For the first couple of years of the agentic era, building a capable AI agent meant building almost everything yourself. The model gave you tokens in and tokens out; the rest — the loop that called tools, re-fed results, managed context, handled retries, held credentials, logged events — was yours to invent and maintain. Teams built elaborate harnesses, swapped war stories, and shipped brave things into production. That era is closing.
The Stack Is Growing Up
The progression has been gradual but consistent. Raw model APIs came first: maximum flexibility, maximum friction. Then higher-level SDKs arrived that packaged the agentic loop itself — tools, sandboxing, file access — so developers could focus on what the agent did rather than how it ran. Now a third layer is emerging: managed, hosted infrastructure where the platform owns the loop, the sandbox, session management, and observability, and the developer owns the domain knowledge, the task definition, and the context.
The practical split is clean. The “brain” — model reasoning, the agentic loop — is separated from the “hands” — the sandboxed container where code runs and tools execute. These two things used to live in the same process, which meant container setup blocked the model from thinking. Decoupling them so the model starts reasoning immediately while the container spins up in parallel produced roughly 60 percent faster time-to-first-token at the median, with even larger gains at the tail. That is not a small number; it is the kind of improvement that changes whether an interaction feels responsive or not.
Three Primitives Worth Understanding
The managed model introduced three durable abstractions.
An agent is the definition of what something does: the model, system prompt, tools, and any packaged skills it can invoke.
An environment is the definition of where it runs: container configuration, allowed network hosts, security policy.
A session combines the two into a durable cloud resource that persists a complete log of every event — every user message, model response, tool call, and result. That session log is not just bookkeeping. It is the substrate for two things that matter: observability (you can inspect what actually happened) and self-improvement (you can feed it back to the model to extract new insights and reorganize memory between runs).
The Harness Problem
One of the more useful ideas to surface from the transition is that harnesses — the scaffolding wrapped around a model — encode assumptions about what the model cannot do. Those assumptions become stale as models improve, and when that happens, the harness actively degrades performance.
A concrete case: an earlier model version had a tendency to wrap up tasks prematurely when approaching its context limit. The harness compensated with explicit context resets. A later, more capable model no longer exhibited that behaviour — but the resets remained, adding latency and breaking cache locality. The harness built to help was now hurting.
This is a pattern worth watching for. Any time a workaround gets baked into infrastructure to compensate for a model limitation, that workaround needs to be revisited when the model changes. The lesson is to build harnesses that are modular enough to swap individual components rather than treating them as permanent fixtures. Design for tomorrow’s model capabilities, not today’s.
What Running for Hours Actually Requires
Long-running agents — the kind that might work for hours or days on an SRE investigation or a complex research task — surface requirements that short-lived agents never reveal.
Context management is the clearest one. Traditional approaches treat the context window as coterminous with the session: once something falls out of context, it is gone. With a persistent session log, the harness can re-read relevant slices of past context back into the current window on demand. That changes what multi-hour tasks are feasible.
Security becomes sharper too. The sensible approach is to keep credentials entirely out of the model’s sight — store them in a vault, decrypt them only at tool-execution time, and never surface security tokens in the model’s context. Similarly, sandboxed execution can run inside a customer’s own private network rather than on a public cloud, with only outbound calls to the agent loop required. Neither of these is novel in software engineering; the novelty is making them the default rather than an afterthought.
Two Ideas Worth Watching
Dreaming is the name given to a periodic process that feeds session transcripts and current memory state back to the model in batch, extracts new insights, and reorganises memory so the next session starts with a better prior. It is early, but the direction — agents that improve through use rather than requiring explicit retraining — points toward something meaningfully different from current deployments.
Outcomes attempts to close the loop on task success. The developer defines a rubric: what success looks like, what failure looks like. A separate grader model evaluates the main agent’s work against that rubric in parallel and, if the task is not complete, the agent retries until it meets the criteria. This is a step toward agents that reliably achieve defined goals rather than making a single best attempt and stopping.
Where This Leaves the Practitioner
The harness has become the limiting factor between what a model can do and what a product actually exposes to users. The infrastructure layer absorbs more of that burden with each generation, which is genuinely useful — but it also means the quality of the domain knowledge, task definition, and context the developer provides matters more, not less. The loop is handled; the thinking is still yours.
Text summarized and optimized using Anthropic’s models and reviewed by a human.