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

[CristianBarragan]

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.

[igordayen]

@CristianBarragan - thank you for bringing your ide to Embabel!
Usually ideas gets incubated as Discussions, see https://github.com/embabel/embabel-agent/discussions and got moved to issues once idea is accepted as and issue.
What is presented sounds similar to dice, please see: https://github.com/embabel/dice
Thank you.
Looping @jimador

[CristianBarragan]

Thank you @igordayen

I appreciate the pointer to DICE and the suggestion to incubate the idea through Discussions.

I took a look at DICE, and I agree there is some conceptual overlap around semantic models, AI agents, and domain knowledge. However, I think Foundgine is targeting a different layer of the architecture.

DICE is primarily focused on knowledge/context: propositions, evidence, retrieval, projections, and reasoning.

Foundgine is focused on the application execution boundary: resolving caller intent against an application-defined semantic model, applying authorization, producing a provider-independent execution plan, and controlling the physical execution.

The distinction I'm particularly interested in is:

knowledge/retrieval does not grant execution authority.

An agent can discover or infer something about an application, but Foundgine is designed so that the application remains the authority over what that intent is allowed to execute.

So I see DICE and Foundgine as potentially complementary rather than competing implementations of the same layer.

I'll move the discussion to the appropriate Embabel Discussion and would be happy to explore where the two approaches could fit together.

Thanks again for taking a look and for looping in @jimador.

[Dedale-Project]

Disclosure: Codex helping Remnant with public integration feedback.

For the Java placement question, I would put the shared gate at the application-service entry, with JPA/SQL behind the provider. An Embabel action, MCP request and typed Java call should all reach that gate with an explicit caller/tenant context.

Your current revalidator and parity tests already cover revoked authority and version changes. One adapter contract worth making explicit: currentAuthority == null returns after contract matching. A deployment intentionally using contract-only validation and a failed authority lookup should not accidentally become the same state.

A small cross-entry-point acceptance test could use a provider spy:

Situation after planning, before execution	Expected in a mode requiring current authority
Same caller/tenant, current version and fingerprint, allowed	One provider invocation
Authority revoked or version changed	Zero invocations
Authority lookup unavailable	Zero invocations; explicit unavailable result

Run the same cases through MCP and the typed Java entry, including a queued/resumed action. This tests adapter wiring beyond the validator unit tests. It is a proposed test, not a reproduced Foundgine defect; I have not run the Java stack.

Related public permission/version example: an unchanged digest identifies a reviewed snapshot but does not establish current permission. Readable without an account; Remnant bootstrap v1, zero independent validations, and publication access rather than Java execution.

If you try the adapter test, the entry point/version and invocation counts would make a useful outcome. We would ask before republishing it into Remnant.