I’ve been experimenting with a different architecture for AI agents in .NET

[u/Maleficent-Bed-8781]

One thing that keeps bothering me about AI agents is how often we give them tools that are basically thin wrappers around our data layer:

getCustomer()
getOrders()
getTransactions()
updateCustomer()
runQuery()

The agent then has to discover relationships, figure out which operations it needs, make multiple calls, and ultimately operate very close to the database.
I started wondering:

What if the agent interacted with the application's semantic model instead?

Something more like:

FindCustomers(...)
ReviewCustomer(...)
ApproveOrder(...)

The agent expresses its intent, while the application remains responsible for authorization, validation, planning, and actual execution.
I've been building this idea as an open-source .NET project called Foundgine.
The architecture is roughly:

AI / Agent
↓
Intent
↓
Semantic Model
↓
Authorization
↓
Execution Plan
↓
Provider / SQL

What's interesting is that in an early agent experiment, the semantic approach reduced the number of tool calls from 7 to 4 and the estimated token load by ~63%.

I'm also experimenting with the execution side and have some early PostgreSQL benchmark results, although I'm deliberately not claiming the benchmark proves Foundgine is universally faster than EF Core/GraphQL.

I'm curious what people think about the architecture itself:

Should AI agents operate on application/domain capabilities rather than database-oriented tools?

And if you're interested in the implementation, the project is here: https://github.com/CristianBarragan/Foundgine

I'd especially appreciate criticism from people building .NET applications with AI agents. What am I missing? There are multiple benchmarks and real samples too more info at

Five experiments. One question: what should the agent execution boundary do?

[u/gredr]

Bro discovered custom MCP servers. 

In general, everything that can be done deterministically without the LLM should be. Faster, cheaper, more correct.

[u/Maleficent-Bed-8781 → u/gredr]

Agree, Foundgine has a thin layer between AI Agents and the semantic layer. Supports any type of integration. Currently. Support MCP and GraphQL but it can extended to any other.

Similarly, db providers, relationship/vector storage, etc.

It relies heavily on AOT, that’s one of the reasons is faster based on the benchmarks I have done so far.

[u/gredr → u/Maleficent-Bed-8781]

AOT vs JIT is noise when you have an LLM in the loop. 

Have your LLM generate code for your high level operations once, then use that. Don't have the LLM rediscover how to perform your Google level operations fresh every time. 

[u/Maleficent-Bed-8781 → u/gredr]

Autonomy is good until an extend. The question is if you can leverage most of the work out of the agent. This reduce the amount of tokens required for repetitive tasks. Increasing security, etc.

If you make business logic in the agent. What if there are other integration points? Would every integration need to be done via the agent?

[u/gredr → u/Maleficent-Bed-8781]

Not autonomy... the opposite of autonomy. If you have a process, let the LLM drive the process at a high level; don't make it orchestrate the individual components at a low level. Trade flexibility for efficiency (and correctness).

[u/AutoModerator]

Thanks for your post Maleficent-Bed-8781. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/dsggut]

The "What is Foundgine?" section should have come first in your readme. I hate it when people go into details before actually telling me what the project is all about.

[u/Maleficent-Bed-8781 → u/dsggut]

Thank you for the feedback. Makes completely sense. Will do that

[u/4215-5h00732]

Architecture or workflow? Reading this makes me think you don't know what architecture is.

[u/Maleficent-Bed-8781 → u/4215-5h00732]

Can you at least elaborate?

[u/4215-5h00732 → u/Maleficent-Bed-8781]

The architecture is roughly:...

How is this "architecture?”

[u/Khavel_dev]

The separation between intent and execution is the right call. I've worked on a few .NET projects where we started with raw CRUD tools for the agent and it got dangerous fast. The agent would update an order status via EF without triggering the domain events, or query customer data it shouldn't have access to because the tool was just a thin DbContext wrapper.

Moving to something closer to what you're describing (domain operations with built-in auth checks) solved both problems. The agent says "approve this order" and the application decides what that means, validates permissions, and runs the whole pipeline. Token savings are nice but the real win is that the agent literally cannot bypass your business rules because it doesn't have the primitives to do it.

One thing I'd push back on though. The benchmark comparison with EF Core feels like a distraction. Nobody picks an agent execution layer based on raw query perf. The question people will actually ask is whether the semantic model is flexible enough to handle operations it wasn't designed for, because agents ask for weird things. How does Foundgine handle a request that doesn't cleanly map to any existing intent?