Scheduled Agents, Dreaming and Q&A: Claude Managed Agents (Part 3 of 4)

Priyanka Phatak, Anthropic, Gabe Cemaj, Anthropic26:31 · Oct 2026 · 5,192 views
Thumbnail for Scheduled Agents, Dreaming and Q&A: Claude Managed Agents (Part 3 of 4) Watch on YouTube
TL;DR
  1. 1

    Claude Managed Agents can fan out work into separate sessions, each with its own tools, memory, and outcome definition.

  2. 2

    Deployments combine an agent definition, a schedule, initial messages, and resources such as memory stores, GitHub repositories, or files.

  3. 3

    Dreaming reviews past sessions and updates a memory store, but Anthropic recommends using evals to check whether the changes improve results.

Summary

Gabe Cemaj demonstrates how Claude Managed Agents can dispatch work into separate sessions, schedule recurring runs, and review past sessions through the Dreaming research preview. A deployment runs a chosen agent on a schedule with initial messages and attached resources. Dreaming analyzes transcripts from a selected period, such as the last 30 days, and can update the memory store when it finds gaps. The Q&A covers observability, long-running sessions, orchestration, workspaces, evals, skills, Claude Code, AWS, multi-tenancy, scaling, and on-premises use. The speakers say Managed Agents currently exposes events through the API and console, handles compaction for long sessions, and uses workspaces as its current tenancy boundary. They are candid about missing granular RBAC, the limits of current model support, and Dreaming's research-preview status. Their repeated advice is to evaluate agent behavior with task-specific evals rather than rely on intuition.

Key ideas
00:01

A main agent can fan out work into separate sessions

The demo asks an agent to analyze Google and Microsoft. The main agent evaluates what information it has, creates a custom dispatch tool, and starts an individual session for each financial artifact. Each session can contain multi-agent collaborative work and an outcome definition for self-supervision. Memory stores let the sessions learn from one another. This gives an application a way to coordinate several pieces of work without putting every task into one session.

01:14

A deployment combines an agent, a schedule, and resources

Deployments are intended to run recurring work through the API and SDK. A deployment takes an agent definition, a schedule, and initial messages. It can also receive resources such as memory stores, GitHub repositories, or files. The example runs a research desk weekly memo on a schedule, while the console can also trigger a run manually. Gabe describes the pieces as composable building blocks for custom UIs and workflows.

02:58

Dreaming reviews past sessions and updates memory

The Dreaming preview lets a user choose a memory store, a model, and optional instructions. It then analyzes a selected period of sessions, with the demo using the last 30 days. Managed Agents starts multiple subagents to inspect the transcripts, check whether the memory store captured needed information, find recurring problems, and identify possible instruction changes. In the example, the process found gaps in a skill and updated the memory store with what had been learned. Gabe says future versions could update skills and prompts directly.

04:52

The API exposes session events for observability

The speakers say the console provides a live view of a session, while the API exposes every event through the debug view. That includes events such as when a model call starts and finishes, which can be used to calculate latency. Users currently filter the full event stream on their own side. Because the product is API-based, a team could build a connector to its own observability stack, including an OTEL connector, although Anthropic does not want to prescribe one observability setup.

06:06

Compaction allows sessions to run for days

Anthropic says Managed Agents runs compaction so that agents can continue for long periods without their persisted state growing without limit. The speakers have seen 10-hour sessions in production from users. They also say an agent that performs a recurring daily task can keep running over a much longer period without the persistence store simply blowing up. The answer focuses on the persistence of the agent across recurring work, rather than promising one uninterrupted session forever.

07:50

Workspaces are the current boundary for tenancy and access

Workspaces let an organization place different customers or groups in separate areas and grant users access to specific workspaces. Users in one workspace can currently access all agents in that workspace. The speakers describe more granular RBAC as a roadmap item. For multi-tenant products, they recommend modeling tenants with workspaces instead of having customers bring their own API keys, because using end-user keys reduces the builder's observability. A company can use one workspace with its own customer-to-agent mapping or create a workspace per customer, with different management tradeoffs.

09:49

Managed Agents leaves harness design to the builder

The speakers use harness to mean different things depending on the audience. In Managed Agents, it mainly means the tool loop, context management, session state, and the mechanics that let an agent do its work. Builders often use the word for coordinating multiple agents and sessions into a larger unit of work. Managed Agents gives them a session as a primitive. To measure whether changes work, the speakers recommend evals with different task types, plus defined outcomes, rubrics, and maximum iterations.

12:05

Skills and multi-agent designs should be chosen through evals

The speakers say the boundary between a thick harness and thick skills changes as Claude becomes more capable. Skills are a useful abstraction today because they provide information and instructions the model needs, but some of that support may become unnecessary. They see multi-agent designs as more useful for some tasks, while acknowledging that the right choice depends on the work. Their practical recommendation is to run evals whenever a model or design changes, even though that creates ongoing maintenance.

15:11

Claude Code inspired the product, but Managed Agents is an API

Managed Agents took inspiration from the Claude Code harness because it works well for coding tasks. The speakers say they are building something more flexible for other tasks, where users bring their own context, information, and capabilities. Claude Code is an out-of-the-box terminal product, while Managed Agents is intended as API infrastructure that can scale and support reliable products. The two are therefore related, but Managed Agents is not simply Claude Code placed behind an API.

"Our best recommendation would be to run evals on your agent with different types of tasks that you want the agent to perform and see how the agent does on those tasks."Priyanka Phatak10:48
Who should watch
  • You are building an agent product that needs scheduled runs, separate sessions, or customer-facing API access.
  • You need a practical view of memory, evals, compaction, and observability for long-running agents.
  • You are deciding whether Claude Code, skills, multi-agent orchestration, or Managed Agents fits your application.