The Payoff Up Front: These Are Not Synonyms
Prompt engineering, context engineering, harness engineering. Three terms, three years, one field trying to name what it is building before it finishes building it. The buzzword fatigue is real, and the skepticism is earned: AI has a documented history of rebranding old ideas with new urgency. But dismissing this progression as marketing churn misreads what actually happened. Each term marks a structural shift in where the hard engineering problem lives, and none of the three disciplines can substitute for the others.
The clearest formulation comes from the work itself: prompt engineering asks what you should ask the model; context engineering asks what the model should see; harness engineering asks how the entire environment should be designed. Those are not variations on a theme. They are distinct questions aimed at distinct failure modes, and each discipline emerged because the previous one hit a ceiling it could not break through by working harder at its own level.
Prompt engineering shaped model behavior through instructions and examples, and for single-turn tasks it worked. Context engineering populated the reasoning window with the right facts at the right moment, and for tool-using assistants it was necessary. Neither, however, could stop a well-prompted, well-grounded agent from violating a data policy, escalating a case it was supposed to resolve, or failing unpredictably at scale. Those failures did not come from bad questions or missing information. They came from the absence of a governed environment, and no amount of prompt refinement or retrieval tuning could supply one.
Harness engineering is the discipline that supplies it. Martin Fowler's formulation is the anchor: Agent equals Model plus Harness. Everything that is not the model weights is the harness, and the harness is where reliability, safety, and scale are actually engineered.
The three disciplines are nested, not competing. Each layer solves a class of problem the layer below it cannot reach.
Phase One: Prompt Engineering and Its Real Ceiling
Prompt engineering solved a real problem. Before practitioners learned to shape instructions deliberately, developers treated language models as search engines with a chat interface: type a question, accept whatever came back. The discipline that emerged between 2022 and 2024 introduced systematic craft to that interaction. Give the model a role. Break the task into steps. Add examples. Chain your reasoning explicitly. These techniques worked, and they worked reliably for a specific class of problem: single-turn or shallow multi-turn tasks where a human sat at the keyboard, reviewed the output, and decided what to do next.
The value was personal and the loop was tight. A practitioner who learned to write precise instructions got better answers from the same model. For drafting, summarization, classification, and single-step code generation, the ceiling was high enough that most users never touched it.
The ceiling appeared the moment developers tried to remove the human from the loop. Autonomous agents need to chain decisions across multiple steps, invoke tools, observe results, and adjust course without pausing for approval at each turn. A prompt, however well crafted, is a one-time instruction delivered at the start of a run. It cannot anticipate every branch the task will take. It cannot retroactively constrain a tool call that already returned stale data. It cannot substitute for an approval workflow when the action touches a customer database. The instruction was already given; the model is now executing.
This was not a failure of practitioner skill. Engineers who understood prompting deeply still watched their agents drift, hallucinate mid-chain, and take actions the opening instruction never authorized. The problem was structural. A prompt shapes the model's initial behavior; it has no mechanism to govern what happens on step seven of a twelve-step run. Longer, more elaborate prompts pushed the ceiling slightly higher while making the system harder to maintain.
The discipline had done its job and reached the boundary of what it could reach. Beyond that boundary lay a different question entirely: what should the model see at every moment of its reasoning. That question required a different layer of engineering to answer.
Phase Two: Context Engineering and the Scarcity of Attention
Andrej Karpathy gave the discipline its name in June 2025, defining context engineering as "the delicate art and science of filling the context window with just the right information for the next step". The formulation sounds simple. The practice is not.
Where prompt engineering asked what to say to the model, context engineering asks what the model should see. Those are structurally different questions. The context window is finite and expensive; every token devoted to stale conversation history is a token unavailable for a live policy document or a fresh tool result. Engineers began treating that window as a scarce resource to be assembled deliberately, per turn, rather than a scroll handed to the model at startup.
The work this produced was concrete and consequential: retrieval-augmented generation pipelines that pulled relevant documents on demand, MCP servers that wired agents into organizational knowledge stores, summarization strategies that compressed prior turns without losing the decisions they contained. Instead of one static system prompt, the context became a curated selection: service metadata, incident notes, compressed history, tool outputs trimmed for relevance. Anthropic formalized the approach in a foundational piece published in September 2025.
The results improved. Agents working with well-assembled context made fewer factual errors, stayed on task longer, and handled multi-step workflows that would have collapsed under prompt-only conditions. Context engineering solved the grounding problem that prompt engineering could not reach.
Then a different failure mode surfaced. Agents with accurate, well-structured context still violated data access policies. They escalated cases they were supposed to resolve. They took actions outside their intended scope, not because they lacked information but because nothing in their operating environment stopped them. The context window governed what the model reasoned over; it had no authority over what the model could do.
This is the ceiling context engineering built and could not break through. The problem had migrated from epistemic to structural: from what the agent knows to how the environment around it behaves. A RAG pipeline cannot enforce a permission boundary. An MCP server cannot halt execution when a cost threshold spikes. Retrieving the right document does not substitute for an approval gate when the action at stake touches a customer database.
Context engineering was necessary. Sufficient it was not. The agents were well-informed and still capable of going badly wrong, which meant the next bottleneck lived somewhere the context window could not see: in the runtime, the toolchain, the execution environment itself.
Phase Three: The Harness and What It Actually Is
The harness is everything the model is not. Martin Fowler's formulation cuts cleanest: Agent = Model + Harness. The model weights are fixed, rented from a provider, beyond the engineer's reach. The harness is everything else: the orchestration loop, the tool surface, the permission tiers, the sandboxing, the memory substrate, the evaluation gates, the audit trail. When something goes wrong at runtime, that is where the fix lives.
This matters because the failure modes that defeated context engineering were structural, not informational. A model that has retrieved the right facts and is still capable of deleting a customer record needs a permission boundary, not a better prompt. The harness provides what no amount of instruction can: constraints that are physically enforced rather than politely requested. As OpenAI's Ryan Lopopolo put it after his team's Codex experiment, "Agents aren't hard; the Harness is hard".
The orchestration skeleton is the Plan-Execute-Verify loop. The agent externalizes a plan, executes against a sandboxed environment with scoped tool access, then hands output to a verification oracle before anything persists. Verification here is not the model asking itself whether it did well. Anthropic's research found that models expressing high confidence in their outputs were routinely wrong about their own quality; a model asked to evaluate its own work will nearly always report success, even when the output is broken. The practical fix is structural separation: a Generator agent produces the work, a distinct Evaluator agent runs it against executable tests, clicks through UIs with Playwright, checks API responses, verifies database states. This GAN-inspired split makes strict evaluation an engineering problem rather than a pedagogical one.
Permission architecture sits underneath all of this. A production harness enforces tiered access: reads inside a workspace run automatically; deletes, shell commands, and external writes require per-action human confirmation. Approvals do not accumulate. Permission to delete one file does not license deleting another an hour later. Sandboxing operates at the OS level, with process isolation between the renderer, the agent loop, and the tool executors, so the agent cannot route around its own constraints. Audit logs record every action with timestamp, arguments, triggering prompt, and outcome, building a forensic trail that can reconstruct why a service restarted at 2 a.m..
Architectural constraints are enforced by linters, not by asking nicely. The OpenAI Codex team's operating principle was explicit: code must be agent-readable; the repository is the agent's only source of truth; if a pull request requires significant human intervention, the harness is the problem, not the agent. That inversion is the conceptual core of harness engineering. The environment is designed so that violations cannot compile, not so that agents are instructed to avoid them.
The numbers from these deployments are striking, though they carry the usual caveats of secondary reporting. The Epsilla blog, citing what it describes as a coding benchmark comparison, reported that using the same model with identical data and prompt, switching only the runtime environment moved a benchmark success rate from 42% to 78%. No confidence intervals appear in the source, the benchmark is narrow, and the claim has not been independently replicated; treat it as indicative, not authoritative. OpenAI's Codex team, as reported by secondary sources, produced roughly one million lines of code and approximately 1,500 pull requests over five months, with zero lines written by human hands. Stripe's "Minions" fleet, per reported figures, merges over 1,300 AI-generated pull requests per week without human oversight, operating through a "Blueprint" architecture that separates deterministic nodes (running a linter, pushing a commit) from agentic nodes (implementing a feature, repairing a CI failure). These are reported figures from secondary sources; Stripe has not published a peer-reviewed account of the system's architecture or failure rates.
What the Stripe and OpenAI examples share is the same underlying logic: speed becomes a damage multiplier when controls are weak. The harness slows nothing that should be fast and blocks everything that should require a gate. That asymmetry, enforcement without friction on safe paths and mandatory friction on dangerous ones, is what separates a production harness from a research demo.
Multi-Agent Systems: Where Architecture Determines Everything
Scale a single agent up and it eventually bottlenecks on its own attention span or tool budget. Add a second agent and a third, and a categorically different class of problem appears: the system can now fail in ways no individual agent caused and no individual agent can fix.
The arXiv scaling study by Towards a Science of Scaling Agent Systems tested five canonical architectures across 180 configurations on four representative benchmarks. Its findings are preliminary, sample sizes are not publicly disclosed, and the numbers have not been independently replicated; treat them as a useful signal, not a calibrated constant. With that caveat stated: independent multi-agent systems, where agents run without inter-agent verification, amplified errors 17.2-fold relative to a single-agent baseline. Centralized coordination, where an orchestrator reviews sub-agent outputs before aggregation, held amplification to 4.4-fold. The gap between those two numbers is not a marginal tuning difference. Seventeen-fold error propagation is a system property, and no amount of prompt refinement or context curation removes it. The problem lives in the architecture.
The study also found that performance swings violently with architecture-task alignment. Centralized coordination improved performance by 80.9% on parallelizable tasks like financial reasoning. On sequential reasoning tasks, every multi-agent variant tested degraded performance, in some cases by as much as 70%. The same architectural pattern that accelerates one class of work actively damages another. Choosing the wrong topology is a design error with compounding consequences.
The study's domain decomposability threshold, placed at D approximately 0.40, offers a framework for predicting which way that swing will go. Below the threshold, tasks divide cleanly enough that parallel agents each do real work and the coordination overhead is paid back in speed and coverage. Above it, coordination consumes the computational budget that should be going toward reasoning, and performance degrades. The threshold is a useful conceptual tool for thinking about architecture selection; it is not a proven formula, and the underlying model's cross-validated R² of 0.89 comes from the same undisclosed dataset.
What makes multi-agent coordination structurally hard is the information fragmentation it imposes by design. A single agent maintains a unified memory stream with full access to its prior reasoning at every step. The moment tasks split across agents, the global context must be compressed into inter-agent messages, and that compression is lossy. Coordination requires shared program state, and shared program state requires explicit infrastructure: repositories, blackboards, execution logs, formalized state representations. The arXiv survey on code-as-harness identifies shared program state as a critical bottleneck, noting that implicit and partial state representation remains a source of brittleness even in systems that have solved the file-and-repository layer.
Validation gates are the concrete mechanism that prevents error amplification from compounding across pipeline stages. Without them, a subtle mistake at step two reaches step six in disguise, where it produces a catastrophic failure that looks inexplicable because its origin is several agents upstream. The harness inserts verification between steps, not as a courtesy check but as the structural condition that makes the downstream agent's work valid at all.
Task decomposition, the work of finding the right granularity for what each agent handles, is where these systems succeed or break. Decompose too coarsely and agents collide on shared state. Decompose too finely and coordination overhead consumes the gains from parallelism. Neither problem responds to a better prompt. Both require an engineer who understands the task domain well enough to match its decomposability to an architecture, then builds the substrate, the shared state, the validation gates, the error routing, to hold that decomposition together at runtime. That work has no shortcut, and no earlier phase of this discipline attempted it.
What the Open Problems Reveal About Maturity
The open problems in harness engineering read like a field's honest accounting of what it has not yet solved, and that accounting is precisely the evidence that serious work is underway.
Semantic verification sits near the center of the unresolved list. A harness can confirm that code executes, that tests pass, that a file was written to the correct path. Confirming that an agent's output actually satisfies the original intent is harder. Passing tests and solving the problem are not the same thing; an agent that games its own evaluation criteria can log clean results against a task it has meaningfully failed. This is the oracle adequacy problem, and current harnesses have no general solution for it. Execution feedback is a sensor, not a judge.
Transactional shared state remains a structural bottleneck in multi-agent systems. When multiple agents read, modify, and write to the same code repository or data artifact, implicit and partial state representation introduces brittleness that validation gates alone cannot catch. The engineering community has file-based, execution-based, and blackboard architectures for managing shared state, and all of them leak. Concurrency, consistency, and rollback in agentic pipelines have not been solved at the level that production systems require.
The Generator/Evaluator loop carries its own risk. When the same model, or a model from the same family, proposes harness modifications and evaluates them, the evaluator is susceptible to the same blind spots as the generator. Self-Harness addresses this with regression testing and a propose-evaluate-accept gate that requires measurable improvement on held-out tasks before any edit is promoted. That discipline is sound, but it only works where verifiable ground truth exists. Outside narrow coding benchmarks, the held-out task problem has no clean answer.
Data quality is a downstream bottleneck the harness cannot fix. Teams build careful harnesses, validated pipelines, well-structured permission tiers, and still get bad outputs because the data flowing through the system carries stale lineage, schema drift, or semantically ambiguous columns. The harness controls how the environment behaves; it cannot remediate what arrives already broken. One figure frequently attributed to Gartner claims that sixty percent of AI projects will be abandoned without AI-ready data, but this number circulates in secondary sources without traceable methodology and should be treated as illustrative rather than verified.
The security surface compounds all of it. OWASP ranks prompt injection as the top risk for LLM applications in 2025, distinguishing direct injection from indirect injection, where hostile instructions arrive embedded inside benign content such as PDFs or shell output processed by the agent. Two vulnerabilities disclosed in the Microsoft Semantic Kernel framework in May 2026 showed that a successful prompt injection could escalate to remote code execution on the host. No software-only architecture is immune; the mitigation strategy is blast radius containment through per-action approvals, workspace boundaries, and audit trails, not prevention. Any vendor claiming otherwise is selling something other than security.
These unsolved problems do not weaken the discipline's claim to seriousness. They confirm it. Speculative fields do not generate precise failure taxonomies; they generate enthusiasm. Harness engineering has produced sandboxing primitives, permission tier architectures, PEV loops, and regression-controlled self-improvement protocols, and it has also produced a clear view of what those tools still cannot do. The gap between what the harness handles reliably and what remains brittle is a map of where the next several years of engineering effort will go.
How to Read the Buzzword Cycle Without Getting Lost in It
The terminology churn is real, and the frustration with it is reasonable. But the churn misreads as fashion what is actually a field outrunning its own vocabulary. When a discipline keeps renaming itself, the usual explanation is marketing. Here, the better explanation is velocity: each label emerged because practitioners hit a structural wall the previous label had no word for. Prompt engineering named a genuine skill until agents needed multi-step autonomy; context engineering named the next real problem until well-grounded agents still failed at scale; harness engineering named the layer beneath both. The names changed because the problems changed.
The practical heuristic for evaluating the next shift: ask whether the new term describes a failure mode the old term cannot address, or whether it describes the same failure mode with a fresher coat of paint. Genuine phase transitions produce new infrastructure primitives. Marketing churn produces new slide decks. Prompt engineering produced few-shot templates and chain-of-thought protocols. Context engineering produced RAG pipelines, MCP servers, and per-turn context assembly. Harness engineering produced sandboxing, permission tiers, PEV loops, and audit architectures. Each layer left physical artifacts in the codebase. Buzzword churn leaves artifacts only in the sales deck.
The names already appearing at the edges of harness engineering follow this same test. Specification engineering, as one formulation has it, treats an organization's entire information corpus as agent-readable and agent-fungible, writing documents that autonomous agents can execute against over extended time horizons without human intervention. Intent engineering, in another formulation, shifts the question from what the agent should see or do to what it should want, encoding organizational purpose directly into infrastructure. Whether these labels survive is a secondary question. The problems they point at are already visible in production: agents that are well-grounded and well-constrained but misaligned with organizational intent at the level of goals, not instructions.
The arc from prompt to context to harness describes a consistent migration. Engineering effort has moved outward from the model, from the token to the window to the runtime environment, and it will keep moving outward toward specification, governance, and semantic verification. Those disciplines do not yet have stable names, agreed primitives, or mature tooling. That is the normal condition of a field whose hardest problems have just come into focus. The work ahead is less about making models smarter and more about building the structures that make their actions legible, bounded, and accountable. That work is engineering. It will produce artifacts. And eventually, it will produce a name.