The Context Laundering Problem
Context management is not a technical problem, it is an authority problem
August 8, 2026 · Jin Kuan
Product context rarely arrives at an agent in a clean and coherent manner.
A request may begin in a customer conversation, get translated into a product brief, become a Linear issue, acquire implementation notes in GitHub, and then pass through one or more agents before reaching the agent session expected to act on it.
Those scattered decisions, each made under incomplete information, once relied on a discerning developer to parse and reconcile them manually. Now they risk being fused into a coherent-looking AI-generated spec that smuggles provisional guesses into the mix alongside binding constraints.
This new class of AI context-control problem, as it turns out, is not entirely unprecedented. In this article we explore how an industry built on business-critical bookkeeping, finance, and its efforts to combat money laundering may provide us the conceptual tools to reframe this problem.
The agent POV
The industry is already working hard on context management—forgetting curves, ontology graphs, better retrieval. Those tools mostly assume that the inputs themselves can be trusted. But as we alluded to at the start, “product context” itself cannot always be taken word for word.
Consider a support ticket: “Customer requests role-based sharing of documents.”
By the time it reaches an agent, three statements sit next to each other in its context window:
- Customer (observation): “We need role-based sharing of documents.”
- PM (Linear): “Add a shareable invite link with role selection.”
- Engineer → agent: “Implement the Linear ticket in accordance with the existing authentication system.”
Notice how the three statements are not one brief: they are three different resolutions of the same feature, each at the granularity of a different stakeholder.
In a follow-up, the same customer complained that the roles they assigned to a teammate via the existing Members page were not automatically reflected in document sharing. How could that be?
It turns out, in our hypothetical scenario, the agent had built a fresh role-picker on the invite link—a second, parallel permission system that fulfills the PM’s request literally. It works fine in preliminary QA, but breaks in unexpected ways in production. Sounds familiar?
The spec was technically implemented, yet the implementation drifted from the intent, and the culprit lies in nuanced misinterpretation of product context. A developer would have paused at the PM’s ticket and sought clarification on what “an invite link with role selection” actually meant: whether it was a new set of permissions logic for document-sharing, or simply a UX feature grafted on top of the existing team management system.
A coding agent that is indifferent to making a one-liner change versus reinventing a module would happily go with the safest, most literal implementation.
Escaping the dichotomy
Could this be reliably fixed?
The design constraint to account for here is that agents are strong rule-followers, and they should be. Consider the downsides that come with making models less rigid in order to give agents better discernment, as seen with the rollout of Claude Opus 4.8 late May this year:
A routine rename-impact scan—“where is this symbol used?”—emitted 46,433 output tokens after 22 minutes and 43 seconds of thinking on medium effort, while the same prompt on Opus 4.6/4.7 ran in roughly 2,000–3,000 tokens (yurukusa, Two unrelated Claude Code Opus 4.8 failures);
Separately, the dynamic workflows functionality that grants the model ownership over its own workflows began ignoring
CLAUDE.mdand custom harness constraints in agentic sessions (anthropics/claude-code#66539)
Beyond these inconveniences, software engineering is unusually sensitive to small changes. Unsolicited cleverness here forces a harder question: when the model invents a product decision, who is held accountable?
To get out of this impasse, we have to go one layer up: resolve spec ambiguity during handoff to agents—not after—and carry those settled decisions forward to an agent that does exactly as instructed without inventing new product truths.
This is what we believe is underplayed in most AI context discourse: an upstream human provenance layer—who said what, carried across agent sessions.
Know-your-author
What we are proposing is not entirely novel. It is grounded in the KYC (Know-your-customer) mechanism put in place to combat money laundering in finance, a tried-and-tested system for credible attribution in critical business operations.
Finance faced a structurally similar problem: how to keep a complex web of funds flowing while still spotting bad actors and freezing only their transactions, keeping the rest intact. That maps to our present challenge: routing product context from disparate sources into the agent session that implements it, without letting unrelated claims pollute the overall specification.
So what are some insights we can derive from the hard-earned KYC mechanism that evolved over two decades?
First, know-your-customer starts at the entrypoint of funds: in TradFi, at account opening and the first regulated transfer; in crypto, at the on-ramp. Gate identity before value moves, and you can later replay the chain when an account is frozen—and see which funds, and which prior authorization, are actually compromised.
Second, when suspicious activity is detected, there is a protocol for human review. A suspicious payment may be placed in an exception queue with a debit block, so other accounts keep settling. An operator reviews the queue at a later time, confirms the provenance chain, and signs off on release, escalation, or a lasting freeze.
We took both lessons: attribute new context at the point they enter the system, and maintain a review queue that differentiates proposed decisions from binding ones.
During feature specification, Bicameral surfaces relevant context evidence to human developers—business objectives, technical rules, one-off exceptions—so they can decide which claims bind the product and whom to reach when claims conflict.
KYC works because it aligns incentives among the stakeholders involved, and the same holds true here:
AI can be trained to perform well on benchmarks, but the real world cannot be distilled into a single objective to be optimized. It is human judgment, driven by real stakes (e.g. profitability, reputation), that provides the irreplaceable creativity and critical thinking necessary for a good software product.
Capturing that judgment, as explicit human signoff on product context, is the missing ingredient that completes the picture.
Flipping the script
The pitfalls of the industry consensus to push for larger context windows become apparent through this lens. Functionally, it functions almost like a mixer that underpins money laundering: many deposits are pooled so no single output can be tied back to a source, destroying traceability in the process.
In the same vein, when used indiscriminately, context-compaction tools that only operate on the what without the who, if unintentionally, creates the conditions for context laundering: an offhand remark is distilled, stripped of the circumstance that produced it, treated as a general rule, and ends up governing architecture for months.
The better alternative is to treat context itself as a first-class resource to be governed: load the smallest set of binding context necessary for any particular task.
This is the librarian model we are building towards: AI serving discrete chunks of relevant human-authored context for reconciliation during implementation, rather than inventing new product decisions from a soup of context. For that to work, we cannot rely only on probabilistic model judgment; we need a deterministic mechanism for fast, reliable recall of past decisions.
Behind the scenes, we are applying techniques from formal verification, previously reserved for high-assurance enterprise systems, to make spec checking and fast recall accessible to all teams. The goal is to turn AI from a sycophantic coworker into a predictable tool developers can trust.
If you want to try the approach, sign up for our alpha.