From intent to authorized execution.
AI agents can decide what should happen. Your application still needs to control how it happens.
As applications expose more capabilities to AI agents, a simple tool or endpoint can become a surprisingly large execution surface. Every new capability can bring another tool schema, another orchestration path, another place to repeat validation and authorization, and another implementation-specific contract for the agent to understand.
Foundgine's goal: expose application capabilities semantically, then keep authorization, planning and physical execution inside an application-controlled boundary.
Foundgine is a programmable semantic execution platform for .NET. It creates a controlled boundary between callers and the data and operations they're allowed to execute.
Every request crosses this boundary — this is the shape you'll see on every page.
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.
Why does Foundgine exist?
Modern applications increasingly have many callers: web and mobile applications, APIs, GraphQL clients, internal services, automation, and AI agents.
Without a common execution boundary, each interface can grow its own authorization, validation, query translation, and data-access path. Foundgine is designed to centralize the semantic execution model so that different callers can share the same application-defined capabilities and execution rules.
Callers describe what they want. Foundgine determines what is allowed, how it should execute, and which provider performs it.
Foundgine and AI agents
AI agents make this boundary particularly important. An AI model can decide what it wants to accomplish. It should not become the authority over which application data it is allowed to access, nor should it need direct database credentials.
This is deliberately different from a model generating SQL directly against a database. Foundgine is intended to keep the application in control of authorization and execution while allowing AI and other structured callers to use application capabilities. Read more in AI agents with Foundgine.
Capabilities
| Capability | Purpose |
|---|---|
| Semantic modeling | Define the application-facing model independently of physical persistence details |
| Structured intent | Represent requested operations without coupling callers directly to SQL |
| Relationship traversal | Express operations across connected domain data |
| Authorization-aware planning | Carry application authorization constraints into execution planning |
| Execution planning | Convert semantic operations into provider-independent plans |
| Plan rewriting and optimization | Transform plans before physical execution |
| Provider independence | Separate semantic operations from provider-specific execution |
| SQL execution | Execute relational plans against SQL providers |
| InMemory execution | Execute the same semantic model without a database |
| GraphQL integration | Use GraphQL as an interface without making GraphQL the execution model |
| JSON / structured input | Accept structured intent from non-GraphQL callers |
| AOT support | Support generated metadata and Native AOT-oriented deployments |
| AI-agent integration | Allow agents to request application capabilities without direct database authority |
| Execution evidence | Make authorization, planning, and execution observable |
A 30-second example
A caller asks: "Find customers with accounts over $10,000." The caller does not need to know the database schema or generate SQL.
Request
↓
Customer
└── Accounts
└── Balance > 10,000
↓
Authorization
↓
Execution plan
↓
SQL provider
↓
Result
The important boundary is: what the caller requested ≠ what the database can execute. Foundgine connects those two through an application-controlled semantic and planning layer.
Agent efficiency under load
Run 4 tests the same customer-exposure business process through two execution paths across 16 workload/concurrency combinations: 10, 100, 1,000 and 10,000 customers at concurrency 8, 16, 32 and 64. Each condition used 30 measured runs after 5 warmups.
| Measured signal | Run 4 result | Interpretation |
|---|---|---|
| Context-load tokens | 87.3% lower | ~1,617 → ~206 estimated context tokens per flow, averaged across the 16 cells. |
| Tool interactions | 6 → 1 | The semantic capability compresses the measured business operation into one application-level tool call. |
| Measured RPS | 3.8×–33× higher | Foundgine recorded higher RPS in all 16 published workload/concurrency cells. |
| Recorded failures | 0 | No failed requests were recorded in the published Run 4 samples. |
The most important result is the reduction in agent-side work. The benchmark's token figure is an offline context-load estimate, not provider billing data. The website's impact explorer therefore treats cost, energy and CO₂ as derived scenarios, with the assumptions exposed and editable.
Less agent context → less estimated compute energy → potentially less CO₂.
The first step is measured. The latter steps are modeled assumptions, not direct electricity or emissions measurements.
Explore the interactive benchmark matrix →
What Foundgine is not
Foundgine is not an ORM replacement, a database, a GraphQL server, an LLM, an agent framework, or an identity provider. It is an execution layer that can sit underneath those kinds of systems.
Vision
Make application capabilities understandable and safely executable by machines.
The long-term vision is a stable semantic execution boundary between what a system asks for and what an application is willing to execute — for traditional software and intelligent agents alike.
Security
Foundgine's authorization and execution boundaries are intended to reduce unsafe access paths, but application security remains a shared responsibility. Authentication, secret management, transport security, rate limiting, database permissions, and deployment security remain application and infrastructure responsibilities.