Claude Managed Agents: Dreaming, Outcomes, and Multi-Agent Orchestration Explained

Anthropic launched Claude Managed Agents as a hosted harness for long-running agent work. On April 8, 2026, the initial public beta arrived on the Claude Platform. Then on May 6, 2026, Anthropic shipped three additions that changed the scope of what the platform can do: dreaming (research preview), outcomes (public beta), and multi-agent orchestration (public beta).

This post covers all three together - what they are, how they connect, and when to reach for them over a local agent loop.

Last updated: June 10, 2026

---

What Changed in the April-May 2026 Updates

The April 8 launch gave developers a managed harness with secure sandboxing, credential management, durable session state, and persistent event history - replacing the need to build your own agent loop from scratch.

The May 6 update added three distinct primitives on top of that foundation:

According to Anthropic's announcement, these features were designed to work as a loop, not independently. Dreaming captures lessons across sessions. Outcomes enforce quality within a session. Multi-agent orchestration distributes the work across parallel sessions. Together they address the three most common failure modes in production agent systems: memory drift, undefined success criteria, and context overload.

---

Dreaming (Research Preview): How Agents Learn Between Sessions

Dreaming is the most unusual of the three features. It gives agents a formal mechanism to improve between sessions without retraining the model.

The Dreams API reads an existing memory store and up to 100 prior sessions, then writes a new output memory store. That output store reorganizes memories, merges duplicates, replaces stale entries, and surfaces patterns that span multiple sessions. The input memory store is not modified - dreaming produces a separate store that engineers can inspect, discard, or promote.

Ken Huang's analysis describes this accurately: dreaming is closer to a postmortem and runbook-generation process than any kind of "AI sleep" mechanism. It is non-parametric memory consolidation - the model weights do not change. What changes is the structured context attached to future sessions.

The pattern Anthropic recommends is a three-store layout:

• A read-only organization store for stable standards
• A read-only project store for verified architecture and domain facts
• A read-write working store for session lessons

Run dreams over the working store and a curated set of recent verified sessions, then promote reviewed outputs into the project store. Never pipe unvetted session transcripts directly into production memory.

Harvey, the legal AI company, reported roughly 6x improvement in completion rates after enabling dreaming - their agents stopped rediscovering filetype workarounds and tool-specific patterns every session.

Dreaming access currently requires a separate request form. It is not available to all API accounts by default.

---

Outcomes (Public Beta): Defining Done with Rubric Agents

Outcomes solve what Anthropic calls the "looks done" problem. Without them, an agent stops when its output appears plausible. With outcomes, you write an explicit rubric describing what success looks like. A separate grader agent evaluates the artifact against that rubric in its own context window - it never sees the working agent's reasoning, so it cannot be anchored to partial results.

When the grader finds gaps, it returns them to the working agent, which takes another pass. This continues until the criteria are satisfied, the iteration budget is exhausted, or the outcome is marked failed.

According to Anthropic's internal benchmarks, outcomes improved task success by up to 10 points over a standard prompting loop, with the largest gains on the hardest problems. For structured file generation specifically: +8.4% task success on docx files and +10.1% on pptx files.

The rubric can handle both objective and subjective criteria. Wisedocs, a document verification company, used outcomes to enforce their internal review guidelines and reported reviews running 50% faster while staying aligned with their team's standards.

Outcomes integrate with the new webhooks support: define an outcome, start a session, and receive a webhook notification when the agent satisfies the rubric. This makes it practical to fire-and-forget agent tasks from an API call without polling.

For developers already familiar with evaluator-optimizer patterns from Anthropic's building effective agents guide, outcomes are the managed version of that same loop - but with observable lifecycle events and no custom eval infrastructure to maintain.

---

Multi-Agent Orchestration (Public Beta): Delegating to Specialists

Multi-agent orchestration lets a lead agent delegate work to specialist agents, each with its own model, system prompt, tools, and context window. The lead agent does not share its context with subagents - they operate independently, which is the key architectural difference from a single large-context run.

From Anthropic's announcement:

A lead agent can run an investigation while subagents fan out through deploy history, error logs, metrics, and support tickets.

Specialists work in parallel on a shared filesystem. Events are persistent across all sessions, so the lead agent can check in on subagent progress mid-workflow. Every step is traceable in the Claude Console: which agent did what, in what order, and why.

Netflix's platform team used this to analyze logs from hundreds of builds across different sources. With changes that affect thousands of applications, the multi-agent pattern allows batches to be analyzed in parallel and only the recurring patterns to be surfaced.

Spiral (by Every) combined multi-agent orchestration with outcomes in an interesting way: a lead agent on Claude Haiku handles routing and follow-up questions, then delegates drafting to subagents running on Claude Opus. Each draft is scored against a rubric before being returned to the user.

This is covered in more detail in building multi-agent workflows with Claude Code and the broader agent architecture guide.

---

When to Use Managed vs Local Agents

The official docs frame the choice clearly: Messages API for custom loops and fine-grained control, Managed Agents for long-running tasks and asynchronous work. Here is a more detailed framework:

The HIPAA and Zero Data Retention gaps are worth noting for teams in regulated industries - Managed Agents is stateful by design, which currently makes it ineligible for both. You can delete sessions and uploaded files through the API, but the session data persists server-side while the session is live.

---

Production Patterns: Cloudflare Workers + Managed Agents

Anthropic published a reference architecture on GitHub with Cloudflare Workers. The pattern uses a Workers edge layer to handle webhook callbacks, fan out tasks, and integrate Managed Agent sessions into existing application flows without a dedicated backend service.

The core loop looks like this:

1. Application sends a task to a Cloudflare Worker
2. Worker creates a Managed Agents session via the SDK
3. Session runs asynchronously in Anthropic's infrastructure
4. Webhook fires to the Worker on completion or failure
5. Worker writes the result back to the application

This pattern fits naturally with asynchronous background job queue patterns, where the session lifecycle maps directly to task management.

The SDK handles the beta header automatically. All Managed Agents endpoints require the managed-agents-2026-04-01 beta header on raw API calls.

---

Managed Outcomes vs Codex /goal: Practical Differences

Both Outcomes and Codex's /goal command define a target state and let an agent iterate toward it. They take different approaches.

For a deeper comparison, see Codex /goal vs Claude Managed Outcomes: Practical Differences.

---

Getting Started: API IDs, Quickstart, Common Gotchas

Quickstart: Follow the official quickstart. Create an agent (define model, system prompt, tools), create an environment, start a session, send events, stream responses.

Beta header: Raw API calls need anthropic-beta: managed-agents-2026-04-01. The Python and TypeScript SDKs set this automatically.

Dreaming access: Not enabled by default. Request access separately.

Common gotchas:

• Sessions store conversation history and sandbox state server-side. Zero Data Retention accounts cannot use Managed Agents.
• The Dreams API reads up to 100 prior sessions. Narrow your input set to verified, curated sessions - do not feed it everything.
• Outcomes iterate until a budget is hit, not indefinitely. Set a realistic max_iterations value or you will see truncated runs on hard tasks.
• Multi-agent subagents have their own context windows, which means they do not share the lead agent's accumulated reasoning. Pass context explicitly via the shared filesystem or event payloads.
• MCP tunnels and dreaming are in more limited research preview inside the broader beta. They require separate access requests.

---

Official Sources