CHAPTERS
- 0:02 – 0:32
Managed Agents overview: APIs for deploying agents at scale
The video opens by defining Claude Managed Agents as a suite of APIs for building, configuring, and running agents reliably at scale. It highlights core primitives like agent definitions, sandboxed environments, and isolated container execution with tool access.
- •Managed Agents as a scalable agent deployment API suite
- •Define agents with tools, personas, and capabilities
- •Configure sandbox environments (packages + network controls)
- •Run sessions from your app while Claude executes in isolated containers
- •Capabilities include filesystem access, bash execution, and web search
- 0:32 – 1:03
Kanban-triggered sessions: turning workflow moves into agent runs
A Kanban board example shows how moving a ticket to “In Progress” automatically triggers an agent session. The session is created by the backend and bound to a pre-configured environment and repo access.
- •UI workflow action (drag ticket) triggers an automated session
- •Backend creates a session tied to a specific environment
- •Environment is tailored to the task requirements
- •Repo is mounted into the container for direct code access
- •Agent is launched with a clear task ticket (e.g., performance optimization)
- 1:03 – 1:18
Website performance optimization agent: tool-driven code changes with a rubric
The agent runs Lighthouse/Puppeteer audits and iteratively improves a website to meet explicit performance criteria. Tool calls stream back in real time, making the agent’s progress observable from the board.
- •Lighthouse and Puppeteer used for automated audits
- •Explicit rubric targets (e.g., score > 90, no render-blocking resources)
- •Agent applies changes like image compression, CSS inlining, script deferral
- •Event streaming shows each tool call and step in real time
- •Agent operates directly on the mounted codebase
- 1:18 – 1:33
Automated grading loop: separate evaluator checks results and drives retries
A distinct grading context evaluates the agent’s output against the rubric and returns feedback. Claude uses that feedback to fix gaps and resubmit until the target outcome is achieved.
- •Independent grader runs in its own context window
- •Evaluates output against predefined criteria
- •Claude reads feedback and iterates to address misses
- •Closed-loop workflow until requirements are met
- •Example outcome improvement to a 96 Lighthouse score
- 1:33 – 1:48
Parallel work: multiple sessions and containers running concurrently
The demo emphasizes that separate tickets can be processed simultaneously, each in its own container. This enables true parallelism across tasks without interference between runs.
- •Drag a second ticket while the first is still running
- •Two sessions correspond to two isolated containers
- •Tasks run concurrently without shared state collisions
- •Supports scaling agent workloads across a queue of work
- •Designed for multi-task operational throughput
- 1:48 – 2:03
SaaS pricing tracker agent: web research + Python analysis + spreadsheet output
Another agent monitors SaaS vendor pricing and plan changes, then produces a report ahead of standup. It combines web search with in-sandbox Python cost analysis and spreadsheet generation.
- •Agent searches the web for current pricing and tier changes
- •Flags new features that could impact contracts
- •Runs cost analysis in Python inside the sandbox
- •Uses an Excel/spreadsheet skill to produce artifacts
- •Generates an executive summary for stakeholders
- 2:03 – 2:18
Enterprise integrations via MCP: Slack delivery and Asana review workflow
The report is distributed and operationalized by posting to Slack and creating an Asana review task. These actions are performed through MCP servers to connect external tools/services.
- •Posts a link to Slack when the report is ready
- •Creates a review task in Asana automatically
- •Integrations are implemented through MCP servers
- •End-to-end workflow from research to distribution
- •Makes agent output actionable in existing team systems
- 2:18 – 2:33
Memory-backed reporting: compare against last week and store deltas
The agent reads from a memory store to avoid repeating static information and to highlight what changed since the prior run. It then writes updated findings back to memory for future sessions.
- •Checks last week’s findings before starting work
- •Stores new results after completing the run
- •Reports deltas (e.g., ‘15% lower since last week’) instead of re-listing data
- •Creates continuity across weekly workflows
- •Enables compounding knowledge over repeated runs
- 2:33 – 2:44
Incident response flow: monitoring alert becomes a tool result in a new session
A monitoring alert triggers a custom backend tool that forwards the payload into a new agent session. This establishes a structured path from operational events into automated investigation.
- •Alert fires from a monitoring stack
- •Custom backend tool receives and packages alert payload
- •Payload is injected as a tool result into a new session
- •Session begins with concrete incident context
- •Bridges observability signals to agent execution
- 2:44 – 2:54
Multi-agent coordination: coordinator delegates to specialists with shared filesystem
A coordinator agent delegates investigation to multiple specialists, each running in its own context window. They collaborate over a shared file system and roll findings up into a unified incident summary.
- •Coordinator agent orchestrates the response
- •Three specialist agents run in separate context windows
- •Specialists share the same filesystem for collaboration
- •Findings are returned to the coordinator
- •Coordinator synthesizes a single incident summary
- 2:54 – 3:04
Human-in-the-loop permissions: approve drafts before Slack posting
Before external actions occur, a permissions policy intercepts and requires approval. The user reviews the draft incident update and then authorizes it to be posted to Slack.
- •Permissions policy gates outbound actions
- •Draft update is shown for review
- •User approval required prior to Slack posting
- •Reduces risk of incorrect or sensitive disclosures
- •Balances automation with control and compliance
- 3:04 – 3:34
Memory-driven incident pattern matching: reuse past context to speed diagnosis
The coordinator consults the memory store to compare the current incident with prior ones and identify recurring patterns. This allows future alerts of a similar nature to start from known root-cause context rather than re-diagnosing from scratch.
- •Coordinator checks memory store for past incidents
- •Flags similarity to a DNS resolution issue from two weeks prior
- •Example root cause reference: misconfigured TTL
- •Future incidents bootstrap with prior context
- •Improves speed and consistency of incident response
- 3:34 – 3:52
Wrap-up: core building blocks and outcome-driven agent execution
The conclusion enumerates the main components—agents, sessions, environments, tools, MCP, memory, outcomes, and multi-agent coordination. The key promise is that developers define ‘done,’ and Claude iterates until it meets that outcome.
- •Managed Agents provides a fully managed, stateful agent experience
- •Core primitives: agents, sessions, environments, tools
- •Platform capabilities: MCP integrations, memory, outcomes
- •Supports multi-agent coordination patterns
- •Outcome-focused model: define done, Claude works until it gets there
