The strange thing about the current state of agentic AI is how well the pieces work and how poorly they combine. Ask a capable model to pick the right tool for a task and it usually will. Ask it to do that twenty times in a row, each step conditioned on the last, and the run frequently ends somewhere nobody intended.
That gap is not primarily a model problem, and it will not be closed only by better models. It is a systems problem with four distinct constraints, each of which gates a different category of application. Understanding which constraint is binding for a given use case is more useful than any forecast about capability.
Compounding is the whole story
Consider a simplified model. If each step of an agent run succeeds independently with probability p, a run of n steps succeeds with probability p^n. The arithmetic is unforgiving in a way that is easy to underestimate: as n grows, even a very high per-step reliability produces a run reliability that falls off a cliff.
The independence assumption is wrong, of course — errors correlate, and a good agent can recover from some of them — but the shape of the curve survives. Short runs are robust. Long runs are fragile. Every additional step is a multiplication, not an addition.
This explains almost everything about where agents currently succeed. They do well at tasks that decompose into a handful of steps with a verifiable end state, and badly at open-ended tasks with long horizons. It is not that the model becomes less capable at step fifteen. It is that fourteen prior opportunities for a small deviation have already happened.
There are only three ways to move the curve:
Raise per-step reliability. The model-improvement path. Real, ongoing, and subject to diminishing returns because the exponent is doing more damage than the base.
Reduce the number of steps. The engineering path, and the most underused one. Every step you can move from the agent into deterministic code is a multiplication removed. This is why so much production "agentic" work is a deterministic pipeline with model-powered steps.
Add checkpoints that catch deviation. The verification path. If a wrong step is detected and corrected rather than compounded, the run stops being a pure product of per-step probabilities.
The third is where the most consequential work is happening, and it is not glamorous.
Constraint one: verification is harder than generation
An agent that can check its own work behaves categorically differently from one that cannot. This is why coding agents progressed faster than agents for most other domains: software ships with an oracle. Tests pass or they do not. The compiler is not persuaded by a confident explanation.
Most valuable work does not have an oracle. Was that the right customer to refund? Is this contract summary accurate? Did the marketing plan account for the constraint mentioned in the third document? These are checkable in principle and expensive to check in practice, which is exactly the condition under which a plausible wrong answer survives.
So the frontier is not "can a model do X" but "can we build a cheap verifier for X". Expect the domains that get reliable agents next to be the ones where someone works out how to make verification cheap — through simulation, through constrained output that can be validated structurally, through a deterministic checker for a subset of cases, or through a second model whose only job is adversarial review against explicit criteria. Where no verifier exists, human review stays in the loop regardless of model capability, and that is a feature.
Constraint two: context economics
Every observation an agent makes is resent to the model on every subsequent step. That makes context a budget, not a container, and it produces a counterintuitive dynamic: larger context windows do not straightforwardly make long-running agents better, because cost and latency scale with what you actually put in them, and relevance does not scale with volume.
The practical result is that context engineering — deciding what an agent should carry forward, what to summarise, what to discard, and what to re-fetch on demand — is becoming a distinct discipline. The techniques are recognisable: compaction of old tool results, externalising state into files or a database the agent can re-read, structured scratchpads rather than an ever-growing transcript.
This is the constraint that most directly limits long-horizon autonomy today. An agent working for hours needs some form of durable memory that is not "the entire transcript", and the field has not converged on what that should look like.
Constraint three: identity and authorisation for non-humans
Nearly all access control in production systems assumes a human principal or a static service account. Agents are neither. An agent acts on behalf of a user, with a subset of that user's authority, for a bounded task, and often through several intermediary systems.
The questions this raises are unresolved in most organisations:
- What authority does an agent hold, and is it a subset of the requesting user's or its own?
- How is that authority scoped to a single task and revoked when the task ends?
- When an agent calls a service that calls another service, how does the original principal survive the hop?
- What does an audit log entry look like when the actor is a process and the authoriser is a person who approved a goal, not an action?
This is unglamorous plumbing, and it is the binding constraint on agents in regulated and enterprise environments far more than model quality is. Expect the emergence of per-task, short-lived, narrowly-scoped credentials as a first-class concept — because the alternative, an agent holding a long-lived key with broad permissions, is the architecture behind most of the ways this goes badly. The mechanism is spelled out in why prompt injection is an architecture problem.
Constraint four: interoperability
For agents to be genuinely useful they have to reach systems, and every system reached today is a bespoke integration. Standardising that layer is what the Model Context Protocol is for, and the direction of travel is clear even if the specific standards are not settled: one server per system, many clients, capabilities discovered at runtime.
The harder half of interoperability is not the wire format. It is semantics. Two
services can both expose a search tool and mean different things by relevance,
freshness and completeness. A model composing them has no way to know unless the
descriptions say so. Interface design for a model consumer — task-granular rather than
resource-granular, explicit about what a tool does not cover, honest in its error
prose — is a genuinely new API design skill, and most existing APIs are badly shaped for
it.
What multi-agent architectures will and will not fix
Multi-agent systems are often presented as the answer to long-horizon fragility: split the work, give each agent a narrower role, coordinate.
The part that works is real. A narrow agent with five tools selects among them more reliably than a general agent with forty, and a supervisor that decomposes a task into independently verifiable subtasks converts one long run into several short ones — which is a direct attack on the exponent.
The part that does not work is the assumption that coordination is free. Every handoff is a lossy serialisation of context between processes that cannot query each other's reasoning. Distributed systems problems reappear in full: partial failure, inconsistent state, deadlock when two agents wait on each other, and debugging across processes with no shared clock.
The honest summary: multi-agent helps when subtasks are genuinely independent and each has a verifiable result. It hurts when the coordination overhead exceeds the reliability gain, which is more often than the architecture diagrams suggest.
Where agents will actually live
Today most agents live in a chat window, which is a transitional interface — it is the lowest-effort way to expose a capability, not the best way to use one.
Two other placements are already more useful. Agents embedded in the tools where work already happens — the editor, the ticket queue, the terminal — inherit context for free and do not require a context switch. And agents running as background processes on a trigger, reporting into a channel a person already reads, remove the interface problem entirely by making the output the artefact rather than the conversation.
The interface question that has no good answer yet is approval. A run that needs permission for one step in the middle either blocks on a human — destroying the unattended value — or proceeds without it. Batched approval, pre-authorised action classes and dry-run-then-confirm are all partial answers, and none is settled.
What is safe to say
Structural claims, not numbers. The steps will get shorter and the deterministic scaffolding around them will get heavier. Verification will be where the engineering effort goes. Tool interfaces will standardise, and the winners will be the ones designed for a model consumer rather than wrapped from an existing REST API. Identity for non-human actors will stop being an afterthought. And the accountability question — who answers for what an agent did — will be settled by regulation and contract rather than by architecture.
What is not safe to say is when any of this arrives, or how capable the underlying models will be. Anyone quoting a figure for that is describing a feeling.
What to build now
Build the boring layer. Instrument every run so a wrong outcome is explainable. Build the evaluation harness before the impressive demo. Keep the agent's authority scoped to the task. Move every step you can into deterministic code. Design tool interfaces for a reader that has never seen your system and cannot ask.
None of that is speculative, and all of it survives whatever the models do next. The teams that will benefit most from a more capable model are the ones who already built the scaffolding to constrain the current one — the same shift already visible in how AI agents are changing software development.