The first real shift in working with AI agents wasn’t the agents themselves — it was the moment teams stopped running them manually and started scheduling them like jobs. Claude Managed Agents (CMA) formalises that shift and adds something more interesting on top: agents that review their own past sessions and update their own memory.
Agents on a Clock
A deployment in CMA is straightforward: an agent definition, a cron schedule, an initial message, and optional resources such as memory stores or connected repositories. The agent runs on its own — spinning up, doing its work, shutting down. A simple example: a “Research Desk Weekly Memo” agent fires on the first of each month at 1 pm, runs a session, and writes a report. No babysitting required.
What makes this more than a dressed-up cron job is the durability underneath. CMA runs context compaction automatically; sessions can last hours or days (ten-hour sessions have been seen in production), and a persistent memory store means the agent can carry forward what it has learned across runs rather than starting cold every time.
Dreaming: An Agent Reviews Its Own Past
The most distinctive feature in this release is “dreaming” — an experimental, research-preview capability that lets an agent retrospectively analyse its own session history to improve its memory store.
The mechanism: a dreaming run spins up a CMA session with many sub-agents to analyse transcripts from prior sessions that used the same memory store. Those sub-agents look for gaps in encoded knowledge, recurring failure patterns, and weaknesses in the agent’s standing instructions, then update the memory store accordingly. The intended future direction extends this to skills, agent prompts, and sub-agent prompts — essentially a self-editing cycle that runs in the background.
Some teams have seen significant evaluation improvements after a dreaming run combined with a refreshed memory store. The honest qualifier is equally prominent, though: dreaming is experimental, proper evaluations are still required to confirm whether a given run actually improved outcomes, and the gains are not guaranteed. The right disposition toward it right now is “interesting signal to investigate” rather than “automatic improvement to deploy and forget.”
What the Q&A Revealed
The most practically useful part of the session was the Q&A, which surfaced the gaps practitioners always ask about before committing to a platform.
Access control. CMA’s current isolation primitive is the workspace — users and agents are separated per workspace, with everyone inside a workspace seeing everything. Fine-grained role-based access control (restricting which users can see or control which agents) is not yet available, though it is on the roadmap. For teams building multi-tenant products, the recommended pattern is one workspace per tenant, or a single workspace with a custom access-mapping layer built on top. One approach to avoid: issuing separate API keys per tenant (“bring your own key”), because it breaks observability.
Scaling. There are no exposed scaling parameters — no equivalent of Kubernetes autoscaling knobs. Anthropic manages the infrastructure; teams make API calls and hit rate limits like any API. For most use cases this is a feature, not a gap.
Observability. A full event stream is available — every model call, tool use, and latency measurement — through the console debug view or the API. There is no built-in OpenTelemetry export, but since everything is API-driven, a connector can be built. The recommended path to confidence in agent behaviour is evals with a rubric, not just log watching.
CMA versus Claude Code. These are genuinely different products for different contexts. Claude Code targets personal and coding workflows. CMA targets teams, organisations, and external product shipping — it took Claude Code’s underlying harness as inspiration but is built as an infrastructure-grade, multi-tenant API product. A managed-agent skill in Claude Code exists to ease the transition from personal agents to CMA deployments. Real-world deployments running on CMA already include Notion external agents and an Atlassian Jira integration.
Where This Points
The design philosophy underneath CMA is worth holding onto: rather than asking teams to specify agent topology — which agent calls which — the system lets the model decide its own coordination structure. The reasoning is that more flexible topologies outperform human-prescribed ones as models improve, and locking in a graph today may just constrain better future behaviour.
Scheduled agents, self-reviewing memory, and eventually self-editing prompts all follow the same logic: systems that need less constant human intervention as capability increases, and that accumulate useful knowledge rather than forgetting it run by run. That is the direction the infrastructure is moving in, and the interesting question is how quickly the evals will catch up to tell us when we can actually trust it.
Text summarized and optimized using Anthropic’s models and reviewed by a human.