From a single reasoning trace to autonomous, self-correcting systems: ReAct, Toolformer, Reflexion, the agent design patterns that actually work, and the open protocol (MCP) that standardises how it all connects.
Five works trace the arc from a clever prompting pattern to a production-grade, vendor-neutral standard. Three are arXiv papers that established the core loops; two are industry pieces — Anthropic's engineering writing on what actually works in practice, and the open protocol that the ecosystem has now standardised on. The series covers papers, articles and blogs alike.
Yao et al. (Princeton / Google) · 2022 · arXiv:2210.03629 arXiv
Chain-of-Thought reasons beautifully but in a vacuum — it cannot consult the world, so its intermediate "facts" are whatever the model believes, and errors compound into confident hallucination. Pure action agents (e.g. WebGPT-style policies) can call tools but have no explicit, inspectable reasoning to decide which action and why. The two capabilities had been studied apart.
ReAct interleaves free-form reasoning traces ("thoughts") with concrete actions (tool / API / environment calls) and the resulting observations, in a single decoding loop: Thought → Action → Observation → Thought → …. The thought decides the next action; the observation grounds the next thought. On HotpotQA and FEVER it cuts hallucination versus CoT; on the ALFWorld and WebShop interactive benchmarks it beats imitation- and RL-based agents with only a handful of in-context exemplars.
This is the blueprint behind virtually every modern agent loop — LangChain/LangGraph "agent executors", OpenAI/Anthropic tool-calling loops, and ROS-style think-act controllers all descend from it. The practical lesson: ground reasoning in tool feedback. An observation from a real tool is worth more than ten lines of speculative chain-of-thought, and the explicit thought line is what makes an agent's behaviour debuggable in your traces.
Keep the thought as a first-class, logged field in your trajectory, not a hidden prefix. When an agent misbehaves, the failing Thought → Action transition is almost always where the bug lives — a wrong tool choice, a malformed argument, or a thought that ignored the last observation.
Schick et al. (Meta AI) · 2023 · arXiv:2302.04761 arXiv
Tool use is usually taught by either hand-written demonstrations or expensive human annotation of when to call what. Neither scales, and both bake in a human's guess of which calls help. Could a model decide for itself — learning which tool, with what arguments, and crucially when — from raw text alone?
A self-supervised loop. The model samples candidate API calls inline in ordinary text, executes them, and keeps only the calls whose returned result reduces the next-token loss on the surrounding text — i.e. calls that demonstrably help prediction. It then fine-tunes on this filtered, self-annotated corpus. The result: a model that has taught itself to use a calculator, a search engine, a QA system, a calendar, and a translation API, with no human tool-use labels.
Toolformer reframes "when should the model call a tool?" as a measurable, data-driven question rather than a prompt-engineering art. The filtering criterion — does the tool result actually improve the prediction? — is a clean, transferable principle: it is exactly the signal you want when curating tool-use fine-tuning data or pruning a bloated tool list that the model invokes for no benefit.
More tools is not better. A tool earns its place only if calling it measurably improves outcomes; otherwise it just enlarges the action space and the model's chance to pick wrong. Toolformer's loss-reduction filter is a principled way to ask that question of every tool you expose.
Shinn et al. (Northeastern / MIT) · 2023 · arXiv:2303.11366 arXiv
A ReAct agent that fails a task has no built-in way to learn from that failure within a session. Reinforcement learning could improve it, but updating weights from sparse, expensive reward signals is slow and impractical for a deployed LLM agent. How do you get the benefit of RL — learning from outcome feedback — without touching the weights?
"Verbal reinforcement learning." After a failed trajectory, the agent generates a natural-language self-reflection ("I failed because I searched the wrong term; next time I should…") and stores it in an episodic memory. That reflection is prepended to the context on the next attempt, conditioning behaviour without any gradient step. On multi-trial benchmarks (HumanEval coding, ALFWorld, HotpotQA) this delivers large gains — e.g. pass rates rising sharply over a few retries.
Reflexion is the cheapest "learning" you can add to an agent: it costs context tokens, not training runs. The pattern — evaluate → reflect in natural language → carry the lesson forward — is the basis of retry loops, self-critique, and the "memory" features in modern agent frameworks. The catch is the evaluator: gains are only as good as the signal telling the agent it failed (unit tests, a verifier, or an LLM-as-judge).
Don't just retry on failure — retry with a written reason. A reflection that names the specific cause of failure and a corrective plan is far more effective than a blind re-run, and it gives you a human-readable audit trail of how the agent course-corrected.
Anthropic Engineering · 2024 · anthropic.com/research/building-effective-agents Anthropic
By 2024 "agent" had become a marketing word stretched over everything from a single tool call to a fully autonomous loop. Teams were reaching for elaborate, autonomous, multi-agent architectures where a simple deterministic pipeline would have been more reliable, cheaper and easier to debug. The field needed a sober vocabulary and a sense of when complexity is actually warranted.
A clean distinction: workflows orchestrate LLMs and tools through predefined code paths; agents dynamically direct their own process and tool use. It then catalogues the composable building blocks — and argues for the simplest design that works, adding agency only when the task genuinely demands open-ended decision-making.
Decompose into a fixed sequence of steps, each feeding the next; optional gate checks between stages.
Classify the input, then dispatch to a specialised prompt / model / tool path.
Run subtasks concurrently (sectioning) or vote across runs, then aggregate.
A central LLM dynamically breaks the task down and delegates to worker calls.
One LLM produces, another critiques against criteria; loop until the bar is met.
Open-ended loop with tools and environment feedback — use only when paths can't be predefined.
This is the most directly actionable piece in the deck. It gives you a shared design language and a default bias toward simplicity: most "agent" requirements are met by a workflow of the patterns above, which are more predictable and cheaper to run. Reach for a true autonomous loop only when the task space is genuinely open-ended — and even then, invest in guardrails, observability and a stopping condition.
Start with the simplest pattern that could work and add agency only when measured behaviour demands it. Every increment of autonomy buys capability at the cost of predictability, latency and debuggability — pay for it deliberately, not by default.
Anthropic · 2024 · modelcontextprotocol.io · announcement Anthropic
Every tool integration was bespoke. Connecting M LLM applications to N data sources and tools meant M×N one-off connectors, each coupled to a particular model's calling convention. Integrations were not portable across vendors, and every new app re-implemented the same plumbing for files, databases and APIs.
An open standard — "USB-C for AI" — that decouples integrations from any single model. MCP defines a JSON-RPC client–server protocol in which a host application runs clients that connect to servers, and each server exposes three primitives: tools (callable functions), resources (readable data / context), and prompts (reusable templates). Write a server once; any MCP-compatible host can use it.
MCP is the integration layer the other four publications were missing. ReAct/Reflexion give you the loop, Toolformer the discipline of which tools earn their place, Anthropic's patterns the architecture — MCP is how you plug tools and data in once and reuse them everywhere, independent of model or vendor. For anyone building agentic systems, an MCP server is now the natural unit of reusable capability.
Treat capabilities as MCP servers, not as code wired into one app. The three primitives map cleanly onto an agent's needs — tools to act, resources to ground, prompts to standardise — and building to the protocol means your integration outlives any single model choice.
This is the final deck of a 30-publication series. Across six presentations the throughline is a single arc: from how language models are built, to how they are made useful, safe and efficient, to how they act in the world.
The unifying lesson for a practising engineer: capability comes from composition, not from any single trick. A strong base model, aligned and made to reason, served efficiently, grounded in retrieved facts, and driven by a disciplined agent loop over standardised tools — that is the modern LLM system. Each deck is one layer; the value is in how they stack.
You've reached the end of the series. Revisit the full index — all six presentations and thirty publications — at the Key LLM Publications series hub, and treat it as a living reading map rather than a one-time pass.