Why do AI agents get core business terms confidently wrong, and what has to sit under them in production?

Agents get core business terms wrong because the same word carries different rules in different systems, and nothing forces one resolved meaning when the question is asked. The model picks the plausible reading and states it with full confidence. The fix underneath: a definition layer built from the data, confirmed by the term owners, resolved at query time.

The pilot worked for a reason. A demo runs inside one system, where one team's vocabulary holds. Widen the question across claims, billing and finance and the vocabulary stops holding, while the agent's tone stays the same. zaimler's agents page names the barrier: nobody signs their name to an ungoverned agent on core data, which is where an agent that demos well stops short of production.

What does this failure actually look like?

Take active policy at an insurer. The walkthrough is illustrative, built from the rules a governed definition has to settle: bound status, effective dating, cancellation. Origination reads active as bound with the effective date passed. Servicing runs its own state machine, where a policy in a grace period after a missed payment is active for coverage and inactive for renewal outreach. Finance writes cancellations back to the effective date, so a policy servicing shows as active can have left the finance view a month ago. Three readings, all defensible, all live, all of it illustration.

Ask an agent how many active policies a customer holds and it never sees that disagreement. It sees tables, columns and whatever description text somebody typed at creation. So it picks. Two other shapes travel with it: business rules living nowhere except a stored procedure, reconstructed on the spot, fluently, with nothing checking the result; and a governed definition two tables over losing to the nearer uncertified column, because nothing in the search space marks one as authoritative.

BIRD scores text-to-SQL across 95 databases in 37 professional domains, and the paper describes their value distributions as real and large, and names dirty database contents and the external knowledge between a question and the data as central challenges. On BIRD's public leaderboard, scored on the held-out test split of 15 of those 95 databases, the best entry so far reaches 81.95% execution accuracy against 92.96% for the human data engineers and students who set the reference. Read it narrowly, since the gap measures query correctness rather than term definitions: a system handed the schema, description files and a human-written hint per question still lands wrong often enough to matter, before anyone argues about what active means.

What does current guidance say to do about it?

The answer that comes back from current practitioner guidance on grounding agents is coherent, specific and mostly right. Retrieval gets upgraded to hybrid search with a reranking pass. Above that sits a governed business-definition layer: a controlled glossary of canonical terms with approved synonyms, named owners in finance or underwriting, and links to systems of record. Certified metric catalogs come next, where every asset carries certification metadata, a steward, freshness expectations and lineage, and the tool schema lists only approved metrics, so an uncertified column never appears. For logic buried in legacy SQL, the guidance describes a mining pipeline that parses stored procedures into rule objects with provenance back to procedure and line, then clusters duplicates, flags conflicts and ranks by usage so only the highest-value rules reach a reviewer.

A parallel body of guidance answers the reliability question from the other end, treating production readiness as detection: offline evaluation suites before deployment, tracing and observability across an agent's trajectory, runtime guardrails that block a bad response before a user sees it, and judge models scoring whether each claim was supported by what was retrieved.

Give this its due, because the core instinct is right. The fix for an agent guessing at active policy is a layer that settles what active policy means, which a bigger model and a longer prompt do not. Restricting an agent to certified assets beats telling it to prefer them, and mining twenty years of T-SQL for evidence is good advice.

The guidance is also honest about what it costs. It recommends a glossary of roughly 100 to 500 terms and an evaluation set of 100 to 1000 real business questions, both written and maintained by people, and the rule-mining pipeline it prescribes stamps every extracted rule with a review status that starts at not reviewed. Those are prescribed dimensions rather than measurements of anybody's program.

Where does the hand-curated version stall?

The definitions in the stack current guidance prescribes are human-owned, and so is their upkeep. The glossary is written and owned by people. The certification metadata is curated asset by asset. The rule miner is the one place the guidance automates the first pass: bootstrap a large part of the catalog automatically, then aim human review at the important and ambiguous rules. Confirmation still makes the rule usable, so rules that clear triage wait on a reviewer and rules that never clear triage are never confirmed. The evaluation suite scores answers against a golden set of questions people write and grow.

The glossary, the certification metadata, the mined rules and the golden set read like four separate pieces of work. They are one, on a single maintenance model, and the layer stays current only as fast as the same few people can review.

That is the catalog problem moved up a layer. The category post argues it there: a catalog runs on a different clock from the data it describes, and a stale definition returns an answer rather than an error. A layer whose upkeep sits with people inherits both. The data changes when an upstream team ships. The definition changes when someone notices and has time.

The maintenance arithmetic is the second half. Effort scales with terms multiplied by sources multiplied by rate of change, and none of those shrink. Whatever decays first is whatever nobody is watching. zaimler's framing is that hand-built catalogs and ontologies take quarters to build and are stale by the time they ship, and that human curation belongs on judgment calls rather than keeping definitions in sync with changing data.

Governance stays. Owners, approvals and certification are load-bearing. The variable worth changing is the build direction: who drafts a definition first, and what keeps it aligned with the data underneath.

What has to sit under an agent in production?

Four properties to test against whatever you buy or build. The category post argues the four jobs a context layer has to do. What follows is what changes about each job when the layer is drafted from the data and confirmed by people, and what to test.

1. Definitions built from the data itself, then confirmed by the people who own them. The layer reads the schemas, the join paths, the value distributions and the logic already encoded in views and procedures, then proposes the definition. A human with authority over the term confirms it, corrects it, or arbitrates between two systems that disagree. That inversion changes what review means: an underwriting lead spends the hour on the two cases where origination and servicing genuinely conflict, instead of transcribing four hundred entries a machine could have read directly. It also changes what happens on a schema change, because the process that produced the first draft produces the next one. This path has a failure mode of its own, a proposed definition rubber-stamped by a rushed confirmer, which is still wrong and now carries a signature, so test what the layer does when a confirmer disagrees with the data and how a confirmed definition gets re-proposed on a schema change.
2. One resolved identity per entity across systems. Curated by hand, matching starts from a blank spec and a steward's judgment about which fields identify a policyholder. Drafted from the data, it starts from the observed keys and overlaps, and review narrows to the merges the machine could not settle. Test what a confirmed match does when a new source contradicts it, and whether a rejected merge stays rejected through the next rebuild.
3. Resolution at runtime against current data. Curated by hand, freshness depends on somebody revisiting a definition after an upstream release, which is the step that gets skipped. Drafted, a schema change re-runs the draft and lands the difference in a confirmation queue, so drift shows up as work waiting rather than an answer that quietly kept resolving. Test how long a changed column takes to reach that queue, and who is watching it.
4. The path and the permissions carried with every answer. A drafted layer owes the path one more field: which proposal a person confirmed and when, or an auditor cannot separate what the machine inferred from what somebody decided. The drafting process reads across everything, so what it learned from data a user cannot see must stay out of that user's answer. Test both, by replaying an answer for the confirmation record and by asking one question under two entitlement levels.

Detection layers still belong in the picture. Evals catch regressions before a release, traces are how anyone debugs a multi-step agent, and a judge model checking each claim against the retrieved evidence catches a good share of production hallucinations, while the failure modes nobody predicted come back through people: annotation queues, thumbs up and down, escalation. All of it inspects answers after generation, so the wrong answer already exists by then. Detection tells you grounding is failing. Grounding is a separate build.

Where does zaimler fit?

zaimler says it is the enterprise context layer that makes AI reliable enough to run in production: it builds a unified domain model from your existing data automatically, your team confirms it, and it resolves the real relationships in a runtime graph, so the same question resolves the same way every time, live against current data, with a reasoning path you can replay for an auditor. On identity and reach, zaimler says it resolves the same entity across every connected source and reads in place with no migration, so a question crossing claims, billing and CRM lands on one customer. Those are the company's own statements, set out on its platform page on reading every source in place, and the list to verify on your own systems.

Common questions about grounding agents on business terms

Is a business glossary enough to stop agents guessing at terms?

A glossary covers part of the problem. It settles what a term should mean and gives it an owner, which stops the model inventing one outright. It leaves entity identity unresolved, rarely enforces the definition at query time against current data, and drifts whenever an upstream schema changes.

Do evals and guardrails make an agent reliable on core data?

They detect, and detection is worth having on any agent in production. Nearly all of it runs on an answer that already exists, which measures how well the grounding underneath is working. Reliability on core business terms comes from resolving definitions and relationships before generation, with detection over the top.

Why does an agent pick an uncertified column when a governed metric already exists?

Because the uncertified column sits in its search space and looks plausible. An agent with broad SQL access ranks candidates on surface similarity, and a column named policy_status one table away beats a governed definition it was told to prefer. The fix is to expose approved business concepts as the interface, so the column never appears.

What is the difference between grounding an agent and fine-tuning it on company data?

Fine-tuning adjusts how a model writes and behaves, and bakes in whatever definitions held on the training date. Grounding forces the model to consult an authoritative source at question time and return the path it took. Definitions change on their own schedule, so the useful ones resolve when asked.