Agentic AI
How to prove your AI is grounded where it runs
Five checks you can run this week. They exist because we shipped agents that answered fluently for weeks with no knowledge attached, and every test we had reported green the whole time.
Earlier today we published a field note about a deploy config that stripped the knowledge packs out of our agent runtime. Nothing errored. The agents kept answering. This is the follow-up: the checks we should have had, written so you can run them against your own system.
Grounding failures do not announce themselves. A retrieval system that breaks goes quiet; a grounding system that breaks keeps talking, with the constraint removed and the confidence intact. So the goal of every check below is the same — make the empty state loud.
1. Write a canary question only the canon can answer
Pick something no general model could produce from training data: an internal rule, a threshold, a name from your own documentation. Ask it and expect a specific answer.
The test isn’t “does the model sound knowledgeable”. It’s “does it produce this exact fact”. A question like “what are best practices for X” passes on vibes even with an empty context. A question like “what does our Article 6 require before two apps connect” cannot.
Done when: you have one question per agent whose correct answer exists only in that agent’s pack, written down next to the expected answer.
2. Ask it where the system actually executes
This is the step almost everyone skips, and it’s the one that would have caught our failure.
We already had a test suite built for exactly this fear — it checks, per agent, whether the knowledge file exists. It reads the local filesystem. Our bug was in the deploy bundle. Local passed. The cloud was empty. The check and the fault were one layer apart, and the suite reported green throughout.
Run the canary against the deployed endpoint, with the same auth and the same entry point real traffic uses. Not the repo. Not a local run. Not staging, unless staging builds from the identical artifact.
Done when: the canary result you trust came back over the network from the thing users talk to.
3. Make the loader fail loudly instead of returning empty
Ours looked like this:
KNOW_CACHE[agentId] = existsSync(f)
? '…canon…' + readFileSync(f, 'utf8')
: '';
A missing pack is not an exception here. It’s an empty string, and an empty string assembles into a perfectly valid prompt.
Decide which one your system means: “no canon is legitimate for this agent” or “canon is required and missing means broken”. If it’s the second — and for a grounded agent it almost always is — then refuse to start, or emit a metric you can alert on. A deliberate empty state and a broken one must not look identical from the outside.
Done when: removing the pack in a scratch environment produces an error, a failed health check, or a metric change — something other than a normal-looking answer.
4. Inspect the artifact, not the repository
Our bug was one glob in a deploy config: an ignore list written to exclude three documentation files, which also matched every knowledge/*.md.
No code review would catch that, because the code was fine. Only the shipped artifact showed it.
List the files actually inside the deployed bundle, image or container and confirm the knowledge directory is there with the file count you expect. Once, by hand, is already worth it. In CI, it’s a one-line assertion.
Done when: you have seen the file list from inside the artifact that got deployed — not from git ls-files.
5. Keep the rule that makes the model tell on itself
We found the failure through an answer, not through monitoring. Every agent here runs under a standing contract: assert what the sources support, and say plainly when they don’t. Asked about a rule that was no longer in its context, the agent said the rule wasn’t in its grounding — instead of reconstructing a plausible version, which the same model would happily have done without that contract.
That honesty rule was written as a quality constraint. It turned out to be the only instrument that could see this class of failure at all. Keep it, and read what your agents say when they decline — those are free diagnostics.
Done when: “I don’t have a source for that” is a normal, expected output in your system rather than something you have tuned away.
When not to bother
If your agent has no fixed corpus — pure tool-use, everything fetched live per request — steps 1, 3 and 4 don’t apply. There’s no pack to go missing. Check your tool responses instead. Adding grounding ceremony to a system with nothing to ground is process for its own sake, and it will be quietly dropped within a month.
Where this sits on the canvas
AI4 asks what data feeds the system and how it evolves. Treated as a design question it gets answered once, in a document. Treated as an operational question it has to be answerable today, against production, by someone who wasn’t there when it was built.
Our own honest state: the cause is patched — the ignore list now names its three files explicitly, and the runtime carries 14 manifests with 14 matching packs. The class is not. The loader still resolves a missing pack to an empty string, and we still have no automated check that reads the deployed bundle. Steps 3 and 4 above are things we are telling you to do and have not finished doing ourselves.
One thing to take away: you have not verified grounding until you have watched the system fail without it. If you can’t make it break on purpose, you can’t tell when it breaks by accident.
BSC is BIXSO’s open framework for working through business model, analysis and agentic AI as one loop — bixso.ai/bsc.