Context Is Part of an Agent's Authority

A developer released Token-Bleed R5, a synthetic experiment showing that governed context selection uses 96.9% to 97.9% fewer prompt tokens and achieves higher F1 than raw full-context stuffing. However, the preregistered claim that governance earned its cost against lexical filtering failed, as governed selection consumed 6.94 times more tokens than the lexical baseline, exceeding the maximum. The developer argues that an agent's context is part of its authority, and that information scope should be governed with the same discipline as action permissions.

Technical source: Token-Bleed R5 release https://github.com/msaleme/token-bleed-benchmark/releases/tag/r5-results-2026-08-17 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. 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. 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. An EAA design should logically separate four responsibilities: 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. For each agent workflow, begin with the least-complex, policy-permitted context route that could credibly meet the decision's quality requirements. The goal is not more governance. The goal is decision-useful context with a defensible cost. 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. 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.