Claude Agents Can Now Dream: How AI Engineers Should Use Anthropic’s New Agent Features Without Creating New Attack Paths
Anthropic’s newest Claude Managed Agents release is not just a feature drop. It is a preview of how production agent systems are moving from single-threaded assistants toward managed, inspectable, multi-agent control loops. The three headline capabilities are dreaming, outcomes, and multi-agent orchestration. Dreaming lets agents consolidate lessons across prior sessions. Outcomes let engineers define what “done” means through a rubric and have a separate grader push the agent through revisions. Multi-agent orchestration lets a lead agent delegate work to specialist agents with separate context windows, tools, prompts, and models. Anthropic announced dreaming as a research preview, while outcomes and multi-agent orchestration are public beta features for Claude Managed Agents (Anthropic announcement).
For AI engineers, the key insight is that these features are not independent. They form an agent improvement loop:
That loop is useful because most agent failures in production are not caused by a lack of raw model intelligence. They come from overloaded context, vague definitions of success, brittle tool use, memory drift, weak observability, and unsafe autonomy boundaries. VentureBeat’s conference report framed the same release around three enterprise problems: accuracy, learning, and bottlenecks in complex work (VentureBeat).
The rest of this piece explains how the three features work, how AI engineers should use them, and how to threat-model them with the MAESTRO framework. The goal is not to hype “self-improving agents.” The goal is to show how to build agents that improve under control.
The runtime underneath the features
Claude Managed Agents is Anthropic’s managed harness for long-running, asynchronous agent work. The platform centers on agents, environments, sessions, and events: an agent bundles the model, system prompt, tools, MCP servers, and skills; an environment supplies the container template; a session runs an agent against a task; and events preserve the interaction stream between the application and the agent (Claude Managed Agents overview).
That abstraction matters because the new features assume durable state. Outcomes need event history so a grader can evaluate progress. Multi-agent orchestration needs independent session threads so specialists can work without bloating the coordinator’s context. Dreaming needs memory stores and session transcripts so it can extract patterns after the work is over.
Anthropic’s engineering post on Managed Agents describes the deeper architecture as a separation between the “brain,” the “hands,” and the session log. The model harness, tool execution surfaces, and durable event history are separate interfaces, so a sandbox can fail without erasing the session, and a restarted harness can recover from the log (Anthropic engineering). This is why Managed Agents feels less like a chatbot wrapper and more like an agent operating system.
Engineers should read the new features through that lens. Dreaming is not a model update. Outcomes are not a prettier prompt. Multi-agent orchestration is not a Slack channel full of bots. They are runtime-level patterns for state, evaluation, and delegation.
Feature one: dreaming as controlled non-parametric learning
Dreaming is the most unusual of the three features because it gives agents a formal way to learn between sessions without changing model weights. The Dreams API reads an existing memory store and, optionally, up to 100 prior sessions, then writes a new output memory store that reorganizes memories, merges duplicates, replaces stale entries, and surfaces new patterns (Dreams docs).
That last detail is crucial: the input memory store is not modified. Dreaming produces a separate store. Engineers can inspect it, discard it, attach it to future sessions, or promote selected contents into a production memory store. This makes dreaming closer to a postmortem and runbook-generation process than a mystical “AI sleep” mechanism.
A good dream job should be narrow. Do not ask the system to “learn everything from all sessions.” Ask it to extract stable, reusable lessons from a curated batch:
dream = client.beta.dreams.create(
inputs=[
{”type”: “memory_store”, “memory_store_id”: project_lessons_store},
{”type”: “sessions”, “session_ids”: last_30_verified_sessions},
],
model=”claude-opus-4-7”,
instructions=”“”
Extract reusable lessons for our code-review agent.
Keep verified repo conventions, recurring failure modes, and tool-specific fixes.
Ignore one-off user preferences, unverified hypotheses, outages, secrets, and transient errors.
Write candidate playbooks that humans can review before promotion.
“”“,
)
Use dreaming when the agent repeats mistakes across runs. Examples include using the wrong CLI flags, misunderstanding a repo layout, mishandling a file format, missing recurring test failures, or rediscovering the same debugging workflow every week. Do not use dreaming as a replacement for deterministic configuration. If a rule belongs in code, policy, or a tool schema, put it there.
Dreaming also changes the security model. A memory store can become a long-lived influence channel. If bad information lands in memory, future sessions may treat it as trusted context. Dreaming can clean memory, but it can also consolidate poisoned lessons if the input sessions are compromised. That is why dream outputs need review gates, provenance checks, and promotion workflows.
The recommended pattern is a three-store layout. Use a read-only organization store for stable standards. Use a read-only project store for verified architecture and domain facts. Use a read-write working store for session lessons. Run dreams over the working store and recent verified sessions, then promote only reviewed outputs into the project store.
Feature two: outcomes as a production-grade definition of done
Outcomes solve the “looks done” problem. In normal agent workflows, the model may stop when an artifact appears plausible. Outcomes make “done” explicit by letting the developer define a rubric, then letting a separate grader evaluate the artifact and return gaps to the working agent until the criteria are satisfied, the iteration budget is reached, or the outcome fails (Define outcomes docs).
This is the managed version of an evaluator-optimizer loop. Anthropic’s general agent guidance says evaluator-optimizer workflows work best when evaluation criteria are clear and iterative refinement provides measurable value (Anthropic agent guidance). Outcomes are useful because they turn that design pattern into a session primitive with observable lifecycle events.
A good outcome rubric should look less like a prompt and more like acceptance criteria. For a pull request review agent:
client.beta.sessions.events.send(
session_id=session.id,
events=[{
“type”: “user.define_outcome”,
“description”: “Review this pull request for correctness, tests, and security.”,
“rubric”: {
“type”: “text”,
“content”: “”“
# PR Review Rubric
## Correctness
- Identify behavior changes introduced by the diff.
- Flag likely runtime errors with file paths and line references.
- Separate confirmed bugs from speculative concerns.
## Test Coverage
- Check whether changed behavior has tests.
- Recommend exact tests when coverage is missing.
## Security
- Review auth boundaries, input validation, secrets, dependencies, and data exposure.
- Escalate any issue that could bypass permissions or leak user data.
## Output Quality
- Put blocking issues first.
- Include reproduction or verification steps for every blocking issue.
“”“
},
“max_iterations”: 5,
}]
)
Outcomes are especially useful for artifacts that are subjective but still auditable: code reviews, incident reports, migration plans, customer escalation summaries, technical design docs, research briefs, and generated documents. They are less useful when success is already fully captured by deterministic tests. If a unit test, schema validator, linter, or type checker can decide the question, run the tool and feed the result to the agent.
The grader is still an LLM, so treat outcomes as structured judgment, not mathematical proof. Research on LLM-as-a-judge systems shows that model-based evaluation can scale assessment but must be designed for reliability, bias control, and scenario fit (LLM-as-a-Judge survey). In production, pair outcomes with programmatic checks and human approval where authority matters.
The anti-pattern is rubric theater. A vague rubric such as “make this excellent, polished, and accurate” will produce a false sense of governance. A strong rubric has observable criteria, explicit constraints, and known failure modes. If human reviewers keep rejecting artifacts that the grader approves, the rubric is a bug.
Feature three: multi-agent orchestration as context sharding
Multi-agent orchestration solves context overload. A coordinator agent can delegate to specialists, each running in its own session thread with its own context, model, prompt, tools, and conversation history. All agents share the same container and filesystem, while the primary session stream gives a condensed view of the orchestration (Multiagent sessions docs).
