Skip to content

.NET: Proposal: Integrating Foundgine as a Semantic Execution Layer for AI Agents #7834

Description

@CristianBarragan

Description

Foundgine + Microsoft AI: a semantic execution boundary for AI agents

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 constraints, builds an execution plan, and sends the plan to a provider such as SQL or InMemory.

The result is a reusable execution boundary that can sit underneath multiple interfaces:

                 Intent Sources

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

More architectural detail is here:

https://cristianbarragan.github.io/Foundgine/docs-site/architecture/index.html

Why is this interesting for AI agents?

Modern applications increasingly have many callers:

  • Web and mobile applications
  • APIs
  • GraphQL clients
  • Internal services
  • Automation
  • AI agents

An AI agent introduces an interesting additional caller.

An agent can determine what it wants to accomplish, but the application should remain authoritative over:

  • what capabilities exist
  • what the caller is allowed to do
  • which data can be accessed
  • which relationships can be traversed
  • how mutations are validated
  • how the operation is translated into execution
  • what actually gets committed

Without an explicit execution boundary, it is easy for an agent integration to become:

AI Agent
   ↓
Tool
   ↓
Application code
   ↓
ORM / SQL / API

Authorization, validation, business rules and data access can then become distributed across individual tools.

The Foundgine model is instead:

AI Agent
   ↓
Structured Intent
   ↓
Semantic Model
   ↓
Capability Validation
   ↓
Authorization
   ↓
Execution Plan
   ↓
Provider
   ↓
Result / Evidence

This leads to a question I'd like to explore with the Microsoft AI community:

Could Foundgine provide a semantic execution layer underneath an AI agent framework?

For example:

              Microsoft Agent Framework
                       │
                 reasoning /
                orchestration
                       │
                       ▼
              Agent capability/tool
                       │
                       ▼
                 ┌───────────┐
                 │ Foundgine │
                 │           │
                 │ Semantics │
                 │ Auth      │
                 │ Planning  │
                 │ Execution │
                 └─────┬─────┘
                       │
                       ▼
                 Application
                    Domain
                       │
                       ▼
                 SQL / Provider

The important distinction is that Foundgine would not replace the agent framework.

The agent framework remains responsible for agent reasoning, orchestration and interaction.

Foundgine would sit underneath it and provide an application-defined, strongly typed execution boundary.

That also opens up an interesting possibility around generated agent capabilities.

Instead of exposing arbitrary application methods or database operations to an agent, the application could expose capabilities derived from its semantic model:

Application Semantic Model
            │
            ▼
    Capability Graph
            │
            ▼
     Agent-facing tools
            │
            ▼
      Structured Intent
            │
            ▼
        Foundgine

The agent can therefore reason about application capabilities, while the application remains in control of authorization and execution.

This is particularly interesting for mutations.

For example:

TransferFunds
     │
     ├── tenant isolation
     ├── account ownership
     ├── account state
     ├── amount validation
     ├── authorization revalidation
     ├── idempotency
     ├── atomic execution
     └── audit / evidence

Transferfunds with benchmark

https://github.com/CristianBarragan/Foundgine/tree/main/benchmarks/AgentEndToEnd/Run5SameClient
https://cristianbarragan.github.io/Foundgine/docs-site/agent-benchmark/run-5b/index.html

The agent can request the operation.

It should not get to redefine the security rules for the operation.

That separation is the architectural idea behind Foundgine.

The question

I'm interested in feedback from people working on Microsoft AI, Agent Framework, Semantic Kernel and related application architecture:

Is a semantic execution boundary like this useful underneath an AI agent?

More specifically:

  • Where should this boundary sit relative to Agent Framework?
  • Should agent tools be generated from application capabilities?
  • How should authorization be represented between an agent and the application runtime?
  • Is a semantic capability graph useful to an agent?
  • Could this complement existing Microsoft AI patterns rather than introducing another agent abstraction?

Foundgine is open source:

https://github.com/CristianBarragan/Foundgine

Architecture:

https://cristianbarragan.github.io/Foundgine/docs-site/architecture/index.html

I'm posting this primarily to get architectural feedback before taking the integration further.

Code Sample

Language/SDK

.NET

Metadata

Metadata

Assignees

No one assigned

    Labels

    .NETUsage: [Issues, PRs], Target: .NettriageUsage: [Issues], Target: All issues that still need to be triaged

    Projects

    Status
    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions