AI Engineer · Published 2026-10-12

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

Open on YouTube ↗

Summary

Overview

  • Speaker: Anthropic Representative
  • Channel: AI Engineer
  • Main topic: Claude Managed Agents, Deployments, Dreaming, and Multi-Agent Orchestration
  • Purpose: To demonstrate advanced agent management capabilities, scheduled deployments, autonomous memory refinement (dreaming), and address technical questions from AI engineers regarding multi-tenancy, custom observability, and scaling. This session covers advanced features of Claude Managed Agents including deployments for scheduled recurring work, dreaming for self-improvement and memory store optimization, and an extensive Q&A session addressing telemetry, scaling, multi-tenancy, and API design.

Topic Map

Deployments and Scheduled Agent Work

  • Explanation: How to orchestrate recurring agent sessions using deployments tied to agent definitions, schedules, and initial messages.
  • Key claims:
    • Deployments allow agent execution on a schedule (e.g., monthly, daily).
    • Everything is API-based, allowing custom UIs and workflows built on top of SDKs.
  • Examples:
    • Setting up 'research-desk-weekly-memo' to run financial filing analysis automatically.
  • Terminology:
    • Deployments
    • Agent definition
    • Memory stores
    • Schedule
  • Why it matters: Enables fully autonomous background agent execution without manual triggering.

Dreaming: Autonomous Self-Improvement

  • Explanation: Dreaming allows agents to analyze past transcripts and memory stores across multiple sessions to surface learnings and update instructions.
  • Key claims:
    • Dreaming spawns sub-agents to analyze past session transcripts using memory stores.
    • It identifies gaps in skills or memory and automatically updates memory stores with improved learnings.
  • Examples:
    • Running dreaming over the last 30 days of financial analysis sessions to refine memory and fix skill gaps.
  • Terminology:
    • Dreaming
    • Sub-agents
    • Memory store
    • Self-supervision
  • Why it matters: Provides a mechanism for continuous agent improvement and memory refinement without human intervention.

Audience Q&A: Telemetry, Multi-Tenancy, and Tooling

  • Explanation: Detailed discussion answering engineer questions regarding observability, multi-tenancy isolation, evaluation (evals), and harness complexity.
  • Key claims:
    • All telemetry events (model requests, tool usage, latency metrics) are available via API and console debug views.
    • Multi-tenancy is currently handled via workspaces as primitives.
    • Evals are recommended to steer and verify agent performance.
  • Examples:
    • Questions about exporting telemetry to OTel, running agents for months, and managing multi-tenant customer workspaces.
  • Terminology:
    • Telemetry
    • Workspaces
    • Evals
    • Harness
    • Multi-tenancy
  • Why it matters: Addresses production-grade concerns for engineering teams deploying agents at scale.

Key Points

API-first agent platform

  • Explanation: All platform features like deployments, dreaming, and memory management are exposed via APIs and SDKs.
  • Evidence: Mentioned that developers can build custom UIs and workflows via the SDK.
  • Practical implication: Allows developers to deeply embed managed agents into custom application architectures.

Dreaming as memory maintenance

  • Explanation: Dreaming evaluates past session transcripts against memory stores to optimize future agent behavior.
  • Evidence: Demo of starting a dreaming job over the last 30 days of sessions.
  • Practical implication: Reduces stale instructions and accumulates institutional knowledge across sessions automatically.

Workspaces for multi-tenancy

  • Explanation: Workspaces act as the primary boundary for separating customer data and agent access control.
  • Evidence: Discussed during Q&A regarding separating customer data in enterprise settings.
  • Practical implication: Provides a clean partitioning method for multi-tenant applications.

Frameworks, Models & Processes

Claude Managed Agents Platform Architecture

  • How it works: Combines agent definitions, memory stores, deployments, and dreaming jobs into an API-driven ecosystem.
  • Components:
    • Agents
    • Memory stores
    • Deployments
    • Dreaming
    • Workspaces
  • When to use: When building recurring, autonomous, stateful multi-agent workflows at scale.

Examples & Case Studies

Speaker triggered a scheduled deployment for weekly financial filing analysis on Google and Microsoft.

  • Illustrates: Automated recurring agent tasks using deployments.
  • Lesson: Agents can execute complex multi-step workflows on a set schedule without human prompting.

Speaker ran a dreaming job across 30 days of sessions to review skill gaps and update memory.

  • Illustrates: Autonomous self-improvement and memory curation.
  • Lesson: Dreaming allows agents to learn from past executions and improve future reliability.

Actionable Takeaways

  • Immediate:
    • Use deployments for scheduled background agent tasks.
    • Leverage dreaming jobs to audit and update memory stores periodically.
  • Strategic:
    • Design multi-tenant applications around workspace primitives.
    • Rely on evals to steer and validate agent performance over time.
  • Questions to investigate:
    • How to integrate custom observability stacks with platform telemetry?
    • What are the best practices for implementing fine-grained RBAC across workspaces?

Claims Worth Verifying

  • All platform interactions and telemetry are fully accessible via API and SDK. (technical architecture)
  • Dreaming jobs analyze transcript history to update memory stores with learned improvements. (agent behavior)

Notable Quotes

"What if you want to do recurring work? What if you want to do you want to have a list of companies you care about and you want every day at 9 a.m. or first of the month to do the analysis over all of these companies on a schedule?" "What dreaming is, it lets you select the memory store, you can select the model, you can give it custom instructions if you want to, but we'll use the default prompt."

Compressed Summary

  • Deployments enable scheduled, recurring agent execution.
  • Dreaming automates memory store optimization and self-improvement by analyzing past transcripts.
  • Platform is API-first, supporting custom UIs and integrations via SDKs.
  • Workspaces provide multi-tenant isolation and organization primitives.
  • Keywords: deployments, dreaming, memory, agents, telemetry
  • Core insight: Claude Managed Agents provide robust primitives for scheduled execution, autonomous memory refinement via dreaming, and multi-tenant workspace management.

Core insights

6
Mechanismhigh noveltymoderate evidence

Dreaming is a self-supervision loop in which a scheduling/analysis job spawns sub-agents to mine past session transcripts against a memory store, detect gaps in skills or memory, and rewrite the memory store with improved learnings — automating memory maintenance that is normally a human editing task.

Why it matters

It moves memory/instruction curation from manual prompt engineering into an autonomous background job, meaning the agent's own context becomes a mutable artifact produced by the agent system rather than a static config.

Generalization

Any long-lived agent can be given an offline 'reflection' pass over its own transcripts to rewrite its own persistent context — applicable beyond this product to any stateful agent with a durable memory abstraction.

Dreaming spawns sub-agents to analyze past session transcripts using memory stores.
Open source video
It identifies gaps in skills or memory and automatically updates memory stores with improved learnings.
Open source video
Architecturemedium noveltystrong evidence

The deployment abstraction binds a schedule, an agent definition, an initial message, and a memory store into a recurring workload — the unit of execution is a scheduled deployment, not a user-triggered session.

Why it matters

It converts agents from request/response responders into unattended background jobs, requiring idempotency, failure alerting, and cost controls that interactive sessions do not need.

Generalization

Agent platforms converge on cron-like scheduling as a first-class primitive; the hard engineering problems shift to failed-run detection and bounding unattended cost.

Deployments allow agent execution on a schedule (e.g., monthly, daily).
Open source video
What if you want to do recurring work? What if you want to do you want to have a list of companies you care about and you want every day at 9 a.m. or first of the month to do the analysis over all of these companies on a schedule?
Open source video
Mechanismmedium noveltymoderate evidence

Dreaming is exposed as a parameterized job (selectable memory store, selectable model, optional custom instructions, default prompt), implying the self-improvement pass is itself a configurable, swappable component rather than a fixed internal routine.

Why it matters

If the reflection pass can run on a different model or prompt than the production agent, memory curation becomes a separately tunable subsystem an engineer can optimize and evaluate independently.

Generalization

Self-improvement loops can be decoupled from the runtime they improve — a 'meta-agent' configuration surface separate from the 'worker agent' configuration.

What dreaming is, it lets you select the memory store, you can select the model, you can give it custom instructions if you want to, but we'll use the default prompt.
Open source video
Architecturemedium noveltystrong evidence

The platform is API-first: deployments, dreaming, and memory management are all exposed via APIs and SDKs, with custom UIs and workflows built on top of the SDK rather than on the console.

Why it matters

It forces a headless-primitives architecture where the console is just one client, so every capability must be complete and stable at the API layer — and integrations/automation are first-class rather than bolt-ons.

Generalization

Agent infrastructure is trending toward composable platform primitives (agent, memory, schedule, workspace) that application teams embed, rather than end-user products.

Everything is API-based, allowing custom UIs and workflows built on top of SDKs.
Open source video
Mental Modellow noveltystrong evidence

Multi-tenancy isolation is delegated to workspaces as the platform primitive, rather than to application-level tenant identifiers.

Why it matters

Choosing the isolation boundary determines where access control, data separation, and blast radius live; workspace-as-boundary shifts tenancy concerns into the platform layer but leaves fine-grained RBAC across workspaces as an acknowledged open problem.

Generalization

Tenancy boundaries in agent platforms map onto whatever the platform treats as the top-level organizational container, and granularity of permissions is typically the unresolved follow-on.

Multi-tenancy is currently handled via workspaces as primitives.
Open source video
Practicemedium noveltystrong evidence

Observability is delivered as queryable API telemetry (model requests, tool usage, latency) alongside console debug views, making agent traces programmatically consumable rather than dashboard-only.

Why it matters

Programmatic telemetry is the prerequisite for automated eval pipelines, regression detection, and cost monitoring on unattended deployments; the unresolved piece is export into existing observability stacks.

Generalization

Agent platforms are converging on trace-level telemetry APIs as the substrate for both evaluation and production monitoring.

All telemetry events (model requests, tool usage, latency metrics) are available via API and console debug views.
Open source video

Deep dives

4

Eval-gated autonomous memory updates (dreaming guardrails)

Research question

Can proposed memory-store diffs from dreaming be scored against held-out sessions and gated so that only updates that improve downstream task performance are committed?

Why

Dreaming automatically rewrites agent memory without an acceptance test; without a gate, silent regressions can accumulate and there is no described rollback path.

It identifies gaps in skills or memory and automatically updates memory stores with improved learnings.
Open source video
Dreaming spawns sub-agents to analyze past session transcripts using memory stores.
Open source video
Source video

Long-horizon cost and state growth of scheduled agents

Research question

How do token cost, memory-store size, and task success rate change over hundreds of unattended scheduled runs?

Why

Deployments enable recurring background work, but running agents for months raises unresolved questions about cost trajectory, state accumulation, and failure handling.

Questions about exporting telemetry to OTel, running agents for months, and managing multi-tenant customer workspaces.
Open source video
Deployments allow agent execution on a schedule (e.g., monthly, daily).
Open source video
Source video

Mapping agent telemetry API to OpenTelemetry

Research question

What is the fidelity, latency, and schema of an OTel export bridge built on the platform's telemetry API, and does it cover sub-agent and dreaming jobs?

Why

Programmatic telemetry is the substrate for automated evals and production monitoring, but integration with existing observability stacks is an open question.

All telemetry events (model requests, tool usage, latency metrics) are available via API and console debug views.
Open source video
Questions about exporting telemetry to OTel, running agents for months, and managing multi-tenant customer workspaces.
Open source video
Source video

Cross-workspace RBAC for multi-tenant agent platforms

Research question

What least-privilege role model is required when workspaces are the tenancy primitive, and can cross-workspace agent access be constrained without breaking legitimate workflows?

Why

Workspaces provide isolation but fine-grained permissioning across them is raised as an open question, leaving access control and blast radius design incomplete.

Multi-tenancy is currently handled via workspaces as primitives.
Open source video
Questions about exporting telemetry to OTel, running agents for months, and managing multi-tenant customer workspaces.
Open source video
Source video

Article ideas

4

The Self-Improving Agent Needs an Eval Gate, Not Blind Trust

Autonomous memory rewriting via dreaming is powerful but dangerous without an eval-gated commit step; the industry should treat memory diffs as deployable artifacts subject to scoring and rollback.

Angle

Reliability engineering for agent memory

Source video

Cron Is the New Agent Interface

Scheduled deployments turn agents from interactive responders into unattended infrastructure, shifting the hard problems to idempotency, missed-run detection, and cost bounding.

Angle

Operational consequences of background agents

Source video

API-First Agent Platforms Ship the Console Last

When every primitive is exposed via API and SDK with the console as just one client, feature parity and stability at the API layer become the gating requirement for any capability.

Angle

Platform architecture for agent products

Source video

Workspaces Are Not RBAC: The Unfinished Tenancy Model for Agents

Using workspaces as the multi-tenancy primitive solves data separation but defers least-privilege; agent platforms need a first-class cross-workspace role model before enterprise adoption.

Angle

Security and access control for multi-tenant agents

Source video

Project ideas

4

Dream Diff Gate

beyond-evals

Eval-gated merging of dreaming-generated memory diffs reduces regression rate on held-out tasks compared to committing dreaming updates unconditionally.

Proof of concept

Build a pipeline that runs a dreaming pass over past transcripts, extracts a structured memory diff, scores it against held-out sessions, and only commits if the score exceeds a baseline.

Measurement

Regression rate on held-out tasks, number of reverts, memory diff size vs. performance delta.

Source video

Agent Longevity Bench

movement-lab

Scheduled agents without memory pruning show superlinear cost growth and declining task success after a threshold number of unattended runs.

Proof of concept

Run a scheduled financial-analysis agent for 500–1000 runs, tracking token cost, memory-store size, and success rate per run.

Measurement

Token cost per run, memory-store growth, task success rate over run index.

Source video

Agent OTel Bridge

new

A bridge mapping the platform's telemetry events to OTel spans can achieve >95% event completeness with <1s export latency and preserve trace context across sub-agent and dreaming jobs.

Proof of concept

Implement an adapter that ingests model-request, tool-usage, and latency events and emits OTel spans, then compare span count and timing to source events.

Measurement

Event completeness ratio, export latency, trace-correlation accuracy across parent/child agent jobs.

Source video

Cross-Workspace RBAC Testbed

gatehouse

Workspace-only isolation permits over-privileged cross-workspace agent access in multi-tenant scenarios unless an explicit role model is enforced.

Proof of concept

Model workspace-level roles and cross-workspace agent invocations, then run a privilege-escalation test suite against a multi-tenant agent deployment.

Measurement

Number of over-privileged access paths, time to enumerate cross-workspace permissions, false-positive rate of least-privilege enforcement.

Source video

Architectural implications

4

Dreaming rewrites memory stores based on analysis of past transcripts, turning persistent agent context into a machine-authored, continuously mutated artifact.

Before

Memory and instructions are human-authored and edited deliberately.

After

Memory stores are updated by background self-improvement jobs with no human in the loop per update.

Consequence

Teams need versioning, diffing, and rollback for agent-authored memory, plus evals to detect drift introduced by the dreaming loop.

Source video

Deployments decouple agent execution from user-triggered sessions by binding a schedule to an agent definition and initial message.

Before

Agents run when a user or upstream event explicitly starts a session.

After

Agents run on a recurring schedule with no human prompt at execution time.

Consequence

Reliability engineering shifts to unattended-run concerns: failed-run detection, alerting, retry/idempotency, and long-horizon cost accounting.

Source video

The platform is API-first with the console as one client among many.

Before

Capabilities are primarily driven through a product UI.

After

All primitives (deployments, dreaming, memory) are scriptable via SDK with custom UIs built on top.

Consequence

Feature parity and stability at the API layer become the gating requirement for any capability, and integration becomes the default consumption pattern.

Source video

Workspaces serve as the multi-tenancy primitive for separating customer data and agent access.

Before

Tenant isolation is implemented inside the application layer with tenant IDs and app-enforced access rules.

After

Isolation is delegated to a platform-level organizational container.

Consequence

Access control and data-boundary responsibility move toward the platform, but cross-workspace RBAC granularity remains to be designed.

Source video

Tradeoffs and failure modes

4

Autonomous memory rewriting via dreaming

Benefit

Reduces stale instructions and accumulates institutional knowledge across sessions without human intervention.

Cost or risk

Agent-authored memory updates can silently degrade behavior or drift, and the summary offers no described mechanism for validating, approving, or reverting those updates.

It identifies gaps in skills or memory and automatically updates memory stores with improved learnings.
Open source video
Source video

Scheduled unattended agent execution

Benefit

Complex multi-step workflows execute on a fixed schedule without human prompting.

Cost or risk

Long-running unattended agents raise unresolved questions about cost, state accumulation, and failure handling over months of runs.

Questions about exporting telemetry to OTel, running agents for months, and managing multi-tenant customer workspaces.
Open source video
Source video

Workspaces as the multi-tenancy boundary

Benefit

Provides a clean partitioning method for separating customer data and agent access in multi-tenant applications.

Cost or risk

Fine-grained permissioning across workspaces is not settled; the summary lists RBAC design as an open investigation rather than a solved capability.

What are the best practices for implementing fine-grained RBAC across workspaces?
Open source video
Source video

Telemetry exposed via API

Benefit

Enables programmatic monitoring, evaluation, and debugging of agent behavior through model-request, tool-usage, and latency events.

Cost or risk

Integration with existing observability stacks such as OTel is left as an unresolved question, so teams may need custom plumbing.

How to integrate custom observability stacks with platform telemetry?
Open source video
Source video

Open questions

4

How can platform telemetry be exported into an existing observability stack such as OTel?

Why unresolved

The summary records it as a Q&A topic raised by the audience without recording a concrete answer or supported export path.

Research direction

Prototype a telemetry bridge that maps agent events (model requests, tool calls, latency) onto OTel spans and measure completeness and latency of the export.

Source video

What guardrails validate that dreaming-applied memory updates actually improve rather than degrade agent behavior?

Why unresolved

Dreaming is described as automatically updating memory stores, but no acceptance test, eval gate, or rollback path is described.

Research direction

Build an eval-gated dreaming pipeline where proposed memory diffs are scored against held-out sessions before being committed, and measure regression rate.

Source video

What are best practices for fine-grained RBAC across workspaces?

Why unresolved

Workspaces are stated to be the current multi-tenancy primitive, but permission granularity beyond that is only raised as a question to investigate.

Research direction

Model workspace-level roles and cross-workspace agent access, then test least-privilege configurations against multi-tenant agent workloads.

Source video

How do agents behave and what do they cost when run continuously for months?

Why unresolved

The summary notes running agents for months was asked about, but no data on state growth, cost trajectory, or degradation is given.

Research direction

Run a long-horizon scheduled agent benchmark and track token cost, memory-store size, and task success rate as a function of elapsed runs.

Source video

Key claims

7
factualVerification needed

Deployments allow agent execution on a schedule (for example monthly or daily).

Evidence

Deployments allow agent execution on a schedule (e.g., monthly, daily).

Question

What scheduling granularity, timezone handling, and missed-run behavior does the deployment scheduler actually support?

Source video
causalVerification needed

Dreaming spawns sub-agents that analyze past session transcripts using memory stores and automatically update memory stores with improved learnings.

Evidence

Dreaming spawns sub-agents to analyze past session transcripts using memory stores.

Question

Does the automatically updated memory store measurably improve downstream task performance, and can updates be reverted?

Source video
factualVerification needed

All telemetry events — model requests, tool usage, and latency metrics — are available via API and console debug views.

Evidence

All telemetry events (model requests, tool usage, latency metrics) are available via API and console debug views.

Question

What is the retention window, latency, and schema stability of the telemetry API, and does it cover sub-agent and dreaming jobs?

Source video
factualVerification needed

Multi-tenancy is currently handled via workspaces as primitives.

Evidence

Multi-tenancy is currently handled via workspaces as primitives.

Question

What isolation guarantees do workspaces provide for memory stores, credentials, and cross-workspace agent access?

Source video
factualVerification needed

Everything is API-based, allowing custom UIs and workflows to be built on top of the SDKs.

Evidence

Everything is API-based, allowing custom UIs and workflows built on top of SDKs.

Question

Is there full API parity with the console, including dreaming setup and telemetry access?

Source video
opinionVerification not requested

Evals are recommended to steer and verify agent performance.

Evidence

Evals are recommended to steer and verify agent performance.

Source video
factualVerification needed

Dreaming jobs can be configured with a chosen memory store, chosen model, and custom instructions, defaulting to a provided prompt.

Evidence

What dreaming is, it lets you select the memory store, you can select the model, you can give it custom instructions if you want to, but we'll use the default prompt.

Question

Does running dreaming with a different model than the production agent produce meaningfully different memory updates?

Source video

Connections

5

dreamingevals

Both are feedback loops over agent behavior: dreaming mutates memory from past sessions, while evals are the recommended mechanism to steer and verify performance; together they form a plus/minus control pair.

Source video