15  New in Claude Managed Agents: Dreaming, Outcomes, and Multiagent Orchestration

15.1 Agents That Reflect, Grade, and Delegate

On May 19, 2026, Anthropic announced three major additions to Claude Managed Agents: Dreaming, Outcomes, and Multiagent Orchestration. Together, these features moved managed agents from capable executors to self-improving systems that review their own work, grade their quality, and decompose complex tasks across specialized subagents.

The three features address different parts of the agent quality loop:

• Dreaming addresses learning over time — reviewing past sessions to find patterns.
• Outcomes addresses quality measurement — grading work against rubrics.
• Multiagent orchestration addresses task complexity — decomposing hard problems across specialists.

This chapter covers each feature, how they work, and how they compose.

15.2 Dreaming: Learning from Experience

15.2.1 What Dreaming Does

Dreaming is a scheduled process in which an agent reviews its past sessions to find patterns and self-improve. The name evokes human dreaming — the offline processing of experiences during sleep — and the analogy is apt: dreaming is the agent’s reflection phase, where it consolidates what it has learned and identifies ways to do better.

During a dreaming session, the agent:

1. Reviews recent sessions — what tasks it worked on, what approaches it took, what outcomes resulted.
2. Identifies patterns — recurring task types, effective approaches, common mistakes, missed opportunities.
3. Updates its knowledge — writes insights to memory (Chapter 12), refines its procedures, adjusts its strategies.

Note

Dreaming is the mechanism by which an agent gets better with experience. Without it, each session is independent — the agent doesn’t learn from its past. With dreaming, the agent accumulates wisdom: it recognizes patterns it’s seen before, avoids approaches that didn’t work, and double down on ones that did.

15.2.2 How Dreaming Is Scheduled

Dreaming runs on a schedule — it’s not continuous. An agent might dream nightly, reviewing the day’s sessions, or weekly, consolidating a longer period. The schedule is configurable, letting you balance the value of reflection against the cost (dreaming consumes tokens for the review process).

15.2.3 What Dreaming Produces

The outputs of dreaming are memory updates — new or refined knowledge stored in the agent’s memory (Chapter 12). These might include:

• Effective approaches: “For tasks involving X, approach Y works well.”
• Common pitfalls: “When doing X, watch out for Y.”
• Pattern recognition: “Tasks that look like X are usually best handled by Y.”
• Self-corrections: “I tended to over-complicate X; simpler approaches are better.”

These memories influence future sessions, making the agent progressively more effective.

15.3 Outcomes: Rubric-Based Grading

15.3.1 What Outcomes Does

Outcomes is a feature for grading an agent’s work against rubrics — structured quality criteria — in a separate context. After an agent completes a task, an evaluation context grades the work against defined rubrics, producing a quality score and feedback.

The key architectural choice is that grading happens in a separate context from the work itself. This ensures the grading is unbiased — the evaluator doesn’t share the worker’s context (and its potential biases). It’s the agent equivalent of code review by someone who didn’t write the code.

15.3.2 The Improvement: Up to 10 Points

Anthropic reported that outcomes-based grading could improve agent performance by up to 10 points on quality metrics. The mechanism is iterative: the agent produces work, the outcome evaluator grades it, and if the grade falls short, the agent iterates with the feedback until the work meets the rubric.

[Task] → [Agent produces work] → [Outcome evaluator grades]
                                        ↓
                                   [Meets rubric?]
                                   ↓ No        ↓ Yes
                            [Feedback to agent]  [Done]
                                   ↓
                            [Agent revises] → [Re-grade] → ...

Tip

The “up to 10 points” improvement is significant because it comes from structured iteration, not from a better model or more context. The agent produces the same quality of initial work; the outcome evaluator catches deficiencies and drives improvement. This is a generalizable pattern: grading + iteration reliably improves quality, regardless of the model’s baseline capability.

15.3.3 Designing Effective Rubrics

The quality of outcomes-based grading depends on the rubric — the structured criteria the evaluator applies. Effective rubrics:

• Decompose quality into checkable criteria (like the rubrics in Chapter 8’s context engineering).
• Are specific enough to grade consistently (not “is it good?” but “does it handle edge case X?”).
• Cover the dimensions that matter for the task (correctness, completeness, style, security).

# Example outcome rubric for a code generation task
rubric:
  - criterion: "All specified tests pass"
    weight: 30
  - criterion: "Code follows project conventions (inferred from codebase)"
    weight: 20
  - criterion: "Edge cases are handled (null inputs, empty lists, large inputs)"
    weight: 25
  - criterion: "No security vulnerabilities (OWASP Top 10)"
    weight: 25

15.4 Multiagent Orchestration

15.4.1 What Multiagent Orchestration Does

Multiagent orchestration lets a lead agent delegate to specialists — each with its own model, prompt, and tools — working in parallel on a shared filesystem. It’s the managed-agents version of the patterns described in Chapters 2, 3, and 10, but with infrastructure support: shared state, coordination, and observability.

In a multiagent orchestration:

1. The lead agent receives a task and decomposes it.
2. The lead delegates subtasks to specialist agents, each configured for its role (model, prompt, tools).
3. Specialists work in parallel on a shared filesystem, each doing its part.
4. The lead synthesizes the specialists’ outputs into a final result.

15.4.2 Specialists with Own Model, Prompt, and Tools

A key feature is that each specialist can have its own configuration:

• Own model: A security specialist might use Opus (deep reasoning); a formatting specialist might use Sonnet (fast, routine).
• Own prompt: Each specialist has a role-specific system prompt.
• Own tools: A coding specialist has code tools; a research specialist has web tools; a review specialist has read-only tools.

This per-specialist configuration optimizes each part of the task for its specific demands, rather than forcing one configuration on all subtasks.

15.4.3 Shared Filesystem

Specialists work on a shared filesystem — they can read each other’s outputs and write files that others will use. This enables coordination that isolated subagents (Chapter 10) cannot achieve. Specialist A produces an artifact; Specialist B reads it and builds on it; the lead synthesizes.

15.4.4 Working in Parallel

Specialists run in parallel, each in its own context. The lead monitors progress, handles dependencies (waiting for one specialist’s output before starting another), and synthesizes results. This parallelism makes complex tasks faster than sequential execution.

         ┌─────────────────────────┐
         │      Lead Agent         │
         │  (decomposes, synthe-   │
         │   sizes, monitors)      │
         └────────┬────────────────┘
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
  ┌─────────┐ ┌─────────┐ ┌─────────┐
  │ Spec A  │ │ Spec B  │ │ Spec C  │
  │ (Opus,  │ │(Sonnet, │ │ (Opus,  │
  │ review) │ │ format) │ │ secure) │
  └────┬────┘ └────┬────┘ └────┬────┘
       │          │          │
       └──────────┼──────────┘
                  ▼
         ┌─────────────────┐
         │ Shared Filesystem│
         └─────────────────┘

15.5 Webhooks: Notification When Done

Multiagent orchestrations can be long-running. To support asynchronous workflows, Managed Agents provides webhooks that notify your application when an orchestration (or a specialist within it) completes. This lets you trigger downstream processing without polling.

# Conceptual webhook setup
agent.orchestrate(
    task="Review and refactor the payment module",
    specialists=[...],
    webhook_url="https://your-app.com/agent-complete"
)

# Your application receives a POST when done

15.6 Console Tracing for Every Step

For observability and debugging, Managed Agents provides console tracing for every step of an orchestration. You can see:

• How the lead decomposed the task.
• Which specialists were spawned and when.
• What each specialist did (tool calls, reasoning).
• How results were synthesized.
• Where time and tokens were spent.

This traceability is essential for debugging complex orchestrations and for building trust in autonomous agent behavior.

15.7 How the Three Features Compose

Dreaming, outcomes, and multiagent orchestration are designed to work together:

1. Multiagent orchestration handles complex tasks by decomposing them across specialists.
2. Outcomes grades the quality of the orchestrated work, driving iteration until rubrics are met.
3. Dreaming reviews sessions (including orchestrated ones) to learn patterns for future work.

Together, they form a quality improvement loop: orchestrate complex work, grade it against rubrics, and learn from the results. Over time, the agent gets better at orchestration (from dreaming), produces higher-quality work (from outcomes-driven iteration), and handles more complex tasks (from multiagent decomposition).

Feature	Addresses	Mechanism
Dreaming	Learning over time	Scheduled review of sessions; updates memory
Outcomes	Quality measurement	Rubric-based grading in separate context; drives iteration
Multiagent orchestration	Task complexity	Lead delegates to specialists (own model/prompt/tools) on shared filesystem

15.8 Dreaming in Depth

Dreaming is one of the most conceptually interesting features of Managed Agents, and its practical implications are significant.

15.8.1 What Happens During a Dream Session

A dreaming session is a scheduled review where the agent examines its past work. The process:

1. Select recent sessions for review (e.g., the last day’s or week’s sessions).
2. For each session, analyze:
   • What task was attempted?
   • What approach was taken?
   • What was the outcome?
   • Was the approach effective? Could it be improved?
3. Identify patterns across sessions:
   • Recurring task types and their best approaches.
   • Common mistakes or suboptimal patterns.
   • Missed opportunities (better approaches not taken).
4. Generate insights — generalizable lessons from the specific experiences.
5. Write insights to memory for future use.

The dreaming session itself is an agent session — the agent reviewing its own work is itself using agent capabilities. This meta-level processing is what enables genuine learning.

15.8.2 Types of Insights from Dreaming

Dreaming can produce several types of insights:

Insight Type	Example
Approach refinement	“For SQL migration tasks, generating the migration first and then writing tests is more effective than test-first.”
Error pattern	“I tend to forget to handle the empty-list case in map operations. I should add an explicit check.”
Efficiency gain	“For this codebase, reading the test file first gives me enough context to implement features without reading all related source files.”
User preference	“This user prefers detailed commit messages with rationale, not just descriptions of changes.”
Domain knowledge	“The payment service has a 30-second timeout; long-running operations should use the async API.”

These insights make the agent progressively more effective at its specific work.

Note

The key insight about dreaming is that it turns experience into expertise. Without dreaming, an agent that has processed 1,000 tasks has 1,000 independent experiences — no wiser than after the first. With dreaming, the agent synthesizes those experiences into accumulated wisdom, genuinely improving over time.

15.8.3 Scheduling Dream Sessions

Dream sessions consume tokens (the review process involves reading session logs and reasoning about them), so they should be scheduled thoughtfully:

• Frequency: Nightly (for active agents) or weekly (for less active ones).
• Scope: Review the sessions since the last dream session.
• Token budget: Cap the dream session’s token consumption.

The optimal frequency depends on the agent’s activity level. An agent processing dozens of tasks daily benefits from nightly dreaming. An agent processing a few tasks per week may only need weekly dreaming.

15.9 Outcomes in Depth

The outcomes feature — rubric-based grading in a separate context — deserves deeper examination because the “up to 10 points” improvement claim is significant.

15.9.1 Why Separate Context Matters

The evaluator runs in a separate context from the agent that produced the work. This separation is crucial because:

• No shared bias: The evaluator doesn’t share the producer’s context, so it isn’t biased by the same information.
• Fresh perspective: The evaluator approaches the work as a new reviewer, not as the author.
• No anchoring: The evaluator isn’t anchored to the producer’s reasoning path.

This is the agent equivalent of blind peer review — the evaluator judges the work on its merits, not on the reasoning that produced it.

15.9.2 The Iteration Loop

The outcomes feature doesn’t just grade — it drives iteration. When work doesn’t meet the rubric:

1. The evaluator grades and produces specific feedback (“Edge case X is not handled”).
2. The feedback goes to the agent, which revises the work.
3. The revised work is re-graded.
4. The loop continues until the rubric is met or a maximum iteration count is reached.

This loop is what produces the “up to 10 points” improvement. The initial work may be mediocre; the iteration driven by specific, rubric-based feedback brings it up to standard.

15.9.3 Designing Effective Rubrics (Expanded)

The quality of outcomes-based grading depends entirely on the rubric. Let’s expand on effective rubric design:

Characteristics of good rubric criteria:

• Specific: “Handles null inputs gracefully” is specific; “is robust” is not.
• Checkable: The evaluator can determine pass/fail objectively.
• Comprehensive: Covers all important quality dimensions.
• Weighted: More important criteria carry more weight.

Example rubric for a code generation task:

rubric:
  - criterion: "All specified tests pass"
    weight: 25
    check: "run_tests"
  - criterion: "Edge cases handled (null, empty, overflow)"
    weight: 20
    check: "manual_review"
  - criterion: "Follows existing codebase conventions"
    weight: 15
    check: "compare_with_codebase"
  - criterion: "No security vulnerabilities"
    weight: 25
    check: "security_scan"
  - criterion: "Code is readable and well-commented"
    weight: 15
    check: "manual_review"

The rubric decomposes “good code” into specific, checkable criteria with appropriate weights. The evaluator can grade each criterion independently and produce targeted feedback.

15.10 Multiagent Orchestration in Depth

15.10.1 When to Use Orchestration

Multiagent orchestration is powerful but adds complexity. Use it when:

• The task is genuinely complex — too much for a single agent to handle well.
• Subtasks benefit from specialization — different parts need different models, prompts, or tools.
• Parallelism provides meaningful speedup — the subtasks can run concurrently.
• The coordination overhead is justified — the benefits exceed the orchestration cost.

Don’t use orchestration for simple tasks where a single agent suffices. The overhead of decomposition, delegation, and synthesis isn’t worth it for trivial work.

15.10.2 The Lead Agent’s Role

The lead agent in an orchestration has a distinct role:

1. Decompose the task into subtasks.
2. Assign each subtask to the appropriate specialist.
3. Monitor progress across specialists.
4. Handle dependencies — wait for one specialist’s output before starting another.
5. Synthesize results into a final output.

The lead agent doesn’t do the specialist work itself — it orchestrates. This requires a capable model (typically Opus) because orchestration reasoning is complex.

15.10.3 Specialist Design

Each specialist should be optimized for its role:

Specialist Role	Model	Prompt Focus	Tools
Code implementer	Opus	“Write correct, efficient code”	read, write, edit, bash
Security reviewer	Opus	“Find security vulnerabilities”	read, grep
Test writer	Sonnet	“Write comprehensive tests”	read, write, bash
Documentation writer	Sonnet	“Write clear, accurate docs”	read, write
Fact checker	Sonnet	“Verify claims against sources”	read, web_search

Matching model, prompt, and tools to each specialist’s role optimizes quality and cost.

15.10.4 Shared Filesystem Coordination

The shared filesystem enables coordination patterns that isolated subagents can’t achieve:

• Sequential dependency: Specialist A produces an artifact; Specialist B reads and extends it.
• Review cycle: Specialist A produces; Specialist B reviews; A revises based on feedback.
• Parallel contribution: Multiple specialists write to different files; the lead assembles them.

The shared filesystem makes these patterns natural — specialists communicate through files, not through message passing.

15.11 Observability and Debugging

For complex orchestrations, observability is essential. The console tracing feature provides:

• Decomposition visibility: See how the lead decomposed the task.
• Specialist tracking: See which specialists ran, when, and what they did.
• Tool call tracing: Every tool call by every specialist is logged.
• Result synthesis: See how the lead combined specialist outputs.
• Token accounting: See where tokens were spent across the orchestration.

This tracing is invaluable for debugging (“why did the orchestration produce this result?”) and for optimization (“which specialist consumed the most tokens?”).

15.12 Key Takeaways

• Three features announced May 19, 2026: Dreaming, Outcomes, and Multiagent Orchestration — each addressing a different part of the agent quality loop.
• Dreaming is a scheduled process where the agent reviews past sessions to find patterns and self-improve, writing insights to memory.
• Outcomes grades work against rubrics in a separate context, driving iterative improvement of up to 10 points on quality metrics.
• Multiagent orchestration lets a lead agent delegate to specialists — each with its own model, prompt, and tools — working in parallel on a shared filesystem.
• Webhooks notify your application when an orchestration completes, supporting asynchronous workflows.
• Console tracing provides observability into every step — decomposition, specialist spawning, tool calls, synthesis.
• The three features compose into a quality improvement loop: orchestrate (complexity), grade (quality), learn (over time).
• Effective rubrics are specific, decompose quality into checkable criteria, and cover the dimensions that matter for the task.
• Per-specialist configuration (own model, prompt, tools) optimizes each part of a complex task for its specific demands.