Background. By 2022 two lines of work sat next to each other without touching. Chain-of-thought prompting had models reason in text, and other work had models emit actions against an environment or a search API.

Problem. Reasoning alone has nothing to check itself against, so an early wrong fact propagates confidently to the end. Acting alone has no plan, so a model cannot decide what to do next when an observation contradicts what it expected.

Key idea. Interleave the two in a single trace. The model writes a thought, then an action, then reads the resulting observation, then thinks again, all from one prompt. This interleaved reason/act loop is the mechanism, and nearly every agent framework is a variation on it.

Findings. On ALFWorld and WebShop, ReAct improved absolute task success over the paper's imitation- and reinforcement-learning baselines by 34 and 10 percentage points, respectively, using one or two in-context examples.

Why it matters. It fixes the shape of the object this course keeps taking apart: thought, action, observation, repeat. Planning, tool schemas, context management, and permission gates are all modifications to one position in that cycle, which is why the loop is worth reading in its original form.

Adoption. LangGraph ships and documents create_react_agent as a direct implementation of ReAct.

Background. By 2024 the default advice for building on an LLM was to adopt an agent framework, which hands you a planner, a memory abstraction, and a graph of steps before you have established that you need any of them.

Problem. Those abstractions hide the prompt and the tool definitions, which are the two things you actually have to debug. Complexity gets added because a pattern is available, not because a measurement showed the simpler version failing.

Key idea. Separate workflows, whose steps are fixed in code, from agents, which let the model choose the steps, then name the composable patterns worth reaching for: prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer. Add complexity only when it measurably improves outcomes.

Why it matters. It gives you a default that is hard to argue with, measure first and complicate second, and it supplies the names for the thing you built. A design review can then say which pattern is in use instead of calling every system an agent.

Background. An agent is often described as a model inside a tool-calling loop, but a deployed system also has to manage context, keep secrets away from the model, stop runaway executions, and decide whether the requested work actually happened.

Problem. Treating the loop as the whole agent leaves the model in charge of declaring success. In the post's example, GPT-3.5 Turbo reaches a Hacker News login page, performs no upvote, and reports that the task succeeded because nothing outside the model checks its claim.

Key idea. Define the harness as the runtime layer around the model, made of six parts: the tool registry, model, context management, guardrails, agent loop, and verification. Put deterministic limits, authentication, trace inspection, and retries in that layer, so failures become code changes to the harness rather than stronger wording in the prompt.

Why it matters. It separates the mechanism that proposes actions from the system that makes those actions reliable. The walkthrough holds the model and prompt fixed while adding guardrails, verification, and a login handler until the task completes and the trace confirms it, which gives a concrete design test: a model's completion message is a claim, and the harness must supply the evidence.

Background. The entry above names five composable patterns and argues for reaching for the simplest one that works. Coding agents have since become the dominant application, and the working knowledge about building them accumulates in blog posts, changelogs, and team lore rather than in papers.

Problem. That knowledge is hard to consult at the moment it is needed. Someone deciding how to shape a tool definition, a review step, or a split across several agents has no reference that separates what works from what merely circulates, and the failure modes are the part nobody writes up.

Key idea. Build a reference corpus rather than one long argument. Short Markdown pages each cover one concept, group related practices, and place anti-patterns beside patterns so known failures are documented instead of rediscovered. Agents can load the same pages into their own context.

Why it matters. Read it as the practitioner's counterpart to the paper above, and read the anti-patterns first, since that is where the cost of a pattern shows up. That it is written to be consumed by an agent is the lesson in miniature: a document an agent can load is a different artifact from one written only for a human reader.

Background. By 2023 the agent literature was a scatter of prompting patterns, tool wrappers, and retrieval add-ons. There was no shared account of what an agent is made of.

Problem. Without a decomposition, two agent systems cannot be compared. Each paper described its own loop end to end, so it was hard to tell which part of a design carried the result and which part was incidental.

Key idea. Put the model call at the center and name three components around it: planning, memory, and tool use. The post is a survey rather than a new system, and the vocabulary is the contribution.

Why it matters. That split is the structure LangChain, LlamaIndex, and the AutoGPT-era frameworks expose to users, and it is still how most agent papers organize their related work.

Background. Research papers explain agent components, but a team first needs to decide which workflows justify an agent at all. This guide draws on OpenAI's customer deployments.

Problem. Teams may choose an agent where a deterministic pipeline would suffice, then discover the reliability cost late. Research papers rarely define the boundary clearly enough to make that decision early.

Key idea. Define an agent as a system in which the model controls workflow execution. Use one when nuanced judgment, unmaintainable rules, or unstructured data defeat a deterministic design. Start with one model, tools, and instructions; add multiple agents only when necessary, with guardrails, explicit exit conditions, and human escalation.

Why it matters. Its strongest contribution is a negative criterion: it identifies systems that are not agents and workflows that should remain deterministic. Compare its decomposition advice with the Anthropic and Cognition positions.

Background. Prompt engineering treats the window as somewhere to word one instruction well. An agent instead fills that window itself over many turns, with tool results, file contents, and its own earlier output.

Problem. Context is a finite resource whose value degrades as it fills, so a long agent run is not fixed by phrasing. The question is which tokens deserve the window on this turn and what happens to everything else.

Key idea. Curate the context rather than write the prompt. The four techniques it names are mechanisms: compaction, structured note-taking into external memory, subagents that each get a clean window, and just-in-time retrieval that holds identifiers and loads the data only when a step needs it.

Why it matters. Each of the four changes what the serving system underneath actually sees, which is why this sits next to context rot and lost in the middle above. Treating the window as an allocation decision is what makes prompt work measurable.

Background. An agent’s context window holds the system prompt, the tool definitions, the retrieved code, and every tool result so far. On a long coding task that window, not the model, is the binding constraint.

Problem. Contexts fill with material that has stopped helping: stale file reads, superseded diffs, search output the agent already consumed. A full window forces truncation at the worst moment, and text that no longer matters competes for attention with text that does.

Key idea. Treat context as a resource with a lifecycle rather than a prompt to be worded well. The guide organizes that work into four pillars, separates it from prompt engineering, and reports which practices hold up in production coding agents.

Why it matters. It names the discipline that decides whether a long agent run stays coherent. Once you see the window as a budget with an allocation policy, retrieval scoping, compaction, and subagent isolation stop being separate tricks and become one decision made three times.

Background. A long-horizon tool-using agent writes its own transcript. Every tool result, intermediate step, and retry stays in the window and is re-read on every following turn.

Problem. Trimming that history is normally treated as a cost measure paid for in accuracy, so pruning gets tuned only once a run stops fitting or stops being affordable, and never as something that could help the task itself.

Key idea. Prune tool output and history aggressively, then score task success rather than tokens alone.

Findings. On a 50-task hotel-expense benchmark, full history completed 71.0% of tasks using 1.48 million tokens. Keeping five tool exchanges completed 79.0% using 535,274 tokens, while adding summaries completed 91.6% using 553,374 tokens.

Why it matters. Context management becomes a joint accuracy and cost knob rather than pure compression. If cutting context can improve both at once, the right setting is not the largest window your budget allows, and it has to be measured per workload.

Background. An agent reaches the outside world only through tools, and each tool a harness mounts arrives at the model as a name, a schema, and a description it has to read. Anthropic wrote this guide out of building Claude Code and the Model Context Protocol.

Problem. A tool the model misuses is usually a documentation failure rather than a capability failure. The description has to teach the schema and the semantics at once, and the output has to be legible to a model instead of to a person reading a log.

Key idea. Treat the description as part of the interface, not as documentation beside it, since it is what teaches the model how and when to call the tool. Shape the return value the same way, giving the next decision what it needs rather than everything the underlying API produces.

Why it matters. Tool definitions and their outputs occupy the same context budget as the task, so a badly shaped tool costs tokens on every turn it is mounted, not only on the turns it is called. It is the practical guide MCP server authors follow when naming tools and shaping their outputs.

Background. A harness gives the model one tool per operation, so reading a file, writing a file, editing a range, and searching a tree each arrive as a separate schema. Every one of those schemas is resident context, and the set of them fixes what the agent can do.

Problem. The designer has to anticipate each operation in advance, and an operation nobody anticipated is unreachable however capable the model is. Composing several of those tools also costs a round trip per step, and each hand-off is a place the trace can go wrong.

Key idea. Expose a shell instead of a catalog. A single command tool routes to the programs already installed, so Python, git, SQLite, a compiler, and the project's own command-line tools become the action space without any of them being mounted as a tool. The safeguards the atomic tools used to provide move into the harness: truncate long output and say how to request a narrower slice, return exit status and duration alongside the text, gate paths and network and destructive commands by policy, and manage long-running processes asynchronously. The author pairs this with two habits, keeping bulk data in the environment and returning only summaries to the model, and delegating messy debugging to a subagent that reports a clean result.

Findings. The author reports that a shell-centered harness performed on par with or better than one exposing separate read, write, edit, and search tools on the same task set, with no numbers given, so read it as one practitioner's observation rather than a measurement. He also names the exception: text cannot carry pixels, so a screenshot still needs its own channel, and a tool is still justified wherever it genuinely offers a better interface than a command would.

Why it matters. It states the tool-count question as a design trade-off rather than a preference. A large catalog spends resident context and bounds the action space by what the designer foresaw, while a shell spends almost none and bounds it by what the environment has installed, at the cost of moving truncation, sandboxing, and process management into the harness. The three papers that follow read differently in this light, since retrieving from a catalog of thousands of APIs presumes the catalog is where capability lives.

Background. A model that cannot call out answers arithmetic, current facts, and translation from its weights. The fix at the time was prompting: describe the available tools in the context and hope the model emits a well-formed call at the right moment.

Problem. Prompted tool use puts the decision in the wrong place. Whether an API call helps at this point in the text is a property of the model's own uncertainty, and instruction text cannot teach it when calling is worth the extra round trip and when it is not.

Key idea. Let the model label its own training data. Sample candidate API calls in context, execute them, keep only the calls whose results reduce the model's loss on the tokens that follow, and fine-tune on what survives. Tool use becomes learned behavior instead of instructed behavior.

Findings. Across the paper's downstream evaluations, Toolformer improved zero-shot performance and was often competitive with much larger models while preserving its underlying language-modeling performance.

Why it matters. This is where the tool-call boundary moves into the weights, which is what makes tool schemas a serving concern. The checkpoint now expects one particular call format, so the chat template, the parser, and the execution loop become part of the model's contract.

Background. An agent is a loop. The harness sends the thread, runs whatever tools the model called, appends the results, and repeats. The model holds no state of its own, so everything the agent knows is whatever that assembly put in the thread, and a designer's whole leverage sits in the assembly step.

Problem. Two structural decisions follow from that loop and are usually made by default rather than on purpose. The first is how many agents to run, since one agent per domain keeps each prompt small but splits the thread so that no agent sees the whole task. The second is what a tool has to be, since a designer who assumes a tool must wrap a real system will build integrations the loop never required.

Key idea. Treat both as free choices, because the loop constrains neither. A tool need not correspond to anything real. The author's team implements a shell tool in Go over a virtual filesystem, and the model cannot tell, so the tool surface can be designed for the model instead of inherited from the backend. In place of one agent per domain, run a single agent that loads skills on demand, which returns full-thread context while keeping the resident prompt small. Wrapping that load in a skill tool, rather than letting the model open files itself, buys name resolution, usage tracking, and a returned file index that saves the model a recursive directory listing.

Findings. A skill description costs roughly 100 tokens of resident context, and its body of a few thousand tokens loads only once that description matches the task, which is what makes the single-agent consolidation affordable at all. Across the roughly 20 observability platforms the author's team covers, one loop and one tool surface serve every platform, with the platform-specific knowledge carried in skills rather than in code.

Why it matters. It separates what a designer has to build from what a designer can simply declare. The loop, the thread, and the tool schemas are engineering, while the know-how about when to use them is text loaded on demand, and moving material across that line is how a harness gains capability without growing its resident prompt. The post also notes that none of this is provider-specific, so the design carries across model vendors.