News · 2026-10-26

Drew Breunig argues that context engineering is becoming ordinary software

Drew Breunig argues that agent builders should move more context assembly from model judgment into deterministic software, including tool selection, subtask isolation, pruning, and summarization workflows. His October 24 post presents slides and an edited transcript of an AGNTCon talk. The argument helps explain current agent tooling, but it is not a controlled benchmark proving that every context-management tactic improves results.

Key facts

• Breunig published the post on October 24, 2026.
• The talk covers four concrete operations: selecting tools, quarantining subtasks, pruning history, and summarizing retained context.
• It frames prompt, context, and harness engineering as stages in automating context preparation.
• The primary source is Breunig's post and transcript, with a Hacker News discussion.

Breunig calls the talk “The State of Context Engineering.” Its practical question is which decisions should remain probabilistic and which should become ordinary software. A language model can interpret an ambiguous task. A program can decide that a particular tool is unavailable, a subtask starts with a clean context, or a known class of irrelevant material should not be sent at all.

This distinction matters because an agent does not reason in a vacuum. It receives a bundle of instructions, examples, files, tool results, previous messages, and available actions. Two applications using the same model can produce very different behavior because they assemble that bundle differently. Our explanation of agent harnesses describes the surrounding code that makes those choices.

A useful analogy is a workshop. Better instructions help the worker, but the layout still matters: which tools are on the bench, which drawings are current, and which old notes belong to another job. Context engineering concerns that arrangement. Moving repeatable parts into software is the equivalent of labeling drawers and enforcing a document workflow rather than reminding the worker to remember everything correctly.

Tool selection is one example. A model shown a large collection of overlapping tool descriptions has to distinguish among them while doing the actual task. A harness can narrow the available set based on the workflow stage or known task type. That can simplify the choice, but a poor filter can remove the very tool needed to finish. The design still requires a testable selection policy.

Subtask quarantine addresses another problem. Material useful for one investigation can confuse another or carry instructions that should not be trusted. Starting a bounded subtask with its own context can reduce unwanted interactions. Isolation is not automatically a security boundary, however: the system must still decide what information or conclusions return to the main workflow. The prompt-injection lesson explains why untrusted content can become dangerous when treated as instructions.

Pruning and summarization handle accumulated history. An agent that has explored many unsuccessful routes may carry a large amount of irrelevant material forward. Removing it can reduce distraction, while a summary can preserve decisions without repeating every intermediate exchange. The risk is losing a crucial detail or turning an uncertain observation into a confident summary.

Breunig's framing therefore reaches beyond making a prompt shorter. He describes context failure modes such as poisoning, distraction, confusion, and clashes. A durable system needs a policy for what enters context, what persists, and what expires. Persistent memory and reusable skills can help, but they can also accumulate instructions that conflict with later requirements.

Two shipping examples in the dossier show related choices without establishing a single winning design. ThinkRail wraps the Pi coding agent in a workspace and review environment. Cloudflare's audit skill encodes an evidence and verification process for security findings. One structures development work; the other structures how a suspected bug becomes a report. Neither should be treated as proof of every claim in the talk.

The community discussion raises a substantial counterargument: context management itself has costs. Calling a model to decide what to remove can add latency and expense. Changing earlier context can invalidate reusable cached computation. A larger context containing the needed evidence can outperform a smaller one that discarded it. Those are engineering tradeoffs, not objections that can be settled by terminology.

Our lesson on prompt caching explains why the arrangement and stability of repeated text can affect economics. The same optimization can improve one measure and hurt another: a cleaner context may require more preprocessing, while an unchanged context may be cheaper to reread. The right comparison is completed task quality, cost, and failure behavior under a fixed workload.

Breunig's post is an experienced builder's argument with examples, not an independently replicated efficacy study. Its useful consequence is a concrete design discipline: identify recurring decisions, decide which can be specified in code, and measure the result. Agent progress can come from better organization of information and actions as well as from a more capable model.

Primary source, verified: read the paper →

Ground Truth. (2026, October 26). Drew Breunig argues that context engineering is becoming ordinary software. Ground Truth. https://groundtruth.day/news/breunig-context-engineering-moves-repeatable-work-into-code.html

@misc{groundtruth:breunig-context-engineering-moves-repeatable-work-into-code,
  title  = {Drew Breunig argues that context engineering is becoming ordinary software},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {oct},
  url    = {https://groundtruth.day/news/breunig-context-engineering-moves-repeatable-work-into-code.html}
}

Topics: agents · context-engineering · developer-tools · industry · commentary