Anthropic Managed Agents Add 'Dreaming': Background Outcomes Without Your Own Loop

If you have ever shipped an agent built on Claude, you know the operational tax. You write a loop that calls the model, hands it tools, parses tool calls, retries on transient errors, persists intermediate state somewhere, and pray that the long-running task does not silently die when your worker recycles. Anthropic’s Managed Agents platform is the company’s pitch to take that tax off your plate, and a new capability the team is calling “dreaming” pushes it further: agents can now run background tasks and explore outcomes on Anthropic’s own infrastructure, returning when they have something worth your attention.

That description sounds glossier than it is in practice. The interesting question is not whether dreaming is a clever feature — it is whether it changes the build-vs-buy math for teams shipping agentic apps on Claude.

What ‘Dreaming’ Actually Does (and Doesn’t)

Strip the metaphor and you get a fairly concrete shift. In the classic agent pattern you wrote yourself, your code is the conductor. You call the model, you receive a tool call, you execute the tool, you feed the result back, and the loop continues until the model emits a final message or you hit a timeout. The whole thing runs in your process, on your hardware, paid for in your latency budget.

“Dreaming” inverts the topology for tasks that do not need to be synchronous. Instead of holding a long-lived connection open while the agent reasons through fifteen tool calls, you hand the work to Managed Agents, walk away, and let Anthropic’s infrastructure carry the loop. The agent explores possible outcomes — different tool orderings, different branches of reasoning, different end states — in the background. When it is done, you get the result.

That is not the same as running an agent on a cron. The point is exploration: the agent is not just retrying a deterministic plan, it is searching across the space of what could happen and reporting back what it found. That is closer to how a research assistant works than how a workflow engine works.

A few practical implications follow from that:

• You stop owning the durable execution problem. No more deciding between Temporal, Inngest, Cloudflare Durable Objects, or a homegrown Redis-backed queue for your agent state. The state lives where the model lives.
• Observability changes hands. When the agent runs in your code, your traces are the source of truth. When it runs in Managed Agents, Anthropic’s dashboards are — for better and worse. You see what they expose.
• Cost shifts from per-token to something more opaque. You pay for the compute that backs the dreaming, not just the tokens consumed. That is fine when it is cheaper than your own infra and frustrating when it is not.

Build-vs-Buy: When Managed Agents Beat Your Own Loop

The honest answer for most teams: it depends on how much agent code you have already written.

If you are starting fresh — you have an idea for a Claude-powered agent and you have not yet picked a runtime — Managed Agents is the path of least resistance. You skip the entire category of work that has nothing to do with your product: durable state, retries, idempotent tool execution, observability plumbing. You write tools, you write a system prompt, you ship.

If you already have a battle-tested agent loop on your own infrastructure, the calculus inverts. You have already paid the operational tax. Your engineers know your traces. Your cost model is predictable. Moving to Managed Agents means giving up a control surface you have spent quarters tuning. The upside has to be more than convenience — it has to unlock something your current architecture cannot do.

Dreaming, if it works as described, is the kind of capability that might pass that bar. Background exploration of a large outcome space is genuinely hard to build yourself. It is not just “run the agent for longer.” It is parallel branches, scoring, pruning, and reasoning about which branch was actually the best — all wrapped in a budget. If Anthropic ships a clean primitive for that, teams that try to roll it themselves are signing up for a research project.

The teams who should be most cautious are the ones in the middle: they have a working agent on their own stack, but it is not particularly differentiated. They could rebuild it on Managed Agents in a week. The question is whether the migration is worth the lock-in, because once your agent loop lives inside one provider’s runtime, switching becomes a real project.

The Tradeoffs You’re Signing Up For

There are four worth thinking about hard before you commit:

Lock-in. Managed Agents is Anthropic’s runtime. Your agent’s state, traces, and execution semantics live there. The longer you run on it, the harder it is to leave. This is the same lock-in story as every managed platform — it is not a reason to avoid it, it is a reason to be deliberate about which agents you put there.

Debugging. When an agent fails in your own loop, you reach for your logs. When it fails inside someone else’s runtime, you reach for their dashboards and their support. Anthropic has a strong incentive to make this good, but it is structurally a different debugging experience.

Cost surprises. Background exploration sounds great until the agent dreams its way through a million tokens you did not budget for. Whatever guardrails Anthropic exposes — token caps, time caps, branch caps — read them carefully and set them before you ship.

Composition with your existing infra. Your agent probably needs to call your APIs, your database, your auth system. That means tool definitions, network egress, and secrets management have to play nicely with a runtime you do not own. Test that path early.

The bet underneath all of this is that the agent runtime is going to look more like a database than like a library. You do not run your own Postgres for every app. You probably will not run your own agent loop forever either. If that prediction is right, Anthropic positioning itself as the runtime — and dreaming as a capability that is genuinely hard to replicate — is a strategically important move, not a feature drop.

Whether you should be an early adopter depends on whether you would rather own your agent’s runtime today, or own your product’s surface and let someone else carry the durable execution problem.