Agent grounding: verified context at runtime, not memory at training time
Agents act. They book, buy, recommend, summarise, and report — and every one of those actions leans on entity facts the underlying model memorised months ago. Agent grounding replaces that memory with a tool call: pull the entity’s live verified record into context at the moment of the task, and check the output against the same record before it ships.
The failure mode is quiet. Ask ChatGPT, Claude, Gemini, Perplexity and Grok about the same company and you get five confident, slightly different, differently-stale answers — Entidex measures this gap continuously, per engine, per fact. A chat user might catch the error; an agent pipeline will not. It will pass the stale headquarters into the CRM, the old CEO into the briefing, the pre-rebrand name into the contract draft. The agent-context layer is where this gets fixed — not with a bigger model, but with a grounding fetch.
The pattern: input packet, output check
Grounding has two touchpoints in an agent loop — one before the model reasons, one before the result leaves the system:
1 · Input — fetch the packet
Before synthesis, resolve each entity in scope and pull its Grounding Packet — the deterministic, Ed25519-signed verified record with per-fact provenance. Canonical identity and current facts are in context from the first token, so the model never has to guess which “Apple” or which decade it is in.
2 · Output — check the claims
Before the answer is returned or acted on, verify its entity claims against the same record. Models sometimes override provided context with training memory mid-generation; the output check catches exactly that class of regression, with a citation into the verified record for every verdict.
Input grounding prevents most entity errors. The output check catches the remainder — and turns “the agent was wrong about the entity” from a silent production incident into a logged, attributable event with the verified value beside it.
MCP quickstart
The Entidex MCP server is hosted — Streamable HTTP at a single URL, nothing to install or run. Point any MCP-capable client or agent framework at it:
{
"mcpServers": {
"entidex": {
"url": "https://entidex.com/api/mcp",
"headers": { "Authorization": "Bearer entx_live_sk_..." }
}
}
}Or let the setup helper detect your client and write the config for you:
npx @entidex/mcp-setup
The grounding loop uses three tools: entity_resolve to map a name to its canonical entity (free tier), entity_verify_fact to check a claim against the signed verified record, and entity_submit_feedback to report a fact the record has wrong — the correction loop that keeps grounding honest in both directions. The MCP server docs list every tool and tier; the developer grounding guide walks the full resolve → fetch → verify loop over both MCP and the REST API.
Grounding, not enrichment
Enrichment fills in fields once and goes stale quietly. Agent grounding is a runtime contract: the record your agents pull is verified against canonical sources, signed under did:web:entidex.com, carries per-fact provenance, and is monitored for drift against what every AI engine believes — so the context layer stays current without you re-vendoring it.
Grounding belongs in the harness, not the prompt
Pasting facts into a system prompt is grounding for exactly one deploy. Facts drift; prompts do not. Wiring the fetch and the check into the agent harness — as tool calls that run on every task — is what makes grounding durable: when the entity’s record changes, the next run picks it up automatically, and the output check keeps holding even as models and prompts are swapped underneath. That is the difference between an agent that was grounded once and an agent that is grounded.
Works with your stack
MCP for agent frameworks and IDE agents; a plain REST API and typed SDK for everything else. The grounding loop is three calls whichever transport you pick.
Verifiable end to end
Every record is Ed25519-signed and every fact carries provenance, so a grounded decision can be audited later: which value the agent held, from which source, observed when.
Go deeper with Entidex
The full entity intelligence platform — beyond Explore Entidex
- Continuous multi-source entity observation
- Alerts when sources diverge or drift
- Cross-surface consensus + visibility over time
- Evidence-anchored intelligence reports
Frequently asked questions
What is agent grounding?
Agent grounding is the practice of giving an AI agent live, verified context at runtime — fetched through tool calls or MCP at the moment of the task — rather than relying on what the underlying model memorised at training time. A grounded agent resolves the entities it is about to reason about, pulls their current verified facts into context, and checks its own entity claims against the record before acting. An ungrounded agent improvises from a training snapshot that is months to years old.
Why do agents need grounding when the model already "knows" the entity?
Because model knowledge is frozen and unattributed. Every engine carries a training-time picture of each entity — and those pictures disagree with each other and with reality. Entidex measures this continuously: engines routinely hold stale headquarters, outdated leadership, and wrong counts, each asserted with full confidence. An agent that books, buys, recommends, or reports based on that memory inherits the staleness. Grounding replaces "the model probably remembers" with "the agent just fetched the verified value, with its source and observation date attached."
What is the input-packet + output-check pattern?
Two grounding touchpoints per task. Input: before synthesis, the agent fetches the entity's verified record — the Grounding Packet — so canonical identity and current facts are in context from the first token. Output: before the result is returned or acted on, the agent verifies its entity claims against the same record (over MCP, the entity_verify_fact tool), catching the cases where the model's memory overrode the provided context mid-generation. Input grounding prevents most entity errors; the output check catches the rest.
How do I connect an agent to Entidex over MCP?
The Entidex MCP server is hosted at https://entidex.com/api/mcp (Streamable HTTP, JSON-RPC 2.0) — nothing to install or run. Point your client at the URL with an Entidex API key, or run npx @entidex/mcp-setup to detect your client and write the config. Free keys cover entity resolution; verification and the full intelligence read gate by tier.
Does grounding replace my RAG pipeline?
No — it sits beside it. Document retrieval remains the right tool for open-ended content questions. Grounding covers the class RAG handles worst: compact, volatile identity facts that are copied into thousands of stale documents. The pattern that works in practice is a per-entity grounding fetch at the top of the workflow, document retrieval for the open-ended middle, and an output check on entity claims at the end.