Agentic
Systems

An agentic system is what you get when you stop treating a language model as a function that maps a prompt to a completion, and start treating it as the controller of a loop: the model observes state, decides on an action, executes it against an environment, observes the result, and repeats until a goal is met. That single architectural move — closing the loop — is responsible for essentially everything interesting and everything dangerous that has happened in applied AI since late 2022.

This survey is written for people who build systems for a living. It assumes you understand distributed infrastructure, control flow, state management, and the difference between a demo and a production system, and it does not spend time explaining what a transformer is. What it does spend time on is the part that is genuinely new: a non-deterministic, natural-language-native controller sits at the center of the system, and almost every hard-won principle of the last three years is a consequence of engineering around that fact — its context window, its failure modes, its lack of durable state, its susceptibility to adversarial input, and its stubborn resistance to evaluation.

The structure is deliberate. Part I fixes definitions and traces the historical arc. Part II takes the computer-science view: the control loop as a formal object, the action space, memory, and the recent and decisive shift from prompting agents to training them with reinforcement learning. Part III takes the systems-engineering view: reliability, durability, observability, evaluation, interoperability, and security — the concerns that separate a viral demo from something you can put in front of a customer. Part IV surveys what is actually deployed and where the frontier is heading. Throughout, the recurring thesis is that the model is now a commodity input and the scaffold is the system — and that the discipline of agent engineering is mostly the discipline of managing a single scarce resource: the tokens in the context window.

What is an agentic system?

The word "agent" carries decades of baggage from symbolic AI, robotics, and reinforcement learning, and the current usage is loose enough to be nearly useless in a technical conversation. The most useful working definition in circulation comes from Anthropic's December 2024 essay Building Effective Agents, which draws a line that matters for architecture: the distinction is not agent-versus-not, but where control flow lives.

This is a spectrum, not a binary, and the spectrum is the single most important design decision in the field. Autonomy is not free: every additional turn the model takes on its own adds latency, adds token cost, and adds a fresh opportunity for an early mistake to compound into an unrecoverable trajectory. The correct default, and the one that most production teams relearn the hard way, is to use the least agentic thing that passes evaluation — often a fixed workflow, sometimes a single well-instrumented LLM call — and to reach for genuine autonomy only when the task's structure cannot be encoded in advance but progress can still be verified as it goes.

The augmented LLM and the loop

The atomic building block underneath both workflows and agents is what Anthropic calls the augmented LLM: a model equipped with three capabilities that turn it from a text generator into a controller — retrieval (it writes its own queries and reads results), tools (it selects and invokes external actions, then reads their output), and memory (it decides what to carry forward). Wrap that augmented model in a loop that feeds each action's result back as the next observation, and you have an agent. The loop — variously called reason–act–observe, the think–act–observe cycle, or simply the agent loop — is the irreducible core. Everything else in this survey is infrastructure that makes that loop run reliably, at scale, in production.

It is worth stating precisely what changes when you close the loop, because it explains why the agent stack is not the LLM stack. A chatbot needs inference and maybe retrieval. An agent needs, in addition: state that persists across many model calls, an action interface governed by some contract, error handling for actions that fail or return garbage, a stopping condition, and — because the loop can run for hundreds of steps — active management of what stays in the context window. Each of those is a section of this report.

The five workflow patterns

Before autonomy, there is a small vocabulary of composable control-flow shapes that cover a large fraction of real deployments. These are classical CS primitives — sequence, branch, fan-out, dispatch, refine — rediscovered in an LLM context, and their value is taxonomic: they turn "build an agent" into a discrete choice about which shape fits the task.

• Prompt chaining — decompose a task into a fixed sequence of steps, each consuming the last one's output. Trades latency for accuracy on tasks with stable structure.
• Routing — classify the input, then dispatch to a specialized handler. The workhorse of production support and triage systems.
• Parallelization — run independent subtasks concurrently (sectioning) or run the same task several times and aggregate (voting, e.g. multiple independent security reviews of one diff).
• Orchestrator–workers — a lead model dynamically breaks a task into subtasks, delegates them, and synthesizes results. The bridge to multi-agent systems.
• Evaluator–optimizer — one model generates, another critiques against explicit criteria, and the pair iterates. Effective only when the evaluator can reliably tell good output from bad.

The honest caveat, well documented by practitioners who have shipped these in anger, is that the patterns assume the task is well-specified and the output is verifiable. When there is no clear evaluation criterion, the evaluator–optimizer loop becomes circular; when the task is high-frequency and simple, deterministic code beats both workflows and agents on cost and latency. The patterns are a map, not a mandate.

A short history, 2022–2026

The field moved fast enough that its own vocabulary shifted underneath it several times. It is worth compressing the arc, because the sequence of ideas explains why today's systems look the way they do — in particular, why the first wave of "autonomous agents" collapsed, and what had to be invented before the second wave could work. Three forces drove the timeline: models got better at reasoning, the interface for taking actions got standardized, and — most consequentially in 2025 — agency became something you train for rather than prompt for.

Anatomy of an agent

Strip away the frameworks and an agent is a small number of components arranged around the loop. Naming them precisely is worth the effort, because most production failures are a failure of exactly one of these components, and the frameworks tend to obscure which.

The loop as a formal object

Formally, an agent is a policy operating in a partially observable environment. The model never sees true world state; it sees the context window, which is a lossy, curated projection of history. This makes an agent a POMDP — a partially observable Markov decision process — and it is not an idle analogy. Two consequences fall directly out of it. First, whatever is not in the context window effectively does not exist for the next decision, which is why context management is not an optimization but a correctness concern. Second, the "Markov" part is a fiction we impose: the model must reconstruct enough state from the visible trace to act coherently, and long, polluted traces make that reconstruction fail — the mechanism behind context-length degradation. Recent long-horizon work makes this explicit, framing the agent's job as Markovian state reconstruction: at each step, compress history into a state sufficient to act, and carry that forward rather than the raw trace.

There is one more structural quirk that distinguishes LLM agents from classical RL agents and dominates their engineering. The classical agent's state is a compact vector; the LLM agent's state is a monotonically growing string of tokens. Every action and every observation is appended. The state therefore grows without bound along the trajectory, bumping into a hard context limit and — well before that limit — into soft degradation. Half of agent engineering is a fight against this single property.

Planning: decomposition and search

Planning in LLM agents spans a spectrum from implicit to explicit. At the implicit end, ReAct-style agents plan one step at a time: the "thought" before each action is a local plan, and the global plan is emergent. This is cheap and, for many tasks, sufficient — but it is greedy, and greedy search over an action space with irreversible actions is fragile. At the explicit end sit deliberate search methods: Tree of Thoughts explores multiple reasoning branches with lookahead and backtracking; LATS (Language Agent Tree Search) grafts Monte-Carlo tree search onto the agent loop, using the model as both policy and value estimator. The tradeoff is the usual one from classical planning — deliberation buys quality at a steep cost in tokens and latency — and in practice most shipped systems stay near the greedy end and buy reliability elsewhere (better models, better tools, verification) rather than paying for search.

The action space: JSON versus code

How the model expresses an action is a genuine architectural fork, not a syntax preference. The mainstream answer since mid-2023 is typed function calling: the model emits structured JSON naming a tool and its arguments, the harness parses and dispatches. It is predictable, easy to validate, and easy to gate for permissions — but it is also a constrained action space. Each action is one tool call; composing tools, looping over results, or branching on an intermediate value requires a separate round-trip per step.

The CodeAct alternative — the model writes executable code as its action, run in a sandboxed interpreter — collapses that overhead. A single action can call several tools, pass one's output to the next, loop over a collection, and branch on results, because code has control flow and data flow natively. On multi-tool benchmarks this yields materially higher success rates and fewer steps, and it is the reason "code agents" (smolagents, langgraph-codeact, and the internal harnesses of most serious coding tools) treat Python as the universal action interface. The cost is that arbitrary code execution is a much larger attack surface and demands real sandboxing. The rule of thumb that has emerged: JSON tools for a small, safety-sensitive, well-defined action set; code-as-action when the task needs composition and the environment can be sandboxed.

Memory: four kinds, one scarce tier

"Memory" in agents is an overloaded word covering four distinct things borrowed, roughly, from cognitive architecture. Only the first is in the context window; the other three are external systems with their own retrieval, cost, and correctness problems.

The dominant design pattern is explicitly OS-inspired. MemGPT (now productized as Letta) framed the LLM as an operating system managing a tiered memory hierarchy: a small always-resident core (like RAM), a searchable archival store (like disk), and paged recall of conversation history — with the model itself issuing function calls to page information in and out. Its descendants specialize: Mem0 distills interactions into retrievable facts and reports large token savings versus stuffing full history into context; Zep maintains a temporal knowledge graph so an agent can answer "what did we decide last Tuesday"; LangGraph provides durable checkpointing plus a cross-thread store. The recurring lesson from every team that has built one is blunt: production-grade long-term memory is usually harder to build than the agent itself, and the effort to make it reliable, scalable, and correct is routinely underestimated.

Reflection and self-correction

A model that can inspect its own failed attempt and revise is dramatically more capable over long horizons than one that cannot — and much of the METR time-horizon growth (§8) is attributed precisely to improved error recovery rather than raw reasoning. The seminal pattern is Reflexion (Shinn et al.): after a failed attempt, the model generates a verbal self-critique and stores it as episodic memory to condition the next try — "verbal reinforcement learning" with no weight updates. Voyager pushed the idea further, accumulating successful behaviors into a reusable, transferable skill library. These prompt-level techniques were the state of the art through 2024; in 2025 the same objective — teach the model to recover from its own mistakes — migrated into the training loop itself (§6), which turned out to be far more effective.

What is genuinely new, and what isn't

For a reader with an AI background it is clarifying to say plainly: the agent abstraction is not new. Perception–action loops, BDI (belief–desire–intention) architectures, planning under uncertainty, and RL policies over action spaces are decades old, and today's agents map cleanly onto that lineage — a policy acting in a POMDP, planning by search, learning from reward. What is new is the controller: a single pretrained model that arrives with broad world knowledge, an open-ended natural-language action and observation space, and enough in-context learning to be redirected at a new task without retraining. That is what makes the old abstractions suddenly practical at general-purpose scope — and it is also why the failure modes are new, because the controller is fluent, confident, non-deterministic, and readily fooled by text in its input.

Context engineering: the central resource

If there is one idea that separates 2025-era practice from what came before, it is this: for a long-horizon agent, the scarce resource is not the model's intelligence — it is the tokens in its context window, and the discipline of managing them is a distinct engineering practice.

Andrej Karpathy popularized the term context engineering in mid-2025; Anthropic's applied team gave it a working definition that September — the set of strategies for curating and maintaining the optimal set of tokens during inference. Cognition, from the coding-agent trenches, called it "effectively the #1 job of engineers building AI agents." The framing caught on because it named something prompt engineering never captured: an agent is not a one-shot chatbot. It runs for hundreds of turns, accumulates tool outputs, and fails in ways that have nothing to do with how the original instruction was worded. Prompt engineering optimizes the first user turn; context engineering owns the entire token lifecycle, from the first system-prompt token to the last compacted summary.

Why bigger windows do not solve it

The intuitive fix — wait for million-token context windows — does not work, and understanding why is the crux. Every model, regardless of advertised window size, degrades when the window fills with the wrong tokens. This is context rot: performance on a task falls as irrelevant, stale, or merely voluminous tokens accumulate, and independent testing (Chroma's context-rot work) finds the degradation begins accelerating well below nominal limits — on the order of tens of thousands of tokens, far short of the window ceiling. The mechanism is attention: as the context grows, the signal the model needs competes with an ever-larger volume of noise, and older task-relevant information gets progressively de-prioritized. A related failure, context drift, occurs when compacted summaries subtly reword the task or early context gets buried, and the model's reasoning slowly diverges from the original intent. A larger window buys headroom; it does not repeal the physics. For the foreseeable future, windows of every size are subject to pollution and relevance decay — so the strongest agent performance still requires actively curating context, not merely enlarging it.

The three levers

Practice has converged on three techniques for keeping a long-running agent inside a usable context budget. They are not exclusive; serious systems compose them.

1 · Compaction

Take a conversation nearing the window limit, summarize it, and reinitialize a fresh window from the summary. This is the first lever most teams reach for and the one that most directly buys long-horizon coherence. Its lightest, safest form is tool-result clearing: drop the verbose raw output of old tool calls (which the model has already extracted what it needs from) while keeping the reasoning. Compaction has matured into provider-native infrastructure — Anthropic shipped an automatic compaction feature on its platform, exposed across the major clouds — so teams no longer hand-roll the trigger-and-summarize loop. The open research problem is lossy compaction: a summary that drops the one fact a later step needed causes a silent, hard-to-debug failure, which is why work like ACON treats compression as an optimization problem (find cases where full context succeeded but compressed context failed, and revise the compressor to preserve that class of information).

2 · Structured note-taking

Have the agent persist durable state outside the context window — to a scratchpad, a to-do file, a memory tool — and reload it as needed, rather than relying on the transcript to carry everything. This externalizes working memory, keeps the live window small, and is especially strong for iterative work with clear milestones (the agent writes down what it has finished and what remains, then works against that ledger instead of re-deriving it from a long trace).

3 · Sub-agent context isolation

Spawn sub-agents with their own fresh, isolated windows to do bounded work — a deep search, an exploration — and have each return only a short, condensed result (on the order of 1–2k tokens) to the lead agent. The detailed context stays quarantined inside the sub-agent; the lead agent's window sees only distilled findings. This is the same idea as a function call hiding its local variables from the caller, and it is the architectural bridge to multi-agent systems (§5) — the multi-agent pattern is, in one reading, primarily a context-isolation strategy.

The cost layer: KV cache and prefix reuse

Context also dominates the economics, through a mechanism worth calling out because it silently shapes agent design: the KV cache. Because a transformer's attention over the prompt can be cached, a stable, unchanging prefix (system prompt, tool definitions, few-shot examples) can be reused across turns at a fraction of the cost and latency of recomputation — provider prefix-caching discounts are large. This creates a concrete design pressure that leaks into architecture: keep the prefix stable and append-only. Anything that rewrites earlier context — reordering tools, mutating the system prompt mid-run, non-append-only compaction — invalidates the cache and re-prices every subsequent token. Cache-aware agents are markedly cheaper and faster than cache-oblivious ones running the identical logic, which is why "don't touch the prefix" has become folklore among people who watch their inference bills.

Orchestration & multi-agent topology

Once a single agent works, the tempting next move is to build many and have them collaborate — a researcher agent, a coder agent, an analyst agent, coordinated by an orchestrator, mirroring how human teams divide labor. Gartner reported a roughly 1,445% surge in multi-agent inquiries between early 2024 and mid-2025; the pattern is genuinely popular. It is also the single most over-applied idea in the field, and the reasons are precise enough to state as engineering rules.

The debate that defined the question

On two consecutive days in June 2025, the two most credible voices in the space published opposite-sounding playbooks — a coincidence that crystallized the field's central tension.

Why both are right

The apparent contradiction dissolves on one observation, and it is the most useful heuristic in this whole area: read actions parallelize; write actions do not. Anthropic's system is research — dominated by reading, where many sub-agents can explore independent branches and their findings simply concatenate. Conflicting reads are cheap; you just gather more. Cognition ships a coding agent — dominated by writing, where two agents editing the same system make incompatible design choices (style, edge cases, interfaces) that produce a broken whole. Conflicting writes are catastrophic, and merging them requires exactly the shared context that parallelism threw away. Anthropic's own post concedes the point: most coding tasks are poorly suited to multi-agent architectures with current technology, because they demand shared context and involve tight interdependencies.

Coordination overhead is real and it saturates fast

Multi-agent systems import the failure modes of distributed systems — and then compound them, because each node is non-deterministic. A second agent multiplies your token bill, multiplies the ways coordination can fail, and compounds unreliability across every hop: a ten-step chain where each hop is 95% reliable is only ~60% reliable end to end. By 2026, practitioners converged on a sober number: the practical sweet spot is often three to four agents, beyond which coordination overhead — redundant message-passing, context reconciliation, error cascades — overwhelms the parallelism gains. The frontier of the sub-field is now about reducing that overhead: sparser communication protocols, hierarchical decomposition so not every agent must talk to every other, and asynchronous orchestration so agents don't block on each other.

The default that ages well

The consensus that emerged is unglamorous and correct: start with one agent and good tools; add a second agent only when a specific limit forces it. The legitimate forcing functions are narrow — the work genuinely exceeds a single context window, the task decomposes into independent read-heavy branches worth exploring in parallel, or you need diverse independent attempts to reduce path-dependence. Absent one of those, most multi-agent systems would work better, cheaper, and more debuggably as a single well-engineered agent. As one widely-shared 2026 title put it: most multi-agent systems would work better as one agent.

Training for agency: the RL turn

The most important shift of 2025 is easy to miss because it happened inside the models rather than the frameworks: agentic capability stopped being something you elicit through scaffolding and started being something you train into the weights with reinforcement learning.

Recall why the 2023 autonomous-agent wave failed: a base model prompted into a long loop drifts, because it was never optimized for the thing that long horizons demand — recovering from its own mistakes over many dependent steps. Prompt-level patches (Reflexion, tree search, elaborate scaffolds) helped at the margin. The decisive move was to make the training objective match the deployment condition: reward the model for completing multi-step tasks, not for producing plausible next tokens.

Reasoning models opened the door

OpenAI's o1 (late 2024) and then DeepSeek-R1 (January 2025) demonstrated that outcome-based RL — rewarding correct final answers, with no supervision of the intermediate reasoning — elicits long, self-correcting chains of thought that emerge rather than being imitated. DeepSeek-R1 mattered doubly: it worked, and it open-sourced the recipe, centered on GRPO (Group Relative Policy Optimization), a PPO variant that dispenses with a separate value network by normalizing rewards within a group of sampled rollouts. Suddenly the cost of training a reasoning model dropped, and a wave of academic and industrial work followed within months. The models produced were not just better at math; they were better at the exact skills agents need — decomposition, backtracking, adaptive depth, and knowing when to stop.

Agentic RL: training the whole loop

The natural next step was to put tools and environments inside the RL loop. Instead of training a model to produce a good answer, train it to produce a good trajectory: reason, call a search API or a code interpreter, read the result, reason again, and be rewarded on the outcome of the whole episode. This is agentic reinforcement learning, and it defined the 2025 research frontier. Search-R1 and R1-Searcher taught models to interleave reasoning with live search; ARTIST and TORL taught them to write and run code mid-reasoning for exact computation; frameworks like AgentGym-RL, AgentRL, and VerlTool generalized the machinery to arbitrary multi-turn, multi-tool settings. A robust empirical finding recurs across this work: simple outcome rewards outperform elaborate process rewards — supervising every intermediate step tends to suppress the exploration that produces novel strategies, whereas rewarding only the end result lets useful behavior emerge.

The hard parts, honestly

Agentic RL is not a solved recipe; it introduces problems that plain RLHF never faced, and these are where current effort concentrates.

• Multi-turn credit assignment. An episode succeeds or fails after dozens of interleaved reasoning steps and tool calls. Attributing the outcome to the specific decisions that mattered — the core RL problem — is far harder over long, heterogeneous trajectories than over a single response.
• Scalable rollout. Each training example is now a full multi-turn interaction with real (or simulated) tools, which is slow and expensive to generate at the scale RL demands. Rollout throughput, not gradient compute, is often the bottleneck.
• Training instability. Long-horizon, off-policy agentic RL is notoriously unstable; recent work (turn-level importance sampling, clipping-triggered normalization) exists specifically to keep these runs from diverging.
• Environments are the new bottleneck. Verifiable reward requires an environment that can score an outcome. Building enough high-fidelity, diverse, cheat-resistant environments — simulated apps, mock worlds, rubric-based graders — is now a first-class research problem in its own right, and arguably the rate limiter on progress.

Reliability & durability

This is the section where demos become products or don't. The uncomfortable arithmetic of agents is that reliability compounds multiplicatively along a trajectory, and long trajectories are unforgiving of per-step error. An agent that is 95% reliable on each step is only about 60% reliable across a ten-step task and 36% across twenty. The headline capability numbers you see are almost always measured at a 50% success threshold precisely because it is the easiest to estimate — but useful work often demands 99% or more, and the gap between "impressive at 50%" and "trustworthy at 99%" is the gap that has kept most agents in pilot purgatory.

Non-determinism is a first-class systems property

Agents are non-deterministic at multiple layers simultaneously: the model samples, tools return different results across calls, and the environment (a live website, a changing database) drifts. The same agent given the same task can succeed, fail, or fail differently on repeated runs. For a systems engineer this has hard consequences: you cannot reproduce a bug by re-running it, you cannot assert on an exact action sequence, and you cannot fully test in advance. The mitigations borrow from testing discipline — assert on resulting state, not on the trajectory that produced it (the same instinct as end-to-end testing) — but the underlying property never goes away, and designing around it (idempotent actions, verification steps, bounded blast radius) is part of the job.

Durable execution: agents are long-running distributed workflows

A serious agent may run for minutes, hours, or across days with human approvals in between — which makes it a long-running stateful workflow, and it inherits every problem such workflows have always had. The process will crash, the machine will restart, the model provider will rate-limit mid-run. Without durability, all progress is lost. The pattern the ecosystem converged on is checkpointing: serialize the agent's state after each step so a run paused (or killed) at step 7 resumes at step 7, potentially days later, on a different machine. LangGraph builds this in — every node execution produces a serializable snapshot written to Postgres, Redis, or similar — and dedicated durable-execution engines (Temporal-style) are increasingly used underneath production agents for exactly-once semantics, retries, and recovery. A 2026 survey found ~68% of production agent deployments now include a dedicated memory/state layer, up from ~23% in 2024 — durability moved from research curiosity to table stakes.

Human-in-the-loop as an architectural primitive

The correct response to imperfect reliability plus irreversible actions is not "make the model perfect" but "put a human at the right checkpoints." This is a design primitive, not a fallback: durable state is what makes it possible to pause an agent before a consequential action (a deployment, a payment, a public post, a permission change), surface the proposed action for approval, and resume on a yes. The engineering question is placement — gate the irreversible and high-blast-radius actions, let the rest run — and the security frameworks in §10 make this concrete by defining which action combinations must never run autonomously at all.

Observability: you cannot operate what you cannot trace

Because a run is a long, branching, non-deterministic trajectory, debugging and monitoring require full execution traces — every prompt, model output, tool call, argument, result, and the exact turn where things went wrong. Tracing is the load-bearing observability primitive for agents the way logs and distributed traces are for microservices, and the tooling grew up around it (LangSmith and peers). The distributed-systems analogy runs deeper than convenience: security researchers now argue agents need the runtime instrumentation that EDR and SIEM provide for traditional infrastructure — tool-call anomaly detection, credential-access monitoring scoped to task context, memory-write auditing — because a compromised agent looks like a legitimate agent doing slightly wrong things, and only the trace reveals it. Most deployments still lack this layer, which is a large part of why production incidents are hard to catch and harder to diagnose.

Evaluation & measurement

Evaluating agents is materially harder than evaluating models, and the field's benchmarks are simultaneously indispensable and deeply untrustworthy. A model that scores 94% on a knowledge benchmark like MMLU can fail a multi-step web task that a human finds trivial, because agentic success requires capabilities that static Q&A never stresses: planning, tool-use discipline, error detection, and recovery. The question shifts from "can the model answer this?" to "can the system complete this multi-step task that requires tools, state, and recovery?" — and that shift breaks most of the measurement machinery inherited from the LLM era.

The capability trajectory

The clearest single signal is the coding-agent trajectory on SWE-bench — resolving real GitHub issues in real repositories — because it is outcome-verified (does the patch pass the hidden tests?) rather than judged. The shape is unambiguous and steep, even after discounting for the caveats below.

Why the numbers lie (four structural reasons)

Agent benchmarks are far less stable than LLM benchmarks, and an architect reading a leaderboard should internalize why before trusting any single figure.

• Scaffold, not just model. The same base model in different harnesses routinely varies by 15+ points on SWE-bench — how it retrieves code, recovers from failed patches, and manages context matters as much as raw model quality. A "model score" is really a "model-plus-scaffold score," and the two are rarely disentangled. This is the deepest lesson of the era for architects: the scaffold is a first-class determinant of capability.
• Contamination. SWE-bench issues predate many models' training cutoffs; an OpenAI audit found a majority of the hardest tasks had tests that pass even when the bug is unfixed, and roughly a third of issues contain the solution in their own comments. Verified subsets reduce but do not eliminate this.
• LLM-as-judge bias. When ground truth is hard to encode, benchmarks fall back on a model to grade partial credit — and judge models exhibit position bias (favoring the first answer ~60% of the time), length bias, and agreeableness bias, with some 2025–26 audits reporting judge error rates above 50%.
• Environment drift & flakiness. Benchmark environments are frozen; real web pages, APIs, and apps are not. And agentic tasks in non-deterministic environments are flaky — the same agent scores differently across runs.

Measuring reliability, not just capability: pass^k

The most useful methodological contribution came from Sierra's τ-bench (tool–agent–user interactions with policy adherence), which popularized pass^k — "pass-hat-k" — in deliberate contrast to the familiar pass@k. Where pass@k rewards success in any of k attempts (and rises toward 1 with more tries), pass^k requires success in every one of k independent trials (and falls toward 0 as k grows). It reports the fraction of tasks an agent solves reliably, every time — exactly the metric that matters for production, and exactly the one that exposes how far "impressive" is from "dependable." The results surfaced substantial reliability gaps that best-of-k numbers hide.

The meta-metric: task-length horizons

The most illuminating framing of progress abstracts away from any single benchmark. METR's time-horizon work measures the length of task (by how long a human professional takes) that an agent can complete at a given reliability — the "50%-task-completion time horizon." Its central finding is a striking regularity: this horizon has been doubling roughly every 7 months since 2019, with strong correlation between task length and success (R² ≈ 0.83), and the trend appears to have accelerated to a ~4-month (by some 2024+ windows, ~3-month) doubling since 2024. Concretely: GPT-2's horizon was seconds; Claude 3.7 Sonnet's was around 50 minutes; the 2026 frontier is measured in hours to tens of hours. Two caveats keep it honest — the 80% reliability horizon grows at a similar rate but sits well below the 50% one (the reliability tax again), and extrapolation from a short recent window is fragile. But as a way to compress "how much can we hand off" into one number, it is the field's most useful yardstick, and it points the same direction as everything else: steadily lengthening autonomy, bottlenecked by reliability.

Interoperability & protocols

In 2023 an agent was a demo; in 2024 it was a framework; by early 2025 it was a hundred incompatible tool-calling conventions. Every framework had its own way to describe a tool, coordinate agents, and handle a transaction — the classic pre-standardization mess. What is genuinely remarkable is how fast the ecosystem converged, and on a clean layering. The web took most of a decade to travel an equivalent distance; the agent stack did it in about eighteen months.

Two protocols, one clean split

The framing the community settled on is exactly right and worth memorizing: MCP connects agents to tools; A2A connects agents to peers. A tool is invoked and returns. A peer is delegated to and negotiates. They are complementary layers, not competitors.

MCP's design choice that aged best is its humility: it standardizes plumbing and stays deliberately silent on agent architecture, which is precisely what let every vendor adopt it without ceding design opinions. Its adoption crossed the tipping point in early 2025 — the moment teams realized a tool built once could serve every agent — and "MCP server" entered the vocabulary of teams that had never shipped an integration before. A2A filled the coordination gap MCP explicitly left out of scope, standardizing how heterogeneous agents (potentially from different vendors, on different frameworks) discover each other's capabilities and hand off work.

Governance consolidated the layer

The institutional story is the reassuring part. Rather than fragmenting, the competing efforts merged under neutral governance: in December 2025 the Linux Foundation launched the Agentic AI Foundation (AAIF), co-founded by OpenAI, Anthropic, Google, Microsoft, AWS, and Block, as the permanent home for both MCP and A2A (plus the emerging WebMCP browser layer). Competing giants agreeing on shared standards, under a neutral foundation, this early in a technology's life is unusual and materially de-risks enterprise adoption — the same reason enterprises trusted HTTP and Kubernetes. Above these sit early payment layers (x402, AP2) for agent-initiated transactions, still immature. The layering that emerged — MCP for tools, A2A for agents, WebMCP for the browser, payment protocols for commerce — is solidifying into the plumbing of an "agentic web."

Security: the unsolved problem

Prompt injection is to agents what memory-safety was to C: a foundational vulnerability that follows directly from the design, resists point fixes, and will be with us for a long time. It is the reason the biggest blocker to agent deployment is no longer capability but safe, reliable access to production systems.

The root cause is simple and, so far, unfixable at the model level: an LLM has no robust separation between instructions and data. Everything in its context — the system prompt, the user's request, a web page it fetched, an email it's summarizing, the contents of a file — arrives as tokens, and the model is a fluent instruction-follower. Any text it ingests can be interpreted as a command. This is indirect prompt injection: an attacker who can get text in front of the agent (via a web page, a document, an email, a poisoned tool) can hijack it. A request to "handle my inbox" authorizes reading the inbox — not executing whatever instructions an attacker planted in one of the messages.

The lethal trifecta

Simon Willison's June 2025 framing is the field's clearest security mental model, and it is genuinely load-bearing for design. Data exfiltration becomes possible when an agent combines three capabilities in a single session:

This is not theoretical. The exact pattern — malicious instructions cause the agent to access private data and embed it in an outbound request (classically the URL of a rendered image, sending the data to an attacker's server) — has been demonstrated against a long list of shipped products since 2023. EchoLeak (CVE-2025-32711) was the first zero-click instance against a production enterprise system, Microsoft 365 Copilot: a crafted email whose hidden instructions, once indexed, caused the assistant to exfiltrate data with no user action. An equivalent attack later hit Google's enterprise stack. Google's own April 2026 sweep of Common Crawl found prompt-injection payloads scattered across the public web, with malicious attempts up ~32% in a single quarter. The threat is catalogued, not speculative: OWASP's 2026 Top 10 for Agentic Applications maps prompt injection to six of its ten categories.

The design response: budget the capabilities

Because you cannot make the model immune, the durable defenses are architectural — constrain which capabilities can coexist. Meta's October 2025 Agents Rule of Two turned the trifecta into a design budget, and Willison endorsed it as the best practical guidance available:

Everything else composes with this. Least privilege: scope each agent's data and tool access to the task, the way you'd scope a service account — an agent rarely needs all of Gmail, all of SharePoint, and all of the database simultaneously. Sandboxing: run code-executing and computer-use agents in isolated VMs or containers with minimal privileges (Anthropic's explicit guidance for computer use), so a hijacked agent's blast radius is bounded. Human gates on the irreversible actions from §7. And runtime monitoring — full execution traces, tool-call anomaly detection, credential-access and memory-write auditing — because a compromised agent is not a human attacker logging in; it is a legitimate agent quietly redirected, and only instrumentation catches it. The threat is also evolving beyond exfiltration: researchers have shown lateral movement across agentic systems (IdentityMesh) and multi-step "promptware" kill chains, so the runtime layer, not just the architecture, is now where the defensive action is.

Production systems & the ecosystem

By 2026 the survey data tells a consistent story: agents crossed from experimentation into production (roughly 80% of surveyed teams report production deployments and ~81% plan to expand into more complex use cases), and the primary obstacle is no longer model capability — ~46% cite integration with existing systems as their top challenge. The hard part is secure, reliable access to CRMs, ticketing systems, internal APIs, and data platforms. Most organizations take a hybrid path (~47% combine off-the-shelf agents with custom development), mirroring how every prior wave of infrastructure was actually adopted.

Coding — the domain that proved it

Software engineering is where agents first delivered daily, compounding value, and it remains the clearest proof of the paradigm. The landscape splits by form factor. IDE-integrated agents (Cursor — which reached ~$2B ARR by early 2026 — and Windsurf) keep a human in the loop turn by turn. Autonomous / CLI agents (Claude Code, OpenAI's Codex agents, Devin, and open harnesses like SWE-agent, OpenHands, and Aider) take a task and run. The category also produced the era's first genuine cultural phenomenon — "vibe coding," non-engineers building software by conversation — and its inevitable backlash, as production teams discovered that unreviewed AI-generated code creates its own class of maintenance debt. The sober framing that emerged: the era of "magic" AI coding is giving way to one of managed, verified, economically-rational AI engineering. Two enduring engineering lessons crystallized here: codebase indexing and retrieval often matter more than raw model intelligence past a few hundred files, and an open harness on open weights can land tasks at a fraction (reports cite ~1/20) of a closed product's per-task cost — if you're willing to own sandboxing and observability yourself.

Deep research & the "deep agents" pattern

Deep-research agents (from OpenAI, Google, and Anthropic) were the other breakout, and they are the canonical read-heavy, parallelizable workload where multi-agent architectures genuinely pay off (§5). They also generalized into a reusable blueprint — the "deep agents" pattern behind both research tools and coding tools: a planner, a filesystem for durable working state (note-taking as memory), isolated sub-agents for bounded parallel work, and persistent memory. It is context engineering (§4) crystallized into an architecture.

Computer use & browser agents

The most ambitious category gives agents a universal action interface — control any software a human can, no API required. The approaches divide by how the agent reaches the system. Screen-grounding agents read the screen as pixels and click by coordinates (Claude computer use, OpenAI's CUA behind what became ChatGPT's agent mode, UI-TARS) — maximal reach, but fragile: a misread element breaks the step, and long tasks drift as the screen changes. Terminal-and-connector agents skip the screen entirely when a cleaner path (an MCP connector, a direct API) exists. The winning production pattern in 2026 is explicitly hybrid and ordered — as one shipping product's rule puts it, connector first, browser second, screen last — using structured access where it exists and falling back to pixels only when nothing else works. Full-desktop control (OSWorld) remains the hardest frontier, with SOTA still in the low-80s versus ~15% two years earlier, and multi-step error recovery — a mistake at step 3 cascading through the next ten — is still the dominant failure mode, which is why human checkpoints remain non-negotiable for consequential tasks.

The framework landscape

A durable tension runs through tooling choices: vendor SDKs versus general frameworks versus starting from plain model APIs. Anthropic's own guidance — start with direct APIs, because frameworks hide the prompts and encourage over-engineering — is worth weighing against the reality that frameworks encode hard-won patterns and save real time. The pragmatic read: understand the primitives first, adopt a framework when its abstractions match your problem, and be suspicious of any layer you can't see through.

Agent Skills: expertise without new agents

A notable 2025–26 pattern worth flagging is Agent Skills — portable packages (a SKILL.md plus assets) that inject procedural, domain-specific knowledge into a general agent on demand, via progressive disclosure, rather than spinning up a bespoke agent per vertical. It is a clean answer to a real problem (how to give one capable agent deep expertise in many domains without bloating its context or its instructions) and complements, rather than replaces, the workflow-first discipline — the same instinct as loading a library only when you need it.

Open problems & outlook

Three years in, the field has a clearer picture of its hard problems than of their solutions. For an architect deciding where to invest, these are the load-bearing open questions — roughly in order of how much they gate real-world value.

Where this is heading

Two framings compete, and both are partly right. The bullish one — "agents are the new microservices" — holds that autonomous, composable, LLM-driven components will become a primary unit of software architecture, coordinated by protocols (MCP/A2A) the way services are coordinated by RPC and message queues. The evidence for it is real: the capability trajectory is steep and shows no clear plateau, standardization consolidated with unusual speed, and coding and research agents already deliver compounding value at scale.

The tempering framing is that everything hard about agents is hard for structural reasons that capability alone doesn't dissolve. Reliability compounds against you; security has no clean fix; evaluation is unreliable; and the most valuable tasks are exactly the ones that touch untrusted content with real privileges — the trifecta's danger zone. The likely near-term shape is therefore not "autonomous agents everywhere" but a widening band of supervised autonomy: agents handling progressively longer and more valuable tasks, inside progressively tighter containment, with humans at the consequential checkpoints — the automation frontier advancing steadily while high-stakes, adversarial-input work stays human-supervised longer than the demos suggest.

Canonical sources

The primary works underneath this survey, for readers who want to go to the source. Foundational papers, the essays that shaped practice, and the standards.