DEV Community: Cristian Barragan

We benchmarked an AI agent with vs. without a semantic execution boundary. It cut token load ~63% — and that's before you count the electricity.

Cristian Barragan — Thu, 20 Aug 2026 01:11:33 +0000

The question

When you give an AI agent tools to complete a real business task, how much of what it does is the task, and how much is just the agent finding its footing — discovering the schema, pulling raw rows into context, re-reading them, hoping it didn't miss a field?

We built a paired benchmark to measure that gap directly, using Foundgine, an open-source .NET semantic execution layer, against a conventional "give the agent raw application tools" flow. Same task, same data, same required final state. Only the execution boundary changes.

The scenario
A banking customer-review task, deliberately not trivial:

Customer
├── 4 banking relationships
│ └── 12 contracts
│ └── 48 transactions
├── calculate total exposure
├── compare with a $48,000 threshold
├── mark the customer as reviewed (one field mutation)
└── verify the final state

Flow A — Conventional application/AI: the agent gets application tools for schema discovery, customer lookup, relationship lookup, contract lookup, transaction retrieval, mutation, and verification. It has to reconstruct the graph itself, in its own context, one tool call at a time.

Flow B — Foundgine semantic flow: the agent gets a semantic capability. Foundgine resolves the graph, applies the application's authorization boundary, and executes behind that boundary. The agent asks for the outcome; it doesn't walk the schema to get there.

Both flows are graded on one thing above everything else: did they land on the exact same final state? If not, nothing else on this page matters. Across 10 measured runs (3 warmups) for each flow, they did — 100% of the time.

What actually changed
Metric Conventional Foundgine Change
Tool calls 7 TO 4 (−42.9%)
Est. token load / call (heuristic) ~981 TO ~364 −62.9%
Same final state true true pass

The tool-call number is measured directly from the harness — no estimation involved. The token number needs one more step, because this benchmark runs in replay mode (no live model calls, so provider-reported token counts are correctly zero — that's the harness working as intended, not a gap). To fill that in, we applied the standard tokenizer approximation — tokens ≈ max(chars/4, words×1.3) — to every recorded tool input/output payload plus the fixed system prompt, which tracks real BPE tokenizers within roughly ±15% for payloads like these. It's directional, not a provider-reported measurement, and it doesn't include the model's own reasoning tokens (which a live run would add — to both flows).

What that's worth in dollars
Converting token load into cost needs one more inference: tool-output payloads get billed as input tokens on the agent's next turn, tool-input payloads (the args the model generated) get billed as output tokens. That's how a real tool-calling loop is billed — inferred here, not measured, but it's the standard convention.

At current Claude API list pricing (Aug 2026):

Model ($/MTok in/out) Saved / call 100K calls/day
Haiku 4.5 ($1/$5) $0.000685 ~$2,055/mo · ~$25K/yr
Sonnet 5, standard ($3/$15) $0.002055 ~$6,165/mo · ~$75K/yr
Opus 5 ($5/$25) $0.003425 ~$10,275/mo · ~$125K/yr

A single internal agent running 10K calls/day is a few hundred dollars a month. A platform-wide agent at 1M calls/day is six figures a month. Treat every one of these as an order of magnitude for planning, not a quote — it's a heuristic estimate at list price, reproducible with a small script (estimate_cost_savings.py, shipped in the repo) so you can re-run it with your own volume and pricing instead of trusting mine.

The part that surprised us: Foundgine was slower, wall-clock
This is the section a lot of benchmark posts would quietly drop. We didn't.

In this replay, Foundgine's wall-clock time was higher, not lower — the conventional flow's 7 small round trips were individually cheap in application time; Foundgine's 4 calls do more resolution work behind the boundary before the agent ever sees a result. Fewer, smaller round trips for the agent traded against more work inside the application.

Tokens, API time, and application load are three different measurements, and a flow can win on one while losing another. Optimizing for per-call API spend and context-window pressure favors the semantic boundary here. Optimizing for raw end-to-end latency does not automatically follow. We report both instead of netting them out into one number that flatters the result.

Zooming out: what if this were the world's problem, not one benchmark?
This part is explicitly a napkin calculation, not a claim. But it's worth doing once, in the open, so it can be argued with.

The IEA's 2026 base case puts global data-center electricity at roughly 485 TWh (2025) heading toward ~950 TWh by 2030, with AI-optimized servers already at ~31% of 2026 data-center power draw (~175 TWh/year) and growing about 3x faster than conventional server load. Critically, the IEA specifically flags agentic and reasoning workloads as consuming hundreds to thousands of times more energy per query than a simple text prompt — this is exactly the workload class this benchmark is measuring.

If we assume energy scales roughly with tokens processed (a simplification — attention cost is superlinear in context length, so this probably understates the real gap at longer contexts), and some slice of that ~175 TWh/year AI-server budget is agentic tool-calling traffic shaped like our "conventional" flow, applying the measured ~63% token-load cut:

Share of AI-server power that's agentic tool-calling like this ≈ energy ≈ saved at 63% cut @ ~$0.12/kWh
1% 1.75 TWh/yr 1.1 TWh/yr ~$132M/yr
5% 8.75 TWh/yr 5.5 TWh/yr ~$660M/yr
10% 17.5 TWh/yr 11 TWh/yr ~$1.3B/yr

1.1 TWh/year is roughly the annual electricity draw of 100,000 average US homes. None of the percentages in the left column are measured — they're scenario inputs, and I'd genuinely like people to push back on them. The one number underneath all three rows that is measured is the 62.9% token-load reduction on this specific scenario. The rest is "if this generalizes, here's the shape of what it's worth" — in dollars, and, just as importantly, in kilowatt-hours and tonnes of CO₂e.

The honest takeaway isn't the headline dollar or TWh figure. It's that a meaningful share of agentic AI's cost and energy footprint is going toward an agent re-discovering how to talk to an application, not toward the business logic itself. That's a fixable, boring, structural problem — not an inherent cost of using AI agents.

Efficiency is not the same thing as safety — and shouldn't be sold as one
This is the part I want to be most direct about, because "we made the agent cheaper" is a dangerous headline to leave unqualified.

Cutting tool calls and token load does not, by itself, change what an agent is authorized to do. That has to be designed in, deliberately, independent of the efficiency win:

The application stays the authority, not the model. Foundgine's semantic capability and mutation boundary are application-defined; the agent requests intent, it never gets raw SQL or physical schema access. A cheaper path can't quietly become a wider one.

Mutations require explicit, narrow intent. In this benchmark, the only field either flow is allowed to mutate is Customer.FullName — because that's the one field the capability grants, not because the agent chose to be conservative.

Verification happens regardless of token count. Both flows call a verify step after the mutation. Fewer tokens should never mean fewer checks.
"Same final state" is the actual gate for every number on this page. An agent that's 63% cheaper and reaches the wrong state isn't a result — it's a regression that happens to look fast.

The efficiency case and the safety case for a semantic execution boundary aren't competing goals. They're the same design decision, looked at from two angles. If you're building agent infrastructure and only optimizing for tokens, you're only doing half the job.

Reproduce it yourself
Full technical report, run-by-run trace, and every caveat: agent benchmark → technical report

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

Foundgine: Why Semantics Matter for LLMs and AI Agents

Cristian Barragan — Wed, 12 Aug 2026 21:17:57 +0000

An engineering example from building Foundgine

Large language models are remarkably good at interpreting language.

That has led to a natural architectural assumption:

User
↓
LLM
↓
SQL / API / Tool call
↓
System

For simple applications, this can work surprisingly well.

But as soon as an agent has to operate a non-trivial system, a fundamental problem appears:

The model has to infer the meaning of the system before it can reliably act on it.

That distinction is easy to overlook.

A database schema contains structure.

An API contains contracts.

A GraphQL schema contains types and fields.

Documentation contains explanations.

But none of these necessarily provide a complete, executable representation of the system's semantics.

That is the problem Foundgine was designed to explore.

Syntax is not semantics

Consider a simplified relational model:

Customer

Id
CustomerKey
FirstName
LastName

CustomerBankingRelationship

Id
CustomerId
CustomerBankingRelationshipKey

Contract

Id
CustomerBankingRelationshipId
ContractKey

Transaction

Id
ContractId
TransactionKey
Amount
Balance

An LLM can look at this and infer:

Customer
↓ CustomerId
CustomerBankingRelationship
↓ CustomerBankingRelationshipId
Contract
↓ ContractId
Transaction

That inference may be correct.

But it is still an inference.

The model is reconstructing semantics from implementation details.

That distinction matters.

A column called:

CustomerId

is not the same thing as an explicit semantic statement:

Customer
hasMany
CustomerBankingRelationship

The first is a database implementation detail.

The second describes the domain relationship.

The problem gets worse when an agent acts

Suppose an AI agent receives:

Create a customer with a banking relationship, a contract and two transactions.

The agent needs to understand more than the names of the tables.

It needs to understand:

Customer
└── CustomerBankingRelationship
└── Contract
└── Transaction

It also needs to understand identity.

For example:

Customer.CustomerKey
CustomerBankingRelationship.CustomerBankingRelationshipKey
Contract.ContractKey
Transaction.TransactionKey

And it needs to understand that the child records depend on values produced by their parents.

Conceptually:

Create Customer
↓
obtain Customer identity
↓
Create CustomerBankingRelationship
↓
obtain relationship identity
↓
Create Contract
↓
obtain contract identity
↓
Create Transactions

This isn't merely SQL generation.

It is planning over a semantic graph.

Foundgine separates meaning from execution

This became one of the central architectural ideas in Foundgine.

Rather than immediately turning a request into SQL, the pipeline introduces semantic representations between the external request and the physical database:

Domain
↓
Metadata
↓
Semantic Graph
↓
Planner
↓
Query Plan
↓
Execution
↓
Provider
↓
SQL

This separation is important.

The semantic layer can describe concepts such as:

Node
NodeIdentity
Edge
EdgeIdentity
Traversal
Path
Predicate
Projection
Ordering
Cardinality

These aren't PostgreSQL concepts.

They aren't GraphQL concepts either.

They describe what the operation means.

Only later does the system decide how that meaning should be implemented physically.

Why an intermediate semantic representation matters

Consider:

customer(first: 50) {
id
firstName
customerBankingRelationship {
contract {
transaction {
amount
balance
}
}
}
}

A naïve architecture can think about this as:

GraphQL
↓
SQL

Foundgine instead treats it conceptually as:

GraphQL intent
↓
semantic traversal
↓
graph plan
↓
physical query plan
↓
SQL

The important difference is that the system can reason about:

Customer
→ CustomerBankingRelationship
→ Contract
→ Transaction

before deciding how that traversal should be executed.

This gives the planner a stable vocabulary.

The semantic model is also useful without AI

This is perhaps the most important point.

It would be easy to describe semantics as:

“metadata for AI.”

That undersells the idea.

The semantic model is useful even if there is no LLM anywhere.

It can drive:

deterministic query planning
relationship traversal
authorization decisions
validation
execution planning
optimization
explainability

AI becomes another consumer.

That distinction is important because it avoids building an “AI layer” that is tightly coupled to a particular model.

Where LLMs fit

The LLM is extremely good at one part of this pipeline:

Natural language
↓
intent

For example:

“Show me the first 50 customers and their transactions.”

An LLM can interpret the request.

But it shouldn't necessarily be responsible for deciding:

Does Customer have this relationship?

What is the identity of the entity?

Is this relationship one-to-one or one-to-many?

Can this traversal happen?

Which fields are authoritative?

What dependencies exist between mutations?

How should the operation be executed?

Those are properties of the system.

The system should expose them.

The LLM interprets intent.

The semantic layer provides meaning.

The planner determines execution.

That gives us:

LLM
↓
Intent
↓
Semantic Model
↓
Deterministic Planner
↓
Execution

rather than:

LLM
↓
"probably correct" SQL

A concrete mutation example

This is where the distinction becomes particularly interesting.

Imagine the mutation:

Create Customer
Create Banking Relationship
Create Contract
Create two Transactions

The transaction records cannot be created independently.

They depend on the contract.

The contract depends on the banking relationship.

The banking relationship depends on the customer.

So the operation has a dependency graph:

Customer
│
▼
Banking Relationship
│
▼
Contract
│
├──► Transaction
└──► Transaction

The semantic representation exposes that dependency.

The planner can then construct an executable plan.

The provider can ultimately turn that plan into database operations.

The LLM doesn't need to invent the dependency chain.

It only needs to express the intended operation.

This is where semantics become especially important for agents

An AI agent has two fundamentally different problems:

Problem 1 — What does the user want?

This is where an LLM shines.

Problem 2 — What does the system allow and mean?

This should not be left entirely to the LLM.

That second problem belongs to the application's semantic model.

This gives us a useful division of responsibility:

Responsibility Best handled by
Interpret natural language LLM
Determine system meaning Semantic model
Validate relationships Semantic model
Determine dependencies Planner
Select physical execution Planner/provider
Execute operation Runtime
Generate final explanation LLM

The LLM remains powerful.

But it is no longer expected to reconstruct the entire system from scratch.

Why this is different from RAG

RAG is useful because it gives an LLM additional context.

For example:

LLM
↓
Retrieve documentation
↓
Reason

But documentation is still information the model has to interpret.

A semantic model is different.

It can be structured and executable.

Instead of:

"CustomerBankingRelationship is a relationship between..."

the system can represent:

Customer
relationship:
CustomerBankingRelationship
cardinality:
many
identity:
CustomerBankingRelationshipKey

The difference is subtle but important.

RAG gives the model information about the system.

A semantic model gives the software a structured representation of the system.

The bigger architectural consequence

Once semantics become first-class, the architecture becomes much more interesting:

              ┌─────────────┐
              │     LLM     │
              └──────┬──────┘
                     │
                   Intent
                     │
                     ▼
            ┌─────────────────┐
            │ Semantic Model  │
            └────────┬────────┘
                     │
          ┌──────────┴──────────┐
          │                     │
     Validation            Authorization
          │                     │
          └──────────┬──────────┘
                     │
                   Planner
                     │
                     ▼
               Query Plan
                     │
                     ▼
                 Provider
                     │
                     ▼
                    SQL

The LLM is no longer the architecture.

It is one component inside the architecture.

That's an important distinction for agentic systems.

What Foundgine actually demonstrates

The repository doesn't prove that:

“LLMs are solved.”

It doesn't prove that:

“A semantic layer makes every AI agent reliable.”

Those would be much larger claims.

What the repository does demonstrate is something narrower and, arguably, more useful:

A software system can make its domain semantics explicit and use those semantics to deterministically plan operations instead of reconstructing system meaning from the physical database representation at every request.

That is already valuable.

And it creates an interesting foundation for AI agents.

Because once a system has an explicit semantic model, an agent no longer has to discover everything through:

documentation
+
database schema
+
API exploration
+
guesswork

It can potentially consume the same semantic representation the runtime itself uses.

The principle

The lesson from Foundgine is not:

“Use AI to generate better SQL.”

It is closer to:

Don't ask an AI to infer semantics that your software already knows.

Let the model do what models are good at:

language
reasoning
intent

Let the system do what deterministic software is good at:

meaning
constraints
relationships
planning
execution

And connect the two through an explicit semantic layer.

That may be one of the more important architectural patterns for the next generation of AI-powered software.

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

Foundgine: Why Another Data Framework?

Cristian Barragan — Tue, 11 Aug 2026 06:44:53 +0000

There is no shortage of frameworks for building data-driven applications.

There are ORMs.

There are GraphQL servers.

There are repositories.

There are query builders.

There are API frameworks.

There are database drivers.

All of them solve real problems.

So why would another system be necessary?

The motivation behind Foundgine starts with a different problem:

modern applications are very good at describing requests, but the meaning of those requests is often lost before execution.

Start with a simple request

Imagine an application with these relationships:

Customer
└── Accounts
└── Transactions

A client asks:

query {
customers {
name
accounts {
number
transactions {
amount
}
}
}
}

At the API level, this is simple.

The client is saying:

Give me customers, their accounts, and the transactions belonging to those accounts.

The difficult part is everything that happens next.

The application has to determine:

which entities are involved
how they are related
which fields are valid
which relationships can be traversed
what authorization applies
how filtering and ordering should work
how the data should be fetched
how many database operations are required
how the result should be reconstructed

This is where application architecture tends to become complicated.

The traditional path

A typical implementation might look like:

GraphQL request
↓
Resolver
↓
Service
↓
Repository
↓
ORM
↓
SQL
↓
Database

Each layer makes sense.

But there is an important architectural consequence.

The original request gets broken apart.

The resolver knows part of it.

The service knows another part.

The repository knows how to query the data.

The ORM knows how to translate objects into SQL.

The database finally executes the result.

There is often no single representation of:

"This is what the application is asking for."

That becomes increasingly important when requests become more complex.

Relationships expose the problem

Consider:

customers {
accounts {
transactions {
amount
}
}
}

A naive implementation can easily turn into:

Query customers
↓
For each customer:
Query accounts
↓
For each account:
Query transactions

The infamous N+1 problem appears.

The solution is well known.

Use batching.

Use eager loading.

Use joins.

Use DataLoader.

Use projections.

Use custom SQL.

Use ORM-specific optimizations.

These are all valid solutions.

But they are mostly execution-level solutions.

The deeper question is:

Where does the system represent the original intent?

That is the question Foundgine explores.

Foundgine starts one step earlier

Instead of immediately converting a request into framework-specific execution code, Foundgine introduces an intermediate representation.

Conceptually:

Request
↓
Intent
↓
Metadata
↓
Semantics
↓
Plan
↓
Execution

The important part is the plan.

The plan represents the requested operation before it becomes SQL.

For the previous example, the system can reason about something like:

Customer
├── Name
└── Accounts
├── Number
└── Transactions
└── Amount

That structure contains meaning.

It says what data is required and how the data is related.

It does not yet say:

"Use this particular SQL query."

That decision belongs later.

Intent versus execution

This distinction is the central idea.

Consider a relational database.

The final execution might be something like:

SELECT
c.name,
a.number,
t.amount
FROM customer c
LEFT JOIN account a
ON a.customer_id = c.id
LEFT JOIN transaction t
ON t.account_id = a.id;

That SQL is useful.

But it is not the original intent.

It is one possible implementation of the intent.

Foundgine attempts to preserve the distinction:

             INTENT
                │
                ▼
          Execution Plan
                │
      ┌─────────┴─────────┐
      ▼                   ▼
    SQL                 Other
   Provider            Provider

This is what makes the architecture different.

The platform does not need to assume that the frontend is GraphQL or that the backend is SQL.

So what exactly is Foundgine?

Foundgine is a platform for turning application intent into executable plans.

Its core concerns are:

Metadata

What entities, fields, and relationships exist?

Intent

What is the application asking for?

Semantics

Is that request valid and allowed?

Planning

What should execution look like?

Execution

How does a provider execute the resulting plan?

This produces a separation like:

What?
↓
Intent

What does it mean?
↓
Semantics

How should it run?
↓
Plan

Run it
↓
Execution

That separation is the foundation.

What Foundgine is not

It is equally important to define what Foundgine is not.

It is not an ORM

Foundgine does not attempt to replace Entity Framework or similar tools.

An ORM maps application objects to database structures.

Foundgine is concerned with a different boundary:

Application intent
↓
Execution plan

An ORM can potentially be part of the execution infrastructure.

It is not a GraphQL server

GraphQL can be an input mechanism.

But Foundgine does not require GraphQL to define its core model.

The architecture is intended to allow other forms of intent to enter the system.

For example:

GraphQL
REST
Application API
JSON Intent
Generated code
│
▼
Foundgine
It is not a SQL replacement

SQL remains extremely powerful.

Foundgine does not try to hide SQL behind another query language.

Instead, SQL can be the final execution representation produced from a higher-level plan.

It is not a repository generator

Repositories typically answer questions such as:

GetCustomer()
GetCustomers()
GetCustomerAccounts()

Foundgine is interested in a different model:

What does this request require?

The distinction becomes increasingly useful when requests are dynamic.

Why introduce another abstraction?

An abstraction is only useful when it solves a problem that otherwise becomes expensive.

The argument for Foundgine is that planning is already happening in many applications.

It is simply happening implicitly.

Developers manually decide:

which joins to use
which queries to issue
which fields to project
how relationships are loaded
how authorization affects the query
how mutations depend on one another
how results are reconstructed

Foundgine attempts to make that planning explicit and reusable.

Instead of every application repeatedly implementing:

Request
↓
Interpretation
↓
Validation
↓
Query construction
↓
Optimization
↓
Execution

the platform provides a place for those responsibilities to live.

The evolution behind the idea

The idea did not begin with a desire to build another framework.

It emerged from a more practical observation:

As applications become more data-driven, the boundary between API, business semantics, and data access becomes increasingly complicated.

GraphQL makes this particularly visible.

A GraphQL query can describe a surprisingly large amount of intent:

customers {
name
accounts {
balance
transactions {
amount
}
}
}

Trying to map that directly to resolvers and application code can result in a growing amount of framework-specific logic.

The natural next step is to ask:

What if the query became a plan instead?

From that question comes the broader architecture:

Frontend
↓
Intent
↓
Semantic model
↓
Planner
↓
Execution plan
↓
Provider

GraphQL becomes one way of expressing intent rather than the foundation of the entire system.

The interesting part is the boundary

The value of Foundgine is therefore not primarily about writing less SQL.

It is about creating a clean boundary between:

what the application wants

and

how infrastructure makes it happen.

That boundary can potentially provide capabilities such as:

query planning
relationship traversal
authorization-aware planning
mutation dependency planning
provider-specific optimization
predictable execution
testable intermediate plans
alternative execution providers

The important word is potentially.

Foundgine is deliberately a foundation rather than a claim that every problem has already been solved.

A different way to think about data access

The traditional mental model is:

API → Code → Database

Foundgine proposes:

API
↓
Intent
↓
Meaning
↓
Plan
↓
Execution
↓
Database

The database still matters.

The API still matters.

The application code still matters.

The difference is that the system now has an explicit representation of the work between them.

That is the core motivation behind Foundgine.

Not another ORM.

Not another GraphQL framework.

Not another database abstraction.

A foundation for making application intent explicit, turning that intent into an execution plan, and allowing infrastructure to determine how the plan should run.

That is the problem Foundgine is designed to explore.

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

Coffee Beanery a GraphQL C# library using Dapper fully customizable

Cristian Barragan — Mon, 01 Sep 2025 02:07:08 +0000

Coffee Beanery intention is to make GraphQL adoption much easier than other frameworks and libraries. Providing it as code rather than as a NuGet package to allow full customizations on a case-by-case basis without boiler plate overhead.

Coffee Beanery repository

Current Features

Configuration-based and faster development
No N+1 problem since the entire query/mutation is batched and materialized by the database engine
Framework agnostic
Allows business service logic within the GraphQL API project
Allows custom mapping between Entity models and Data models
Supports subgraph mutations and queries
Data annotation-based configuration (Data models and Entity models)
Leverage to a mapping framework the mapping between Data models and Entity models
Leverage generics to generate the column names based on the data entities
Supports any GraphQL framework or vanilla .NET API, since it is not tightly couple to a vendor
Nodes (Left joins between entities)
Edges (Joins between entities)
Paging
Filtering
Sorting

Customizable Features

Granular access by table/columns based on token-claims
Data and column validations
Query cache can be customized in multiple layers
Query result handling can be fully customized

Queries

Even though the query cannot be directly converted and translated during the tree processing, the library supports multiple caching techniques, since queries need to be processed as a single statement for the entire tree

Support of multiple cache levels

key: main node string Value: Calculated query
Where and Pagination are decoupled from the query, allowing better cache plans
Query Result data: based on the requirements, the returning data result can be upserted and saved into the cache Mutations Mutations are not cached as they are directly converted and translated during the tree processing, since the upserts do not need to be combined within a single statement. Also, mutations are tightly coupled with data, so there is not much gain in caching the queries with specific values