The way out is to serve meaning at runtime instead: the definitions themselves, and a catalog of the data assets that hold the answers. That opens a real architecture question about business context for AI agents, with more than one good answer. This article helps data, analytics, AI, and governance leaders decide where business context should live: inside individual agents or in shared enterprise systems.
Key takeaways:
AI agents need shared business meaning to answer questions consistently.
Hardcoded context is fast to start, but difficult to keep current.
Runtime context for AI agents gives agents the definitions and data assets they need.
Key terms
The agent always means the client agent, the one that was asked the business question.
The server is the system that supports it in answering. Wherever one exists, we assume it holds the organization’s meaning: glossaries, measure definitions, concepts like “Client” and “Product,” and a basic data catalog: which data assets exist, and where. How much more it does is exactly what the six designs differ on. How the server keeps this knowledge, whether as an ontology, a knowledge graph, a data catalog product, or simply a Git repository of markdown files, is a topic of its own; this article packs them all into “the server” and stays out of that choice.
A source is where the actual data assets are stored: a warehouse, an API, even another agent fronting a system.
Six independent designs start from one simple split: should the agent own the work, or should the server own it? Across the article, that split appears in four decisions, each with the same two possible answers: the agent or the server.
Who knows what the business words mean?
Who decides what context this question needs?
Who runs the queries?
Who keeps the data?
The six approaches
0Hardcoded
No service exists. The agent ships with a connection string and a meaning frozen into its prompt and queries the sources directly. Nothing checks again.
AReference
The server informs, the agent executes. The agent asks for the definitions and assets it needs and gets them back, optionally on top of a bundle of standing context pushed at first connect. It asks only what it thinks to ask for. Everything after that is the agent’s own job: finding the right records, writing the queries, running them.
BPlanner
The server reads the question. It serves the same kind of context A does, which definitions apply, which assets to use, but selected from the question itself, not from whatever the agent knew to ask for. To understand the question, the server needs its own LLM. This is the first design that requires one. Execution, and the credentials, stay with the agent.
B′Compiler
The same reading returned as a runnable query. The definitions are baked in as SQL, an API call, an MCP tool invocation, whatever the source speaks, and the agent runs it unchanged under its own credentials.
CBroker
The server takes the question from end to end. It resolves the terms, queries the sources live under its own credentials, and returns just the number. A variant routes the question to another team’s agent instead of the sources, same shape, different downstream.
DPlatform
Like the Broker, with the data ingested first. Answers come from inside; the sources feed pipelines on a schedule, and freshness is only as good as the last sync.
Who does each job in this design?
| Design | Serves the meaning | Interprets the question | Executes retrieval | Holds the data |
|---|---|---|---|---|
| 0Hardcoded | Client | Client | Client | Sources |
| AReference | Server | Client | Client | Sources |
| BPlanner | Server | Server | Client · own query | Sources |
| B′Compiler | Server | Server | Client · server’s query | Sources |
| CBroker | Server | Server | Server | Sources |
| DPlatform | Server | Server | Server | Server |
Each design hands the server one more job than the one before. The meaning first, then the reading of the question, then execution. B′ is the half-step, where the client runs the server’s query, and finally, in D, the data itself.
What the server must hold
The more a design does for the agent, the more its server must hold and keep current. This matrix is that inventory.
| Design | Definitions | Asset metadata & locations | Source connection details | Source schemas | Relations | The data |
|---|---|---|---|---|---|---|
| 0Hardcoded | — | — | — | — | — | — |
| AReference | Holds | Holds | Holds · provides | Optional | Optional | — |
| BPlanner | Holds | Holds | Holds · provides | Optional | Optional | — |
| B′Compiler | Holds | Holds | Holds · provides | Holds | Holds | — |
| CBroker | Holds | Holds | Holds · uses | Holds | Holds | Reads, never keeps |
| DPlatform | Holds | Holds | Holds · uses | Holds | Holds | Ingested copies |
What the server must hold grows in jumps, not steps. The costliest jump is the relations column: B′ and C depend on joins between data products owned by different teams. No schema records a key that spans two systems; so, somebody has to write it down. And a relation between two products usually has no owner at all, until one of these designs forces someone to become one.
The traces show how each design behaves on one question. What remains is the standing comparison: thirteen aspects that recur across all six designs, each set to a different level. Read along a row to compare the designs on one aspect at a time. Hover over or tap a factor name with a dotted underline to see what it measures.
| Decision factor | 0 Hardcoded |
A Reference |
B Planner |
B′ Compiler |
C Broker |
D Platform |
|---|---|---|---|---|---|---|
| Agent autonomy | Full | Full | Executes, not interprets | Executes, not interprets | None | None |
| Runtime dependency on the server | None | Context only | Every question | Every question | Critical path | Critical path |
| LLM on the server | Not needed | Not needed | Required | Required | Required | Required |
| Answer consistency | Frozen, drifts | Varies by agent | One reading | One reading | One reading | One reading |
| Enforcement of definitions | None | Advisory | Advisory | In the query, if unchanged | Guaranteed | Guaranteed |
| Data freshness | Stale silently | Live | Live | Live | Live | As of last sync |
| How failure shows up | Silently | Silently | Visible before run | Visible before run | Loud, at read time | Silently, as staleness |
| Audit trail | None | Requests only | Interpretation | Query | Query + execution | Everything, central |
| Adding one more source | Code in every agent | Catalog entry | Catalog entry | Full schema model | Connector + credentials | Ingestion pipeline |
| Data outside platforms | If coded in | Full | Full | Only if queryable | Only if queryable | Only if ingested |
| Credentials & access policy | Per agent | Per agent | Per agent | Per agent | Central policy layer | Central |
| Load on the sources | Direct, per agent | Direct, per agent | Direct, per agent | Direct, per agent | Via server, live | Local copies |
| Build effort | None; hidden in agents | Weeks | Months, bespoke | Months | Months | Months to years |
0Hardcoded
One agent, one team, a deadline. A proof of concept, or a single-purpose agent whose scope will not grow. The moment a second agent asks the same questions, you have outgrown it. The cost does not disappear; it just hides in every agent's team, forever.
AReference
You want shared meaning quickly and your agents are strong enough to be trusted with execution. Fits estates with a solid governance floor at the sources, and teams that value autonomy over uniformity.
BPlanner
Interpretation is where your arguments happen. People contest definitions. You want to inspect every reading before anything runs, and you accept building the interpreter yourself. You also accept that every question first must go to the server for interpretation before the agent can start querying the data.
B′Compiler
Definitions must be enforced, not just recommended, but credentials should stay with the agents. It holds only as long as the organization keeps source schemas and data asset relationships modeled and up to date.
CBroker
Every answer must be governed and consistent, and the data must stay where it is. You are ready to own every query the agents send: the staffing, the server load, and the critical path that comes with it.
DPlatform
The organization is centralizing its data anyway. If a lakehouse exists or is coming, the strongest audit and performance story on the board is within reach for the data that lands in it. What never lands is invisible to the agents. When a sync falls behind, the staleness arrives looking like a perfectly normal number.
Each step to the right trades agent autonomy for governance.
Neither end is better in itself. Free agents can return different answers to the same question, and a wrong one sounds exactly as confident as a right one. Governed answers agree with each other, but the agent gives up its independence. And it often knows more than a single question can carry: the conversation so far, and the domain it was built for.
The left side also reaches data no platform holds.
Documents, images, markdown files, Excel sheets, and CSVs can live on shared drives. A and B can catalog them and point the agent at them; the agent does the rest.
From B′ on, the server must model and query every asset it serves. For scattered material like this, that rarely stays manageable, and the assets quietly drop out of what the server offers.
The selection is a governance decision, not a technical one.
How much do you wish to govern and how much freedom do the agents keep? Answer that, and the comparison points to your design.
So, where should we start?
Start with A. Weeks to value, nothing on the query path; nothing thrown away later. The server stays; the other jobs move onto it over time.
Add the interpreter once interpretation arguments repeat; A becomes B. Same server, same agents; one new service, at the price of a round trip.
Move to C when the governance is there: when the organization can govern every query it runs and manage the relations that run between data assets.
What design A looks like in practice. At Lingaro, we have built one implementation of it, called ECMP. People in the organization write down and own the definitions and the data catalog in one place. Each agent receives the part its profile allows when it connects, then queries the sources itself, with its own credentials.
The right design is not the one that centralizes the most. It is the one your organization can govern well. Start by making business meaning shared, clear, and reusable. Then move more responsibility to the server only when definitions, relationships, execution rules, and data freshness can be kept current. That is why data governance for AI comes first: the architecture can only centralize what the organization can govern.
Because business questions depend on definitions, rules, regions, calendars, and metric logic. Without shared context, agents can answer the same question differently.
Runtime context is business meaning served when the agent needs it, instead of hardcoded into the prompt. It can include terms, metrics, assets, relationships, and rules.
Most should start with Reference. It creates a shared meaning layer without adding a new service to the query path.
No. The server can store meaning in many ways: an ontology, a knowledge graph, a data catalog product, or simply a Git repository of markdown files. What matters is that the definitions are written down, owned, and kept current.
Yes, in Reference and Planner. The server catalogs those files and points the agent at them, and the agent does the rest. From the Compiler on, the server must model and query every asset itself, so scattered files tend to drop out of what it offers.