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.

Background. Context windows grew from a few thousand tokens to tens of thousands, and the working assumption was that anything you place inside the window is equally available to the model.

Problem. It is not. On multi-document question answering, accuracy depends on where in the input the one relevant passage sits, so a retrieval pipeline can hand the model exactly the right document and still get the wrong answer.

Key idea. Hold the task fixed and move the relevant document through the context, measuring accuracy at each position.

Findings. The curve is U-shaped: accuracy is highest when the evidence sits near the beginning or the end and lowest when it sits in the middle.

Why it matters. Long context is not free accuracy. This is the paper to reach for when a project’s answer to a problem is “put more in the prompt”, because it turns the ordering of retrieved chunks into a design decision with a measured cost.

Background. A long-horizon search agent appends every tool result to its context and rarely removes anything, so the prompt fills with search output the model has already finished using.

Problem. That accumulation costs accuracy, not just space. The agent starts answering worse while the context window is still far from full, so watching capacity never sees the failure coming.

Key idea. Grow accumulated search context while controlling task difficulty, classify the resulting failures, and compare seven context-management methods with a behavior-aware filter for parallel samples.

Findings. Across four models and three benchmarks, premature termination increased with context length even before the window filled. Behavior-aware filtering improved reported accuracy by 2.6-4.9% over unfiltered aggregation across three aggregation methods.

Why it matters. It changes the argument for context management. Eviction and compaction are normally justified by memory pressure; the same operations justified by answer quality have to trigger much earlier, and on different evidence.

Background. Before 2020, a model answered a knowledge-intensive question from whatever pretraining had written into its weights. Updating a fact meant retraining, and there was no passage to point at when the answer came out wrong.

Problem. Parametric knowledge is fixed at training time and cannot be inspected. Asked about something absent from its weights, the model produces a fluent answer anyway, and nothing in the output tells you which case you are in.

Key idea. Put a dense retriever over a Wikipedia index in front of a pretrained sequence-to-sequence generator, fetch passages for each input, and condition generation on them, training retriever and generator together while the index stays fixed. Knowledge moves out of the weights and into a store you can edit.

Findings. RAG set the reported state of the art on three open-domain question-answering tasks and generated more factual language than the paper's parametric-only sequence-to-sequence baseline.

Why it matters. It is the origin of the long, partly repeated prompts that make prefix caching worth building. It also splits serving in two: a retrieval tier with its own index and latency, and a generation tier whose input length is now set by how much you retrieved.

Adoption. Hugging Face Transformers implements the original RAG model and retriever classes, providing a maintained external implementation of the architecture.

Background. The context window is a fixed budget, and any long conversation or long task overruns it. The standard answers are truncation, summarization, and retrieval bolted on outside the model.

Problem. All three discard state without asking the agent what it still needs, and none of them lets the agent decide what stays resident. The window is managed for the model rather than by it.

Key idea. Treat the context window as the top tier of a memory hierarchy and give the model explicit paging operations into the tiers below. What stays resident, what is evicted, and what is fetched back become decisions the agent makes with function calls.

Why it matters. It is the most systems-flavored agent paper on the list, and it imports the virtual memory design wholesale: a small fast tier, a larger slow one, and an explicit policy for moving data between them. Once the window is a cache, compaction and retrieval stop looking like separate features.

Background. Agent evaluations in 2023 ran one task in a fresh context and stopped. An open-ended environment has no terminal task; the agent chooses what to attempt next and the session keeps going.

Problem. Nothing carries across episodes. Whatever the agent worked out is discarded with the context window, so the thousandth hour starts where the first did and every capability has to be rederived inside one window.

Key idea. Write each solved behavior out as an executable program, store it in a skill library indexed for retrieval, and load skills back when a later task needs them. A curriculum proposes the next task, and execution errors and environment feedback drive the rewrite loop.

Findings. In Minecraft, Voyager collected 3.3× more unique items, traveled 2.3× farther, and reached selected technology-tree milestones up to 15.3× faster than the prior methods evaluated in the paper.

Why it matters. It separates what the agent knows from what is currently in its context. Once skills live outside the window as code, the long-horizon session becomes a storage and retrieval problem, which is the framing context engineering and agent memory later formalize.