Vibe coding crossed the chasm. Your enterprise agent is still stuck in the demo.

What’s missing from the enterprise agent harness.

In about eighteen months, AI coding assistants went from party trick to daily tool. “Vibe coding” is a real workflow now — people describe what they want and ship working software with it. In the same window, the enterprise agent that’s supposed to answer a question as mundane as “what was revenue for SKU X last week?” mostly still lives in a slide deck. Same underlying models. Wildly different outcomes. It’s worth understanding exactly why, because the reason isn’t what most people assume, and it points straight at the piece almost everyone is hand-waving.

The wrong number nobody catches

Picture an analyst trying out the company’s shiny new agent. She asks for revenue for SKU X over the past week. Back comes a number — $128,400 — fast, fluent, neatly formatted. It goes into the board deck.

It’s wrong. The agent used shipped revenue instead of booked; it counted a rolling seven-day window instead of the company’s Monday-to-Sunday week; and it ignored the return provision. The real figure was $96,000. Nobody catches the error, because a confident wrong answer is indistinguishable from a right one. There’s no red squiggle under a bad number. Code that doesn’t compile announces itself; a plausible revenue figure does not.

That’s the enterprise agent problem in a single scene. The failure isn’t loud and obvious. It’s silent, plausible, and repeatable — which is worse.

The same request has several defensible readings — definitions of “revenue” crossed with definitions of “last week” — each producing a different number. The model must choose one, and nothing in the question tells it which is the house rule.

Why coding agents crossed over and business agents didn’t

Here’s the part that gets skipped. Coding agents didn’t win because code is “easier.” They won because code comes with a free lie detector. Write a function, run it, and the test passes or it doesn’t. The compiler complains. The program crashes. The feedback is immediate, automatic, and nearly free, so the agent gets corrected by reality dozens of times an hour. It operates in a verifiable domain.

Most business operations don’t offer that. “Revenue for SKU X last week” has exactly one correct answer inside your company — but nothing at the moment the agent produces it tells the agent, or the analyst, that it picked the wrong interpretation. The answer simply looks finished. This is the real chasm: not model intelligence, but verifiability. Wherever there’s a cheap oracle for “is this right?”, agents are thriving. Wherever there isn’t, they’re stuck in the demo.

Why one crossed the chasm and the other didn’t. Code gets an automatic verdict — compile, run, test — so the agent is corrected for free. A business answer has no such referee at the moment it’s produced.

And without an oracle, the model fills the gaps the only way it can — by guessing the most statistically plausible reading. “Last week,” “revenue,” “active customer,” “the Northeast region” each carry a dozen defensible meanings, and the model confidently commits to one. The deeper trap: it cannot see that those terms are ambiguous in your business. To the model, “revenue” is a common word with an obvious meaning, so it never thinks to ask. (“Just have it ask a clarifying question” doesn’t rescue this — it doesn’t scale to thousands of calls a day, and it assumes the agent knows what it doesn’t know, which is the whole problem.) Turning the temperature to zero doesn’t help either: a deterministic guess is still a guess. You just get the same wrong number every time.

A bigger model won’t save you

The tempting move is to wait for the next, smarter model. It won’t fix this, and the reason is worth stating precisely.

A consumer agent planning your weekend runs on universal knowledge — public facts, general reasoning, the shared meaning of ordinary words. All of that gets absorbed during training. An enterprise agent needs the opposite kind of knowledge: particular, proprietary, contested, and fast-changing. What your finance team means by “booked revenue.” Which SKUs roll up into “Product Line 4.” That your fiscal week starts Monday. That “active customer” was quietly redefined last quarter. None of that is on the public internet, so no amount of pretraining can learn it. It lives in your databases and in your veterans’ heads, and it changes on a schedule no training run can follow.

So the gap is structural, not a capability you can wait out. A more powerful model guesses more eloquently. It does not guess your house definitions.

Everyone feels it — and names it differently

The major platforms have all reached the same diagnosis, and each is attacking from the direction of its own history. The effect, for a buyer, is that the market suddenly sounds like five vendors selling the same idea in five dialects.

• SAP, sitting on the transactional system of record, argues the moat is business process context, and is building a knowledge graph of business entities beneath its agents.
• Snowflake and Databricks, sitting on the data estate, argue the moat is a governed semantic layer over your data — a single place where “revenue” is defined once so every agent inherits the same meaning.
• Microsoft, spanning the whole stack, is assembling a context layer — an ontology plus a graph — that feeds its agents structured business meaning alongside the model.

Different starting points, one shared realization: the model is the easy part; the missing piece is grounded, governed business meaning. And a fair note for the skeptic — none of this is genuinely new. Semantic layers, master data management, and metrics layers have existed for years. What changed is the consumer. A dashboard is read by a human who knows to be suspicious. An agent acts on the definition, non-deterministically, at scale. The old plumbing now has to be machine-bindable and governed, not a glossary buried in a wiki.

If you’re evaluating any of this, that gives you a lens that cuts through the branding. Ignore whose “context layer” or “intelligence” product has the slicker name. Ask one question: at the moment the agent acts, does it bind to grounded, governed, executable definitions — or is it guessing?

What the fix actually looks like

Concretely: put a layer of knowledge and semantics between the natural-language request and the data, so that language resolves to one canonical query instead of a guess.

Back to our analyst. “Revenue for SKU X last week” enters the agent. Before it touches the database, the semantic layer binds the terms — “revenue” to booked, net of returns, “last week” to the prior Monday through Sunday, “SKU X” to its canonical id, rolled up correctly. Those bindings aren’t prose the model reads and paraphrases. They are executable definitions that compile to a single, governed query against the live ledger. The agent runs it and returns $96,000 — the same number the company’s most senior analyst would produce — with a trail showing exactly which definitions it used. Ask again tomorrow, get the same answer. The win isn’t that the model got smarter. It’s that the ambiguity was removed before the model could guess.

Grounding in one line: the semantic layer binds each ambiguous term to a sanctioned, executable definition, the fan of readings collapses to a single governed query, and the live ledger returns one answer you can repeat and audit.

Two things make this more than a dictionary of definitions. First, the knowledge layer doesn’t hold the data — your ledger stays where it is, authoritative and fast-changing, and the agent fetches the live slice it needs at query time. Second, the semantics double as governance: because every answer is bound to a sanctioned definition, every answer is auditable. The same mechanism that makes the number right makes it defensible. “Our agents cannot quietly invent their own definition of revenue” is a compliance sentence, not just an accuracy one — and that’s the version that gets funded. None of this replaces your systems of record; it sits over them.

Step back, and the whole runtime has a shape — think of it as the agent’s harness, the frame that holds a model in place so it can do real work.

The enterprise agent harness.

Read it in three moves. First, three sources feed context, the small disposable working set for a single task: the agent consults slow-changing knowledge (with semantics nested inside — the definitions, and the “map” of where data lives), recalls relevant memory, and fetches a live slice of external data. That external fetch lands straight in context rather than passing through memory, which keeps the ledger authoritative rather than something the agent half-remembers. Second, the agent acts — reasoning over that context and reading or writing external systems. Third, it stores outcomes back to memory; and on a much slower cycle (the dotted line) experience that proves durable gets promoted into knowledge — the way a one-off workaround eventually becomes a documented standard. Grounding, the subject of this post, is the top-left corner of that picture: get knowledge and semantics right, and everything downstream has something true to stand on.

One beam, not the whole harness

A necessary caveat: grounding is one beam of the harness, not the entire structure. An agent that retrieves the right definition still needs everything around it — a way to evaluate whether its answer was in fact correct (grounding and evaluation are joined at the hip; you can’t trust grounding you have no way to check), a loop to improve over time, and the security, identity, and guardrails that decide what an agent is even permitted to read or do. Each is load-bearing.

Knowledge and semantics earn their own treatment for one reason: it’s the beam most often dismissed with “we’ll add a context layer,” and the one that most directly separates a demo from something you’d let near the board deck.

The hard part is next

Which leaves the obvious question. If the missing piece is a layer of grounded, governed, executable business meaning — and if those definitions are scattered across systems and contested across departments — how do you actually build it? Who decides that revenue means booked-net-of-returns when finance, sales, and tax each have a legitimate claim?

That turns out to be mostly an organizational problem wearing a technical costume. And it’s the subject of the next post.