Organizational legibility: six layers, seven tests
A working reference on where agent context comes from, where it breaks, and how to test for the breaks. Every test here runs in-house, with the tools and access you already have.
Updated July 2026·11 min read
You've deployed agents. The model is state-of-the-art, the orchestration is competent, the demos are good. Then the agent makes a decision nobody on the team would make. Before filing it under hallucination or harness failure, consider a third explanation: the decision was correct for the organization described in the objects the agent could reach. That organization just isn't yours.
An agent builds its picture of your company from data objects: schemas, records, code, docs, tickets, half-written conventions. Where those objects are thin or contradictory, it doesn't stop to ask. It fills the gap with a statistically plausible guess. The guess compounds through every task downstream. This guide covers where that gap comes from, how to measure it, and what closing it actually consists of.
Agent-readiness is not a documentation problem.
The instinct when an agent fails is to write more documentation. It's the wrong instinct, and it's why "we documented everything and the agent still guesses" is such a common report.
Here's the mechanism. Everything load-bearing in a company starts as somebody's model: a founder's thesis, a product lead's model of the customer, a researcher's understanding of why the system works. Executing on that model generates information all over the org: specs, code, pipelines, CRM records, support threads. Each of those is a data object, and almost none of them were designed to carry the reasoning that produced them. So the objects drift: the same entity named three ways, a definition current in one system and stale in another, the rationale for a workflow living in someone's head while the object records only the steps.
Humans absorb drifts in judgment. We ask a colleague, read the room, find that spreadsheet. Agents act on the objects literally, at scale. Drift that used to cost onboarding time and support tickets now costs wrong decisions made confidently. And splitting the work across multiple agents makes it worse, not better: every handoff is a place context dies.
We call the distance between what leadership means and what the objects say the vision gap. Agent-readiness is the work of closing it: architecture work, not transcription work. That distinction drives everything that follows.
Six layers, in process order with seven tests
An agent-ready organization is built in process order: first the substrate agents read, then three decisions about how the work is organized, then the loop that proves the rest is working. The three middle layers look like engineering choices, but they're auditable properties of your organization. An org can fail every one of them before a single agent is deployed. Each layer below has a failure pattern, a test, and Passing the bar. None of the tests needs new tooling; run all seven and you'll have an honest map of where you stand.
The substrate: what your agents read
The legible substrate
Meaning carried into objects: first the judgment, then the vocabulary.
This layer is half the work. It has two parts, because objects have to carry two different kinds of meaning: how your leadership decides, and what your terms denote. Miss the first and agents reason like a generic company. Miss the second and they reason precisely about entities that don't quite exist.
01a Vision & principles
Every organization runs on a set of positions its leadership treats as settled: what to optimize, what to refuse, which tradeoffs are already decided. Very little of that is usually written anywhere an agent can retrieve it. When an agent hits a genuine tradeoff, it should be reasoning from your positions not from the median opinion of its training data.
Failure pattern
The vision exists in pitch decks, all-hands recordings, and the founder's head. The agent consumes all of it and flattens it into probability mass. So when it hits a real tradeoff, the resolution is the internet's average answer, not yours.
The tradeoff-probe test
Pick one decision your leadership would consider obvious, one where "it depends" is the wrong answer. Give an agent only your written surfaces and pose the decision. If it hedges, or decides the way a generic company would, this part of the substrate is missing.
Passing the bar
A short, ratified principles document that states positions, not values-poster abstractions. Written horizons, values, and principles are something an agent can cite mid-reasoning. Version it like code.
01b Vocabulary & contracts
Your organization has almost certainly stated everything an agent needs. The problem is that each fact is stated five times, in four places, and three of those are stale. Humans route around this on social signal: ask in the channel, someone points at the real source, the group self-corrects in thirty seconds. An agent retrieves what ranks well. What ranks well is often what was written most confidently, longest ago.
Failure pattern
The same term means different things in different systems. "Customer" in Salesforce is not "customer" in the billing schema is not "customer" in the support macros. Each object is locally correct. A human reconciles the three without noticing. An agent silently picks one. Or worse, it collapses them into a lowest-common-denominator merge. Every downstream decision inherits the pick.
The ten-term-diff test
List your ten most load-bearing business terms. Pull their working definitions from three systems, for example: schema, CRM, docs, and then diff them. Every divergence is a place your agents are already choosing a meaning for you. Budget an afternoon, and expect the diff to be uncomfortable.
Passing the bar
Data contracts: explicit, owned, versioned agreements about what an object means and guarantees, between the team that produces it and the teams that consume it. Enforce it at the object, not on a wiki page.
The knowledge graph as domain bounds
The KG as the control plane that defines your agents' domain of interest.
Layer 01 fixes what your terms mean. This layer fixes how they relate. Relationships are where unstructured corpora fail hardest: left to raw tables and prose, an agent infers your domain's structure statistically, and it will invent relationships that don't exist in your business. The alternative is to sit your domain experts down and ratify the graph explicitly: which entities exist, how geography connects to account connects to product, which metric drives which. Done properly, the graph isn't something the agent consults. It's the surface the agent navigates. Every ratified edge is a hypothesis the agent may investigate. Paths not in the graph aren't legal moves. That bound is what turns an open-ended fishing expedition into a tractable investigation.
Failure pattern
The agent's answer cites a causal chain nobody in the org recognizes. It may be plausible-sounding, statistically derived. But it's wrong about how the business actually works. Nobody can point to the relationship it violated, because the relationships were never objects.
The traversal-probe test
Pick a real symptom from last quarter: a metric that moved. Ask an agent, with only your written surfaces, to lay out the plausible causes and how it would check each one. Compare its causal map to the one your best analyst carries in their head. Every relationship the agent missed or invented is an edge you never ratified.
Passing the bar
An explicit domain model of entities, relationships, and metric dependencies, built with your domain experts, versioned, and wired in as the boundary of agent investigation rather than background reading. This is where ontology and knowledge-graph discipline lives, applied one altitude up from the data platform.
The build decisions: auditable properties of how you've organized the work
The deterministic boundary
Someone has decided what is not an AI task.
Every real process has deterministic parts and judgment parts, and the most expensive mistake in agent deployment is paying a model to do unreliably what a pipeline does perfectly. Statistics and machinery should run before any agent is pulled in: detecting that a threshold was crossed, that a number moved, that a gate passed. Whether your organization has drawn this boundary anywhere, and written it down, is a fact about your org's auditability today, agents or no agents.
Failure pattern
An agent is deciding what counts as a signal. Sometimes it applies a method; sometimes it barely looks at the data. Sometimes it's a real signal; sometimes it's noise dressed as insight. Nobody can say which, because nobody decided which questions were ever the agent's to answer.
The misallocation-inventory test
List every step your agents (or your agent plans) currently assign to model judgment. Mark each one: could a pipeline with a threshold do this? Every "yes" is a reliability hole you're paying token prices for. If nobody can produce the list, the boundary doesn't exist.
Passing the bar
A written boundary: detection, gating, and prioritization run as tested, versioned machinery; agents are invoked downstream of it, on a queue of things worth investigating. The boundary itself is an object: reviewable, arguable, improvable.
Workflows from observation, not the org chart
The documented workflow describes what the work actually is not who used to do it.
There's at least one person in your org whose undocumented knowledge is what keeps a process running, and that knowledge is real. But there's a trap in transcribing it directly. The workflow a human runs is shaped by human role boundaries. A pipeline that mimics those roles inherits their seams. Context dies in the handoff. The durable property to audit is whether your documented workflows were ever validated against observation. Did anyone watch the work being attempted by a capable person outside the group, or by an agent? Did they record where the documentation failed? Is the wiki org-chart folklore?
Failure pattern
The wiki says what the workflow is about. A description written for a human who can fill gaps is not an execution surface for an agent that can't. The gaps are invisible until something without tribal knowledge attempts the work.
The cold-start-run test
Give an agent a real (safe) instance of a documented workflow and only the documentation. Count the human rescues every time someone steps in with context that wasn't in the objects. More than zero rescues means the workflow is described, not executable. The rescue count is your metric: it's concrete, it trends, and it's hard to argue with.
Passing the bar
Workflows written as execution surfaces. Inputs are named. Outputs are specified. Edge cases are documented in advance. Stated boundaries make clear where the agent must stop and ask. Boundaries are derived from watching the work run. Every rescue folded back into the object that failed to prevent it.
A single owner of judgment
Sub-tasks return results. They never return reasoning.
The principle is older than agents: judgment needs a single accountable owner. Distribute a decision across a committee, with human or agent members, and every member can be locally right while the outcome is incoherent: correct cause identified, disconnected action recommended, an outlook that follows from neither. The current architectural expression of the principle is one agent that owns the reasoning end to end; it may delegate focused investigations to sub-agents and machinery, but delegations return results, never conclusions. Judgment is probably not owned by one person in your group. But folks take ownership of decisions. Clarifying who is the owner, decider, one responsible makes it easy to identify judgements. Just like for humans, having this charted out makes reasoning much clearer for agents.
Failure pattern
Each step in the chain is defensible and the whole is incoherent. The diagnosis names the real cause; the recommendation addresses a different one; the forecast assumes the recommendation worked. No single mind, whether human or agent, ever held the end-to-end picture, so nobody notices the seams. Coherence failures are the hardest kind to catch, because every component passes its own review.
The coherence-probe test
Take a recent multi-step output from an agent pipeline, or from your human process. Read only the conclusion chain: does the recommended action actually address the identified cause? Does the projected outcome follow from the action? Then ask the sharper question: who owned this end to end? If the answer is a list of names, the answer is nobody.
Passing the bar
One named owner for each decision class, human and agent alike. In agent architecture: a single reasoning agent holding the full context, with sub-agents scoped to investigations whose results, not whose judgments, flow back. The delegation boundary is written down, like everything else in this guide.
The loop: how you know any of it is working
Evals & feedback
Every layer above feeds this one. This one points back at the layer that failed.
Most teams discover their agent was wrong the way they discover a roof leak: from underneath, during a storm, in front of a customer. But notice what well-built agent systems already do at runtime: pull a hypothesis, test it against real data, mark it supported or contradicted, move on. That loop is why they work. This layer runs the same loop over the whole stack. The payoff of process order is that failures become addressable: a wrong tradeoff points at 01a, an invented relationship at 02, noise-chasing at 03, a rescue at 04, an incoherent chain at 05. Every failure becomes a graded case; the case points at the object that caused it; the eval set grows from your operations instead of someone's imagination.
Failure pattern
"The agent seems better lately." With no baseline or metric, you have no way to distinguish improvement from luck. So the program can't defend its budget, and quietly dies. Meanwhile regressions are invisible: an agent that got worse at one edge case looks identical to one that didn't, until the edge case shows up in front of a customer.
The silent-failure-probe test
Take a real agent mistake from the last month and ask one question: how did you find out? If the answer is a customer, an escalation, or someone happening to notice, you don't have a feedback loop. You have an incident process. Then ask the harder version: how many like it are running right now that nobody has caught?
Passing the bar
A graded set of real cases with known-good answers: rescues from Layer 04, divergences from 01b, coherence failures from 05. Rerun whenever the surfaces beneath them change. Someone owns the number. Report regularly. Track the direction of change. And with each failing case, trace to the specific layer and object that caused it. That traceability is the whole reason to structure the layers this way.
The audit is the scored, full-coverage version of these seven tests.
Request an Agent-Readiness Audit →The honest problem
Agent-readiness has no mature measurement standard. The benchmarks the field publishes measure model capability, not organizational legibility. No public benchmark tells you whether your company, specifically, can be read. The semantic-platform vendors are right about the problem and sell tooling for the last 20% of it. The other 80% has no product category: the ontology, the governed vocabulary, the reasoning carried into objects, the boundaries and ownership the middle layers describe. That is why it has no owner inside most org charts.
We don't claim a certification that doesn't exist. We measure direction of change on the seven tests above, and we show our work: the rubric is part of the audit deliverable. And clients keep the rubric.
Agent-readiness is a vision-fidelity problem, not a documentation problem. Write more docs and agents keep guessing. Carry the vision into the objects, and agents stop needing to.
How to work with us
Each engagement starts from whichever layer the tests say you're stuck in.
The Agent-Readiness Audit
A fixed-scope, fixed-price diagnostic. You get: a scored map of all six layers against our rubric (which you keep); the ten-term diff run across your actual systems, with every divergence documented; a rescue-count baseline on named workflows; a map of which steps in those workflows are deterministic and currently left to agent judgment; and three data contracts your leadership needs to ratify to unblock the program. The fastest way to know where you stand.
Fixed scope, fixed price
The Semantic Architecture Engagement
A defined project to close the gaps the audit found: principles written to be cited, the vocabulary contracted and the domain model ratified as a control surface for agent reasoning, the deterministic boundary drawn and encoded as machinery, workflows rebuilt as execution surfaces from observed runs, and judgment ownership made explicit in the architecture. It integrates with whatever platform you run, and your team owns it after we leave. The project is scoped from the audit, and we bring in senior specialists as the work requires.
Defined project, scoped from the audit
Fractional Knowledge Engineering
Ongoing senior partnership for organizations scaling agent use, where the semantic layer needs continuous architecture, governance, and evals. Not a one-time fix. Monthly retainer, with quarterly leadership briefings that translate rescue counts and consistency metrics into P&L language.
Monthly retainer
Julee Burdekin, founder of Allostasis.
If you've run the tests, we're happy to look at the results with you.
A 30-minute conversation is usually enough to tell whether it's worth going further. Bring the result that surprised you.
Request an Agent-Readiness Audit