[FEATURE] Integrating Foundgine as a Semantic Execution Layer for AI Agents

# Foundgine for Java: a semantic execution boundary for AI agents

I've been building **Foundgine** around a simple architectural idea:

> **A caller should be able to express intent without being given direct authority over how that intent is executed.**

Foundgine is now being ported to **Java**, bringing the same semantic execution architecture to the Java ecosystem.

## What is Foundgine?

Foundgine separates **what a caller wants** from **how the application executes it**.

A caller submits structured intent. Foundgine resolves that intent against an application-defined semantic model, validates the requested capabilities, applies authorization, builds a provider-independent execution plan, and finally executes that plan through a provider.

Conceptually:

```text
Intent Sources

API GraphQL MCP AI Agent
\ | | /
\ | | /
└────────┴───────────┴────────┘
│
▼
┌──────────────────┐
│ Foundgine │
│ │
│ Semantic Model │
│ Resolution │
│ Authorization │
│ Planning │
│ Execution │
└────────┬─────────┘
│
┌────────┼────────┐
▼ ▼ ▼
SQL InMemory Providers
```

The important point is that **the caller does not become the execution authority**.

The application remains authoritative over what the semantic model means, what capabilities exist, what the caller is allowed to do, and what ultimately gets executed.

---

## Why does this matter for AI agents?

AI agents introduce a new type of application caller.

An agent can reason about what it wants to accomplish.

But the application should still decide:

* which capabilities exist
* which entities and fields are accessible
* which relationships may be traversed
* which operations are permitted
* which tenant or ownership constraints apply
* which mutations are valid
* how the operation is translated into execution
* what actually gets committed
* what evidence is returned

Without a common execution boundary, agent integrations can easily become:

```text
AI Agent
↓
Tool
↓
Custom authorization
↓
Custom validation
↓
Custom query logic
↓
ORM / SQL / API
```

And then the application ends up with dozens of slightly different security and execution surfaces.

Foundgine proposes:

```text
AI Agent
↓
Intent
↓
Semantic Model
↓
Semantic Resolution
↓
Authorization
↓
Execution Plan
↓
Provider
↓
Result + Evidence
```

The agent can **propose** an operation.

The application decides whether that operation is **meaningful, authorized, and executable**.

---

# Open intent does not mean open authority

This is one of the central ideas behind Foundgine.

The caller does not need a predefined method for every possible request.

For example, an application shouldn't necessarily need to expose:

```text
getCustomer()
getCustomerOrders()
getCustomerOrdersByDate()
getCustomerOrdersByStatus()
searchCustomers()
searchOrders()
searchOrdersBySupplier()
...
```

Instead, the caller can express intent against the application's semantic model.

The application defines the **meaning and authority**.

Foundgine determines the **execution**.

This is what I mean by **open intent**.

It is not open access.

---

# Retrieval is not authorization

Another important distinction is between semantic discovery and authority.

Suppose a caller says:

> "Show me the overdue buys from our top seller in Texas."

A retrieval system might discover:

```text
"buys" → PurchaseOrder
"seller" → Supplier
```

But retrieval does not grant permission to access purchase orders or suppliers.

The flow is:

```text
Caller intent
↓
Candidate retrieval
↓
Semantic resolution
↓
Authorization
↓
Plan binding
↓
Execution
```

**Retrieval proposes. Authorization decides.**

That separation is especially important when AI-generated intent is involved.

---

# Ambiguity should not become accidental execution

Consider:

> "Show me active customers."

Suppose the application legitimately has two meanings:

```text
Customer.AccountEnabled
Customer.HasRecentOrder
```

A vector search or fuzzy matcher might give one interpretation a slightly higher score.

Foundgine does not treat that score as proof of intent.

If both interpretations are legally possible and neither meaning dominates, the system can return a clarification requirement:

```text
Did you mean:

1. Customers with an enabled account
2. Customers who placed a recent order
```

Instead of silently executing a guess.

The principle is:

> **A legal semantic path proves that an interpretation is possible. It does not prove that it was intended.**

That is a very different security model from simply asking an LLM or retriever to choose the highest-scoring result.

---

# Why Java?

The architecture is intentionally not tied to .NET.

The Java port is an important step because the same semantic execution model can now be explored in the Java ecosystem:

```text
Java Domain Model
↓
Semantic Metadata
↓
Application Capabilities
↓
Open Intent
↓
Semantic Resolution
↓
Authorization
↓
Execution Plan
↓
Java Provider
```

The goal isn't to create a Java version of an ORM.

And Foundgine isn't intended to replace:

* Spring
* Hibernate
* JPA
* Jakarta EE
* GraphQL
* MCP
* agent frameworks
* AI frameworks

Instead, it is exploring a layer **between intent and execution**.

That layer can sit underneath those technologies.

---

# Where AI agents fit

I don't see Foundgine as an agent framework.

The agent framework should remain responsible for:

* reasoning
* conversation
* orchestration
* planning at the agent level
* model interaction
* tool selection

Foundgine sits underneath that.

```text
┌──────────────────────────────┐
│ AI Agent │
│ │
│ Reasoning / Orchestration │
└───────────────┬──────────────┘
│
│ Intent
▼
┌──────────────────────────────┐
│ Foundgine │
│ │
│ Semantic Model │
│ Resolution │
│ Authorization │
│ Planning │
│ Execution │
│ Evidence │
└───────────────┬──────────────┘
│
▼
Application Data
APIs / SQL / Providers
```

This means an agent doesn't need to become the application's security boundary.

The application remains the security boundary.

---

# MCP is one possible interface

MCP can expose Foundgine to agents, but MCP itself doesn't need to become the place where application semantics and authorization are implemented.

The architecture becomes:

```text
AI Agent
↓
MCP
↓
Foundgine Intent
↓
Semantic Resolution
↓
Authorization
↓
Execution Plan
↓
Provider
```

This means the same execution boundary can potentially serve multiple callers:

```text
REST
GraphQL
MCP
Java application code
Automation
AI agents
Internal services
```

The transport changes.

The semantic and authorization boundary does not.

---

# And this is where I think the Java port gets interesting

The implementation itself isn't enormous.

The interesting part is the architectural separation:

```text
Caller intent
≠
Semantic meaning
≠
Authorization
≠
Execution plan
≠
Physical execution
```

Once those concerns are separated, different interfaces can converge on the same execution model.

A typed Java API, an MCP request, an AI-generated intent, or another application interface can ultimately become the same kind of semantic intent.

The downstream runtime doesn't need to know which interface produced it.

---

# The architectural question

The question I'm exploring with the Java port is:

> **Could semantic execution become a reusable application boundary between AI/agent intent and the systems that actually execute operations?**

Not another agent framework.

Not another ORM.

Not another API framework.

Not a replacement for MCP.

Rather:

**a semantic execution layer underneath them.**

And importantly:

> **The agent can request the operation. It should not get to redefine the security rules for the operation.**

I'm interested in feedback from Java developers, architects, AI/agent developers, Spring developers, and people working on enterprise application architecture:

* Does Java need a semantic execution layer?
* Where should this boundary sit relative to Spring, Hibernate/JPA, GraphQL and MCP?
* Should application capabilities be generated from Java domain models?
* Could semantic capabilities become a better abstraction for AI-agent tools?
* Should agent frameworks treat application runtimes as semantic execution boundaries rather than collections of independent tools?
* Is this a useful architectural category, or does it overlap too much with existing Java patterns?

**Foundgine is open source, and the Java port is actively being developed.**

Repository: [Foundgine on GitHub](https://github.com/CristianBarragan/Foundgine)

Website: [Foundgine documentation](https://cristianbarragan.github.io/Foundgine/docs-site/index.html)

I'm particularly interested in feedback on whether this architecture makes sense from a **Java-first perspective**, rather than simply reproducing a .NET design in another language.