Integrating Foundgine as a Semantic Execution Layer for AI Agents

[CristianBarragan]

Hi everyone,

Following the suggestion to bring this idea into Discussions, I wanted to introduce Foundgine and get feedback from the Embabel community.

Foundgine is a semantic execution boundary for AI agents and other callers.

The core idea is to separate what a caller intends from how the application actually executes it:

Caller / AI Agent
       ↓
     Intent
       ↓
Semantic Model
       ↓
Authorization
       ↓
Execution Plan
       ↓
Provider
       ↓
Result + Evidence

The important invariant is that semantic discovery or retrieval does not grant execution authority.

An agent can express an open-ended intent, but the application remains responsible for determining whether that intent is meaningful, authorized, and executable against its own semantic model.

I was pointed toward DICE, and after looking at it I see some interesting overlap, particularly around semantic domain models, AI agents, knowledge, retrieval, and reasoning.

However, I see the two projects as operating at different layers.

My current understanding is:

• DICE: primarily knowledge/context engineering — propositions, evidence, retrieval, projections, and reasoning.
• Foundgine: application execution — semantic intent, authorization, planning, provider-independent execution, and execution evidence.

For example, DICE could help an agent establish what is known about a customer, while Foundgine could provide the boundary that determines whether the agent is allowed to execute an operation against the application's customer data.

That leads to an interesting potential architecture:

             AI Agent
                │
        ┌───────┴────────┐
        ↓                ↓
      DICE           Foundgine
   Knowledge /       Execution /
     Context         Authority
        │                │
        └───────┬────────┘
                ↓
          AI Application

I'm particularly interested in whether this separation is useful within the Embabel ecosystem, and whether there are places where Foundgine's execution-boundary approach could complement Embabel's agent and knowledge capabilities.

Foundgine is currently implemented in .NET, and I'm also developing a Java implementation because I believe this architectural boundary is particularly relevant to JVM backend applications.

I'd appreciate feedback on:

1. Whether this execution-boundary abstraction is useful for Embabel.
2. Where you see overlap with DICE and where you see meaningful differences.
3. Whether this could be useful as a complementary component rather than something that belongs inside Embabel itself.
4. Whether there are existing Embabel abstractions that already address this problem.

Thanks for taking the time to look at it. I'm interested in the architectural discussion more than trying to force a particular integration.

Repository: Foundgine on GitHub

Website: Foundgine documentation

[igordayen]

Linking to DETAILED FEATURE Discussion: #2015

[igordayen]

@CristianBarragan - I converted the original issue into a discussion and linked both Discussion Items. Ideally, a single Discussion item would be easier to manage.

My take:

In Embabel, DICE already appears to cover semantic discovery and grounding through its knowledge graph, propositions, labels, evidence, and projections. The more interesting question is whether Foundgine offers something after discovery: a reusable authorization, policy, and execution - planning boundary that can consume DICE-resolved semantics without duplicating DICE’s semantic model. If Foundgine requires its own parallel semantic layer, the overlap may outweigh the benefit.

Modern agents actually can be viewed as applications by themselves, so the boundary between agent and application is not always distinct. That's what I see as a trend for agents empowered with orchestration capabilities, such as Embabel-powered agents.

Would Foundgine help to resolve too-loose, open-ended queries which DICE otherwise would not be able to resolve?

Thank you.

Looping @jimador @jasperblues @tschuehly @johnsonr

[CristianBarragan]

Thanks @igordayen — I think this framing gets much closer to where I see Foundgine fitting.

I agree that DICE should own the knowledge / context / grounding side rather than Foundgine trying to reproduce a parallel knowledge graph. The distinction I would make is that Foundgine's semantic model is not intended to be a second source of knowledge about the world. It is an application capability model: what the application exposes, what those capabilities mean, how they relate, what operations are possible, and what constraints apply to executing them.

So I think the more interesting architecture is actually:

             Embabel Agent
                  │
          intent / reasoning
                  │
          DICE grounding
         knowledge / evidence
                  │
                  ▼
         ┌─────────────────┐
         │    Foundgine    │
         │                 │
         │ Semantic Model  │
         │      ↓          │
         │ Resolution      │
         │      ↓          │
         │ Authorization   │
         │      ↓          │
         │ Planning        │
         │      ↓          │
         │ Execution       │
         └────────┬────────┘
                  │
             Application

The important thing for me is that the boundary isn't necessarily agent vs application. As you point out, an Embabel agent can itself become an application.

I think the more durable boundary is:

untrusted intent → application-defined semantics → authorized executable plan

That distinction matters because an agent should be able to say something relatively loose such as:

"Find customers who are likely to need replenishment and show me their recent orders."

without having to know the database schema, table names, joins, authorization rules, or the application's execution strategy.

Foundgine can resolve that intent against the application's semantic capability model, determine which concepts and operations it maps to, and then produce an executable plan only if that plan is actually permitted.

That also gives us an important property for agents: the domain logic can stay in the domain/application rather than being repeatedly encoded in prompts or agent instructions.

That has two consequences I think are particularly relevant to Embabel.

First, less token consumption and less semantic drift.

Instead of putting a large description of the application's data model, relationships, business rules, and available operations into the agent's context and hoping the model consistently reasons over it, the agent can interact with a compact semantic contract.

The application remains the source of truth.

The agent doesn't need to remember:

Customer -> Orders -> OrderItems -> Product

or know how those relationships are physically implemented. It can express intent in application terms and Foundgine resolves that against the application's model.

Second, Foundgine doesn't require the agent to use only an open-ended interface.

It can expose a rigid/structured API when the caller already knows exactly what it wants, but it can also expose a generic open-intent API where the caller supplies an intent and Foundgine performs lexical/semantic resolution against the application's bounded capability model.

Conceptually:

Rigid API

Embabel
│
└── GetCustomerOrders(customerId)
│
▼
Foundgine

versus:

Open Intent API

Embabel
│
└── "Show me recent orders for customers
likely to need replenishment"
│
▼
Foundgine semantic resolution
│
▼
authorized execution plan

The second case is where I think the interaction with DICE becomes particularly interesting.

DICE could provide the knowledge and evidence needed to formulate or ground the intent, while Foundgine provides the application capability boundary needed to determine whether that intent maps to something the application can actually and safely execute.

So to your question:

Would Foundgine help resolve too-loose, open-ended queries which DICE otherwise would not be able to resolve?

I think potentially yes, but I would phrase it slightly differently.

DICE and Foundgine would be resolving different kinds of uncertainty.

DICE can help answer:

"What do we know about this?"

Foundgine can help answer:

"Given what this caller is asking for, what does this application actually expose that corresponds to that intent, and which executable operation is authorized?"

That distinction is why I don't think Foundgine needs to compete with DICE's semantic/knowledge model.

The other part I consider important is that retrieval is not authority.

A fuzzy match, vector match, lexical match, knowledge-graph result, or even an LLM's interpretation can suggest what the caller means. None of those should by themselves grant permission to execute something.

The final path still needs to be:

Intent
↓
Resolution
↓
Application semantic contract
↓
Authorization
↓
Executable plan
↓
Provider execution

That is the invariant I'm trying to preserve.

So rather than thinking of Foundgine as something that should be "inside Embabel", I could see it being a complementary execution boundary that an Embabel application can call whenever it needs to cross from agent reasoning into application capabilities.

And importantly, that boundary can be used without making Embabel aware of the underlying database or execution technology.

I think that is probably the area I'd be most interested in exploring with the Embabel community: not replacing DICE, and not making Foundgine another agent framework, but seeing whether an application capability / authorization / execution layer is useful alongside the existing agent + knowledge abstractions.

[igordayen]

"Given what this caller is asking for, what does this application actually expose that corresponds to that intent, and which executable operation is authorized?"

@CristianBarragan - there is interface Autonomy which helps with such inquiries. Suppose deployment includes number of agents.
You: here is the intent
Autonomy: here is and agent to fulfill this intent.

thanks.

[igordayen]

@CristianBarragan - What do you think about an Autonomy-like approach? thank you

[CristianBarragan]

Thank you @igordayen, that's a helpful pointer.

I think an Autonomy-like approach fits well for the first hop. "Here's the intent → here's the agent that can fulfill it" is the right shape for routing across a deployment. I'd like Foundgine's open-intent interface to feel similar: intent in, a bounded set of candidates out.

Where I think they differ is in what gets resolved and what happens afterwards:

Autonomy selects which agent should handle an intent.
Foundgine operates below that, at the point where an agent (or any caller) needs to touch application capabilities. It resolves the intent against the application's capability model, checks whether the caller is authorized, and only then produces an executable plan, with evidence of what was run.

So I see them as sequential rather than competing:

Intent → Autonomy (which agent?) → Agent reasoning + DICE grounding
→ Foundgine (which capability, permitted?) → Application

I also agree with your earlier concern about overlap. If Foundgine only did "map intent to a capability," it would duplicate what Autonomy and tool selection already do. The part I think isn't covered is the invariant that resolution never grants authority: authorization and planning are separate steps that can't be skipped, and the result carries execution evidence.

[igordayen]

@CristianBarragan

Thanks for the feedback on Autonomy.

Let's try to draw a boundary between agent vs. application:

• Agent+Application: same deployable unit
• Agent and Application: separate deployable units; Agent is Primary, connects to the application via REST, agent introspects
• Application gets modelled as MCP

What do you think?

Looping @jimador

Thanks