[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:

                 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:

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:

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:

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:

"buys"   → PurchaseOrder
"seller" → Supplier

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

The flow is:

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:

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:

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:

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.

┌──────────────────────────────┐
│          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:

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

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

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:

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

Website: Foundgine documentation

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.