Technical source: Token-Bleed R5 release
Enterprise AI programs often treat context as a prompt-engineering problem: retrieve more documents, add more records, and let the model sort it out. That is backwards.
The information an agent receives determines what it can infer, combine, and disclose. An agent's effective authority is therefore shaped by both its information scope and its permitted actions: context governs the former; capability controls govern the latter.
Context does not grant permission to dispatch power, change a price, or execute a transaction. It expands what the agent can know, infer, and disclose, and therefore its practical power.
Too little context is not neutral either: omitted constraints, exceptions, or dependencies can make a confident recommendation wrong. The architectural objective is therefore not minimum context, but minimum sufficient context.
We spend substantial time defining action authority: which tools an agent may call, which systems it may reach, and which approvals it needs before a change takes effect. Information authority deserves the same discipline. Before an agent decides, architecture must establish what information it is permitted to see and what it actually needs for this decision.
The full-context default is not neutral
Sending every available record to a model feels safe because nothing has been left out. In practice, it can be expensive, dilute the relevant signal, make the decision harder to review, and expand the information the system can combine.
That does not mean every workload needs a complex governance layer. It means every workload needs a comparator.
In the retained Token-Bleed R5 synthetic experiment, compact governed selection used 96.9% to 97.9% fewer prompt tokens and achieved higher F1 than raw full-context stuffing on the frozen local configuration. The public record includes the frozen contract, preflight, retained-evidence decision pack, and hashes.
The more important finding is the limitation. Against a cheap lexical baseline, governed selection consumed 6.94 times as many prompt tokens on the holdout set, exceeding the preregistered maximum of three. The lexical route scored 0.000 F1 at every catalog size, so governed context won the quality comparison outright. Even so, the preregistered claim that governance earned its cost against lexical filtering failed. The frozen economic rule controlled the verdict; relaxing that ceiling after collection would have invalidated it. One caveat belongs with that zero: R5 used opaque physical names, where lexical matching has nothing to grip. On an earlier round with a lexically tractable catalog, the same baseline beat governed selection on both quality and cost.
That is exactly what useful architecture evidence should do. It should show where a method helps and where it has not yet earned the right to be the default.
Enterprise Agent Architecture needs a context plane
An EAA design should logically separate four responsibilities:
- Connection plane: APIs, events, and data services connect an agent to enterprise systems.
- Context plane: retrieval, classification, policy, lineage, and routing assemble the minimum sufficient, policy-permitted information set for the decision at hand.
- Capability plane: permissions and approvals govern what the agent may do next.
- Evidence plane: retained contracts, source references, tool traces, and human decisions make the outcome reviewable.
The context plane is not a technical ornament between a database and a model. It decides what the agent knows before it chooses a path. That makes it an authority control.
An agent's context is part of its authority.
A practical decision rule
For each agent workflow, begin with the least-complex, policy-permitted context route that could credibly meet the decision's quality requirements.
- If a simple filter captures the relevant records and produces a reviewable decision, use it.
- Add governed metadata when field names are ambiguous, business definitions matter, access policy must be enforced before the model sees data, lineage changes the answer, or the evidence trail itself is required.
- Compare the richer route with the cheap baseline. Measure quality, omission risk under routing misses, prompt cost, latency, and the work required to maintain the governed layer.
The goal is not more governance. The goal is decision-useful context with a defensible cost.
What this changes in industry workflows
In energy and utilities, an outage or maintenance exception agent may need weather, load, asset, work-order, and switching-constraint context to recommend whether to keep, reschedule, or escalate a window. It should not receive unrestricted operating data, and it should not obtain dispatch authority merely because it can assemble a recommendation; that authority must be separately granted, bounded, and evidenced.
In CPG and retail, a commercial exception agent may need store, SKU, promotion, inventory, cost, and service context to recommend a response. It should make the data basis, confidence, and required approver visible. It should not alter price or trade terms unless that capability has been separately authorized within explicit limits.
Those are not generic chatbot problems. They are architecture problems involving context, authority, and evidence.
The evidence boundary
R5 is a synthetic, named-endpoint runtime characterization. It is not a customer-data result, a production ROI study, or proof that governed context always beats a simple filter. The original raw report remains private because it contains host identifiers.
That boundary is part of the result, not a footnote. Enterprise agents deserve evidence that is as specific about its limits as it is about its gains.
Top comments (5)
The minimum sufficient context framing is the useful bit here. I like treating retrieval as authority, not plumbing. If an agent can read a customer record, a billing exception, and an internal note in the same run, it can synthesize something no single system explicitly exposed. That needs the same review surface as a tool permission.
The synthesis case is the one most access reviews cannot see. Each of those three reads is individually authorized, and the combination is what nobody approved. Row-level permissions answer "may it read this" and never answer "may it hold these together."
Your receipts-not-scores piece from last week is the same argument one layer up. A score reports that a system passed. A receipt lets someone else check what it passed and under which rule. Benchmarks and agents fail the same way when the artifact preserves the outcome but not the basis.
I hit the sharper version of that in my own benchmark. The preregistered cost rule rejected my result even though the quality comparison favored it. The receipt is the only reason that reads as a finding rather than an argument.
Code to reproduce the Token-Bleed R5 benchmark: github.com/msaleme/token-bleed-ben...
The four-plane split is the most useful framing I've seen for this. One addition from running a decision ledger on an agent system: the evidence plane should record inaction too. A policy block that prevents an action ("price change rejected - requires approval") is a decision, and if it leaves no record, a future review reads it as nothing having happened - indistinguishable from the agent never considering it. We made records unconditional: the trigger, the proposed action, and the outcome ("done", "blocked by policy", "deferred") all land in the log, including when nothing was executed. The evidence plane's job isn't just to preserve what happened - it's to make absence-of-action inspectable. That's the piece that turns "we have evidence" into "we have accountability".
You are right, and the piece does not say it. I wrote the evidence plane as retaining what the agent saw and did, which leaves refusals invisible.
The failure mode you name is worse than a gap. An unrecorded policy block and an agent that never considered the action produce identical evidence, so a reviewer cannot separate a control that fired from a control that was never reached. Absence of records starts reading as absence of risk.
It also breaks what the evidence is for. If you cannot show that the block happened, you cannot show that the boundary held.
Unconditional records covering trigger, proposed action, and outcome is the right shape, and "blocked by policy" has to be a first-class outcome rather than a missing row. I will carry that into the model rather than leave it in the comments.