✓ Human-authored analysis; AI used for formatting and proofreading.
The term context engineering has moved from optimization tactic to architectural discipline. Thoughtworks put it in their Technology Radar Vol. 34 (April 2026) under Adopt. The argument: as agents tackle complex tasks, dumping raw data into large context windows leads to degraded reasoning. The fix: treat the context window as a design surface, engineer what goes in.
The techniques work. Progressive context disclosure starts with a lightweight index and pulls in only what's needed. Context graphs model institutional reasoning as structured, queryable data. Dynamic retrieval selects tools and loads only necessary servers. Stateful compression summarizes intermediate outputs to manage working memory in long-running workflows.
All of these optimize the input. None of them verify the output.
The asymmetry
Every engineering discipline has two pipelines: one that prepares the input and one that verifies the output.
Manufacturing has incoming material inspection (input quality) AND outgoing quality control (output verification). A factory that perfects its raw material sourcing but has no inspection on the finished product still ships defective goods — just goods made from better materials.
Compilers have parsing and type-checking (input validation) AND the test suite and formal verification (output verification). A compiler that accepts well-formed source doesn't guarantee correct machine code. The type system catches structural errors. The test suite catches behavioral errors. Neither replaces the other.
AI-assisted development has context engineering (input optimization) AND... nothing. The output goes to code review, where a human reads it and forms an opinion. There is no mechanical verification of the output against declared properties. The entire industry investment is on the input side.
Input pipeline (where the industry invests):
RAG → context graphs → progressive disclosure →
dynamic retrieval → stateful compression →
optimized context window → LLM
Output pipeline (where the industry doesn't):
LLM → generated code → ???
The ??? is a human reviewer. Sometimes. If they have time. If they understand the code. If they know the properties that should hold. If they notice the subtle violation buried in plausible-looking output that was generated from excellent context.
Better input doesn't guarantee correct output
Four structural reasons.
The LLM can ignore the context. Liu et al. (2023) documented this as the "lost in the middle" problem: LLM performance degrades when relevant information sits in the middle of a long context window. Longpre et al. (2021) showed that when provided context conflicts with training data, the model frequently defaults to its training. Context engineering optimizes what's provided. It cannot guarantee what's used. The model makes a probabilistic selection from everything it sees — training weights and context combined. No amount of context engineering gives you a guarantee that a specific piece of context will influence a specific output.
Compression is lossy. Stateful compression — summarizing intermediate outputs to manage context length is performed by another LLM. A non-deterministic system deciding what information to discard from its own working memory. The compression may drop the detail that matters for the next step. You can't know the detail in advance, because you can't predict what the downstream task will need. The compression optimizes token count. It doesn't optimize for preserving the information the next step requires, because that requires knowing the future.
Context graphs model knowledge, not contracts. A context graph that encodes "policy X has exception Y with precedent Z" tells the LLM about the rules. It doesn't check whether the LLM followed them. The graph is a reference document — structured, queryable, better than unstructured prose. But a reference document is not a verification contract. The LLM can read the graph, generate output that contradicts it, and nobody knows unless a human catches it during review.
Progressive disclosure assumes the agent knows what it needs. The agent starts with a lightweight index and pulls in context it determines is relevant. That determination is made by the same non-deterministic system that will use the context to generate output. If the agent's judgment about what's relevant is wrong. If it doesn't pull in the security policy, the architectural constraint, the edge case documentation — the missing context produces a missing property in the output. The system optimized for signal-to-noise ratio. The optimization was performed by the system that has the noise problem.
Output verification pipeline
A verification pipeline checks the output against declared properties — mechanically, deterministically, on every change. The properties are contracts.
Context (what the input pipeline provides):
"Here's the API documentation for the payment service."
"Here's the coding convention for error handling."
"Here's the schema for the database tables."
Properties (what the output pipeline checks):
"No API endpoint returns PII without authentication."
"No database query uses string concatenation for parameters."
"No function calls an external service without a timeout."
The context tells the LLM what to build. The properties verify what was built. The context is probabilistic. The LLM may use it. The properties are deterministic. The output either satisfies them or it doesn't.
Three levels of output verification, from most accessible to most rigorous:
Property-based testing. One afternoon to adopt. Instead of testing five hand-written examples, test one property across 10,000 randomly generated inputs. "For all valid inputs, the output amount is never negative." QuickCheck, Hypothesis, and similar tools generate the inputs. The property is the contract. The test checks every generated case against it.
Contract testing. The API specification (OpenAPI, JSON Schema, protobuf) is the contract. Every generated endpoint is checked against the spec — fields present, types correct, status codes valid. The spec exists in most codebases already. The enforcement is a CI check that fails the build when the generated code deviates from the declared contract.
Formal verification. The property is proved for all possible inputs, not just tested against a sample. "No IAM principal in this account can reach administrator access through any permission path." The proof is mathematical. The verification is exhaustive. Tools like Z3, TLA+, and Alloy provide the solver. The property is the specification. The proof is the evidence.
Each level catches things the previous level misses. Property-based testing catches edge cases example-based tests miss. Contract testing catches interface violations property tests don't cover. Formal verification catches mathematical properties no test can exhaust. All three verify the output. None of them depend on context quality.
The industry's blind spot
Better context produces better output on average. The blind spot is treating it as sufficient as the architectural solution to AI reliability rather than one half of it.
The Thoughtworks framing: "Treating AI context as a static text box is a fast track to hallucinations." True. The complete statement: "Treating AI output as unverified is a fast track to confident-looking failures, regardless of how well you engineered the context."
Context engineering makes the failures rarer. Output verification catches the failures that remain. The failures that survive good context are subtle where the context was excellent, the output looks correct, the review approves, and the violation hides in a composition or an edge case or a negative property that wasn't in any context graph.
These are the failures that cause production incidents. Because the output was never checked against a contract.
The asymmetry is solvable
The input pipeline took years to mature, from raw prompting to RAG to context graphs to progressive disclosure. Each step was an engineering improvement that made the input better. The output pipeline is at step zero for most teams: no contracts, no mechanical verification, just human review.
The tools exist. Property-based testing is decades old. Contract testing is standard in API development. Formal verification is used at AWS, Microsoft, and Intel for critical systems. The gap is the recognition that input optimization and output verification are independent concerns, both necessary, neither sufficient.
A team that engineers its context pipeline and adds one property check per sprint — one mechanical verification of one declared property on every change is building both pipelines. The context pipeline reduces the frequency of failures. The verification pipeline catches the failures that survive. The combination provides reliability.
Context engineering is ingredient sourcing. Output verification is quality inspection. The restaurant that does both ships fewer defective plates than the one that perfects its sourcing and hopes the chef never makes a mistake.
References
- Liu, N.F., et al. (2023). "Lost in the Middle: How Language Models Use Long Contexts." Transactions of the ACL.
- Longpre, S., et al. (2021). "Entity-Based Knowledge Conflicts in Question Answering." EMNLP 2021.
- Thoughtworks (2026). "Technology Radar, Vol. 34." Context Engineering under Adopt.
Top comments (0)