Inside Anthropic’s 37-minute Agent Workshop: Seven Functions and an Incident Investigator

Start with the incident

When an incident wakes you up, much of the work is assembling evidence. Which service slowed down first? What changed? Why would an ordinary refactor exhaust a database connection pool? Are the other errors relevant?

Anthropic’s Ship your first Managed Agent turns that investigation into a practical exercise. Its strength is that you can follow how an agent acquires evidence, executes analysis, exposes progress, and retains its conversation after a refresh. This article explains the interfaces involved, how to reproduce the exercise, and what you still need to establish before applying it to production.

What the workshop actually covers

The official video, published by the Claude channel on May 26, 2026, runs 37 minutes and 9 seconds. Isabella He introduces herself as a member of Anthropic’s Applied AI team. The approximate duration circulating on social media is reasonable; descriptions calling it newly released or a guide to automating an entire business overstate its timing and scope.

The exercise builds an investigator for a fictional commerce incident. It reads synthetic logs, requests fixture metrics and deployments, examines a code diff, and recommends action. At around 25:00, the speaker discusses editing code and opening pull requests as possible extensions. The demonstration stops at recommendations.

The product announcement has a separate date: April 8, 2026. That page now includes links to subsequent capabilities, so its present contents should not all be attributed to the original launch or the workshop.

For this article, we reviewed the full automatic captions, official documentation, and repository code, and ran the synthetic log generator locally. We did not call the paid Managed Agents API. Source-confirmed behavior, the speaker’s demonstrated results, and our engineering recommendations are distinguished below.

Why the example teaches effectively

The exercise combines a clear question with an inspectable answer. Deployment history supplies timing, metrics show impact, the diff explains a mechanism, and logs provide execution evidence. No single source establishes the whole diagnosis.

The dashboard and tools also share the same fixtures. Readers can inspect Metrics, Logs, and Deploys rather than trusting a fluent answer. Implementation proceeds through visible stages: an agent definition, an environment, an uploaded file, a session, and working tool callbacks.

A reference solution makes each stage easy to compare. However, the small amount of code the learner writes relies on substantial scaffolding: prompts, schemas, fixtures, UI, and history reconstruction. The README’s approximately 38 lines describe the missing core logic, not the total size of a finished product. Workshop source

A complete viewing guide

These approximate markers refer to the full YouTube version. Automatic captions can misrecognize technical terms; code is the reference for API spelling.

Four objects behind the application

An Agent is reusable working configuration: model, instructions, tools, and skills. An Environment describes execution. A Session binds configuration, environment, and task inputs into a particular run. Events carry messages, tool requests, results, and status. Official overview

There are two execution paths. The uploaded log is analyzed in the cloud sandbox. Metrics, deployments, and diffs are read by local Python handlers and returned through events. This does not give the cloud model arbitrary control of the laptop: the application implements the tool requests it accepts.

The speaker describes reasoning and execution as the agent’s brain and hands. Separating them lets developers reason independently about model scheduling, container lifecycle, credentials, and tool execution. She also reports internal latency improvements and faster development; these are reported experiences, not performance guarantees for a reader’s application.

Managed infrastructure also absorbs some harness maintenance. The presentation uses changing model context behavior to illustrate why a mitigation useful for one model can become unnecessary for another. The business still owns the quality of its inputs, tool contracts, and acceptance criteria.

User asks an incident question in Streamlit
                 ↓ user message event
Anthropic-managed agent loop
    ├─ runs commands against app.log in a sandbox
    └─ emits a custom tool request
                 ↓ event stream
Local Python dispatcher → fixture metrics, deployments, diff
                 ↓ tool result event
Agent continues → returns analysis → session becomes idle

What the seven functions connect

The video description says six functions; the current repository lists seven, including session deletion. This walkthrough follows the pinned reference implementation.

1. setup_agent: reusable configuration and team knowledge

The current implementation uploads the incident triage Skill and creates an agent with its model, system prompt, tools, and skill version. A random suffix avoids duplicate Skill display titles within the organization.

There is visible version drift: the speaker names Opus 4.7 at approximately 12:44, while the current file uses claude-opus-4-8. Current code also attaches the runbook directly; the video discusses runbooks as useful additional context. A moving main branch should not be treated as an exact recording of the live exercise.

2. setup_environment: where execution happens

The example creates a cloud environment with networking.type = unrestricted. This is convenient for teaching; an actual integration needs a deliberate network and tool access policy.

The presentation also mentions self-hosted execution and MCP tunnels. Neither infrastructure path is deployed by this exercise.

3. upload_log: make evidence a searchable file

The Files API receives data/app.log. The system prompt tells the agent to analyze the large file with grep or Python instead of reading it whole.

The useful pattern is selective retrieval: narrow by service, time, and request identifier before bringing evidence into model context. Note the data boundary: this file has been uploaded. Locally executed metric tools do not make the entire system local-only.

4. start_session: bind the task inputs

The session references the agent, environment, and uploaded file. The resource uses mount_path = app.log; the prompt identifies /mnt/session/uploads/app.log as its readable location.

Upload success and successful access from the session are separate checks. A mismatch between the mount and the prompt can break investigation despite a successful upload.

5. stream_reply: complete the event round trip

The function opens a stream before sending user.message. For agent.custom_tool_use, it invokes a local handler and sends user.custom_tool_result, using the original request event ID as custom_tool_use_id.

That correlation is essential. Logging a result locally does not supply it to the agent.

The generator yields events continuously. Its UI caller in provided.py stops consuming on session.status_idle with an end_turn stop reason. If you reuse the generator elsewhere, implement an appropriate completion path yourself.

6. handle_tool: connect requests to business functions

The three handlers return service metrics, recent deployments, and a commit diff. They read JSON and text fixtures; they do not connect to live Datadog, PagerDuty, or GitHub APIs.

Replacing fixtures with clients requires validation, authorization, bounded queries, timeouts, rate limits, and meaningful failures. There are also fixture-specific shortcuts: the metrics fallback relies on truthiness, which could misclassify a valid scalar zero if generalized, and the diff handler checks whether a seven-character commit prefix occurs in text rather than performing an exact repository lookup.

7. delete_session: manage resource lifetime

This function deletes a session. The current overview states that uploaded files can be deleted separately. Removing a session from the picker does not establish that files, Skills, Agent definitions, and Environments were all removed.

Likewise, st.cache_resource reduces duplicate creation within the application process. It is not a durable resource registry. Production code needs persisted identifiers, version policy, and cleanup rather than assuming a process restart will discover the same resources.

Reconstructing the incident

The fictional checkout deployment places commit a3f9c21 at 14:31:18 UTC on April 22, 2026. This fixture date is distinct from the product announcement and video upload. Deployment fixture

The diff replaces a batched order-item query and in-memory grouping with an item query inside each order iteration. Database requests grow with the number of orders. N+1 describes that repeated-query pattern; exact counts also depend on ORM evaluation and surrounding operations.

Reading the fixture shows checkout p99 starting at 62.448 ms and peaking at 3638.004 ms, with a peak error rate of 21.9%. These are synthetic observations, not business improvements produced by the agent. The README’s 65 ms, 3600 ms, and 20% are rounded descriptions.

Our local generator run produced 69,740 lines and 14,875,565 bytes, supporting “about 70,000 log lines.” It includes earlier auth errors that recover, giving the investigator a distractor rather than making every error causal. Generator

The fixtures are simplified rather than measurements from a single monitoring pipeline. For example, the pool metric reaches 100% at 14:37, while the generator starts its post-exhaustion error branch at 14:40. They support the intended mechanism but should not be represented as a perfectly synchronized production trace.

What the runbook contributes

The current Skill starts with deployments and metrics, then a relevant diff, followed by log confirmation. If no deployment aligns, it directs attention to connection pools and upstream dependencies. It also lists common failure patterns and requests a concise root-cause statement.

Tools determine what evidence is accessible; the runbook helps prioritize investigation and define the report. This can reduce aimless searching, provided the agent can take another branch when evidence does not fit.

Markdown instructions are not an authorization mechanism. A communication instruction cannot create a messaging integration, and a runbook cannot enforce the permissions for a real rollback. Those controls belong in the application and tool layer.

Waiting and recovery are part of the lesson

At about 22:38, the speaker starts another session and retries the investigation. A result arrives around 24:17. While revisiting history later, she notes that the previous session has also returned. The recording does not establish the cause of the wait.

The practical lesson is to preserve identifiers, inspect events, and distinguish runtime states. Repeatedly opening new sessions can duplicate work and spending.

Another nuance concerns closing the laptop. The platform can persist and run the server-side session, but this sample’s custom handlers execute in local Python. If the process stops and the agent needs another tool result, the end-to-end workflow is missing its executor. Session durability and tool-service availability are separate properties.

What the UI and history code actually provide

provided.py renders different status boxes for sandbox and local tools and reconstructs history with session and event listing. This exposes work instead of only displaying a final answer.

The sample fetches 15 recent sessions and at most 500 historical events without complete pagination. A newly created Agent definition also changes the session filter. Missing records in this UI therefore do not establish that the cloud lost them.

Event streaming is also distinct from token streaming. Current event documentation describes default agent.message delivery as buffered; incremental previews are opt-in. A production UI should correlate previews by event ID and reconcile them with the persisted message to avoid duplication. The workshop’s event display does not promise immediate character-by-character output.

The final capability tour is an extension map

Persisting the current conversation is not the same as learning across sessions, and generating an answer is not evidence that an Outcomes rubric evaluated it. Access conditions can also change; consult current documentation and account availability when implementing an extension.

Reproduce a small, verifiable loop

You need Python 3.10+, an Anthropic API key, and platform access and billing. The public lesson is free to watch; cloud execution is billable. These commands use the current organization address rather than the older address still shown in the README.

git clone https://github.com/anthropics/cwc-workshops.git
cd cwc-workshops
# Pin the source reviewed here; this is not a production recommendation.
git checkout 068b84bb03d2ae87c51edb2837dda25c84c1d686
cd ship-your-first-managed-agent
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt
cp .env.example .env
# Edit .env locally to set ANTHROPIC_API_KEY.
python data/generate_log.py
streamlit run app.py

Validate and troubleshoot the exercise

On Windows, activation depends on the terminal; PowerShell can use .venv\Scripts\Activate.ps1. Keep the working directory at the exercise root because some paths are relative.

The dashboard should initially work while the agent panel asks you to implement setup_agent(). Fill agent.py using agent_complete.py as a reference. Once resource identifiers appear, create a session with the plus button and ask about checkout latency around 14:32 UTC.

Validate in this order:

The repository’s e2e.py calls the cloud and incurs costs. Its success condition mainly checks for N+1 and the commit identifier in the answer: useful smoke coverage, not proof of a correct evidence chain. It does not implement comprehensive cleanup, and its 600-second deadline is checked after an event arrives rather than acting as an independent hard timeout. Test source

The README explicitly labels this an unmaintained workshop sample that does not accept contributions. Treat it as learning material rather than a maintained production template. Requirements use minimum versions rather than a fully pinned dependency set. Pinning source alone does not freeze the runtime. Record SDK versions, session identifiers, and event types when debugging, and compare against the current Quickstart.

• Log generation and resource creation succeed.
• The session can access the log, and custom requests receive correlated results.
• The answer identifies a3f9c21 and N+1 with deployment, metric, diff, and log support.
• It explains why the earlier auth errors do not adequately explain the checkout incident.
• Refresh recovers the same session and permits a follow-up question.
• Cleanup covers the relevant resource types, and usage is reviewed.

Six priorities before production

These are recommendations from reviewing the code, beyond the completed demonstration.

Operate the tool handler as a reliable service. Define reconnection, duplicate-event handling, execution timeouts, and failure responses. Write operations also need business-level idempotency.

Specify bounded inputs and meaningful outputs. Validate services, time ranges, and commit identifiers. Limit result sizes. Distinguish missing data from failed queries, and allow an inconclusive diagnosis.

Authorize investigation and changes separately. Begin with read-only evidence gathering. Add rollback, configuration changes, or PR creation only with their own controls. A recommendation is neither execution nor proof of recovery.

Evaluate multiple incident types. Include failures without deployments, nearby competing deployments, missing logs, timeouts, and misleading evidence. Measure false conclusions, omissions, cost, and duration rather than extrapolating reliability from one known answer.

Manage data and versions deliberately. Persist resource mappings, pin reproducible configurations and dependencies, and define upload and retention scope. The sample’s latest Skill reference introduces another moving part.

Bound cost and runtime. At verification time, official pricing lists model token charges plus $0.08 per active session-hour. Eight cents per hour is not the whole bill; consult model and applicable tool charges. Pricing

What to take into your own agent product

The workshop offers an inspectable unit of work: a specific incident question, evidence-producing tools, an execution environment, a recoverable process, and a conclusion a person can check.

That decomposition is useful regardless of where you ultimately host an agent. Make one well-bounded task reliable, then decide how to expand data access, permitted actions, and parallel work. Execution location, service availability, cost, and control determine whether a managed platform fits.

The lasting benefit is being able to trace how the answer was produced—and knowing what evidence to demand next.