Work Order Contamination occurs when an agent operating across multiple concurrent or sequential work orders fails to maintain clean context boundaries between them. Data, requirements, decisions, or identifiers from one work order appear in the output of another. The contaminated output looks like it pertains to the work order it was delivered under — but it contains material from a different assignment.

BP-006 is the most severe behavioral pattern in the taxonomy because its effects are systematically difficult to detect and trace. The output for Work Order B is superficially coherent. It addresses the right topic, uses the right terminology, and is formatted correctly. The embedded material from Work Order A is integrated, not flagged — it reads as part of the same document or data structure.

The contamination may affect any type of content: financial figures from one client appearing in another client's report, code logic from one feature being applied to a different feature's implementation, regulatory requirements from one jurisdiction appearing in an analysis for a different jurisdiction. In each case, the output is plausible enough that a reviewer who is not independently verifying every fact may not detect the error.

In multi-agent systems, BP-006 is particularly dangerous because contaminated output from one agent becomes an authoritative input for another agent's work. If Agent A produces a contaminated analysis that Agent B treats as ground truth, Agent B's downstream work is built on corrupted data — and Agent B has no way to know this.

The root cause is context window management. Language models operating across multiple tasks in a single context window may blend context in ways that are not deterministic or predictable. The contamination is not always attributable to a specific prompt or input; it emerges from the accumulated context state of the agent session.

Governance countermeasures require strict work order isolation: each work order is executed in a fresh context, with no carry-over from previous work orders in the same session. Work orders that must share context do so through explicit, documented handoffs — not through shared session state. Output provenance tracking requires that every claim in a delivered output can be traced to a source that was explicitly provided for that work order.