Anthropic shipped two Claude Managed Agents features in a week. On October 9 it added dynamic workflows in beta, letting an agent write a program that runs many agents in phases and combines their results on Anthropic’s servers. On October 14 it launched OpenTelemetry export in beta, so Messages API requests and Managed Agents sessions can be traced in an existing observability backend. Release notes Both move work that teams have usually built themselves, fan-out orchestration and agent tracing, onto the platform. Whether to hand it over depends on limits and defaults that are easy to miss.
Everything here is beta under the managed-agents-2026-04-01 header, and S5 Labs has not run either feature. The numbers below come from Anthropic’s documentation.
What a workflow run is
Anthropic’s docs define a workflow as “a program that an agent writes to run many agents and combine what they return.” The server runs it in the background, and the agents work in session threads the server creates. Workflow runs The orchestration page gives “reviewing hundreds of documents or cross-checking many sources” as the kind of work it targets. Multiagent orchestration
There is no endpoint to start a run. You describe the work in a user.message, and the agent decides whether and when to start one; the docs say to steer that choice in the system prompt. Permission policies apply to the tools the run’s agents call, not to starting the run. Multiagent orchestration
The setting is multiagent.type = "multiagent_20261001". The release note says to enable workflows with {"type": "multiagent_20261001", "workflows": {"type": "enabled"}}, but the orchestration page says workflows and subagents are both on by default with this type. Release notes Multiagent orchestration Anyone switching an agent to the new type for subagents alone gets workflows too unless they set workflows to {"type": "disabled"}. The older coordinator type cannot start runs or define subagents. Multiagent orchestration
Agents in a run are either defined inline by the workflow or picked from up to 20 predefined_agents. Inline agents use the session agent’s model, so mixing models means creating separate agents and listing them. Neither page lists which models a run supports. Multiagent orchestration
Limits and billing
| Limit | Value |
|---|---|
| Threads working at once in one run | 64 (“The API doesn’t guarantee this number.”) |
| Agents started over a run’s life | 1,000, then thread_limit_error |
| Run lifetime | 24 hours by default, or what the agent sets, then timeout_error |
| Open runs per session | 10 by default, idle runs included |
The docs add that the server has “other limits on workflows” that are not listed. Workflow runs Progress arrives as workflow_run.* events on the session stream, from workflow_run.created through phase events to workflow_run.status_ended with the result. Updating the session’s agent while a run is open returns a 400 workflow_run_open. Workflow runs
“A run has no price of its own.” Its agents’ tokens bill at each model’s rates and count toward the session budget. When the budget is hit, every open run pauses, but each working thread finishes its in-flight request, so a run can overshoot by one request per working thread. With 64 threads busy, that is up to 64 requests past the cap. A paused run’s lifetime keeps ticking. Workflow runs
Managed Agents also bills session runtime at $0.08 per session-hour, counted only while the session is running. Pricing Run requests count against the organization’s Messages API rate limits for each thread’s model, so those limits may cap a run before the 64-thread ceiling does. Workflow runs
Build or buy the orchestrator
With your own harness, you write the retry logic, mix any models, decide when fan-out starts and set the limits. A Managed Agents run takes the scheduler, thread bookkeeping and result collection off your hands, but the agent decides when to fan out, inline agents are tied to one model, and some limits are undisclosed. For batch review jobs that already run on Managed Agents, the server-run version is worth a trial. For pipelines where a missed retry or a surprise fan-out is expensive, the case for keeping orchestration in your own code still holds.
This is a different product from the dynamic workflows Anthropic previewed in Claude Code, which we covered in May; limits from one should not be assumed for the other. For a hosted-agent comparison, see OpenAI’s managed Codex harness.
OpenTelemetry export: two layers, metadata by default
Tracing comes in two layers. SDK tracing runs in your code and emits spans in Python, TypeScript, C#, Go, Java, PHP and Ruby; it is in beta on the Claude API, Claude Platform on AWS, Bedrock, Google Cloud and Microsoft Foundry. API tracing is configured as a destination in the Claude Console by an admin and covers model runs, Managed Agents turns and server tools, on the Claude API and Claude Platform on AWS only. Used together they produce one trace, except on Claude Platform on AWS, where the API spans land in their own traces. OpenTelemetry SDK tracing
The default content mode is metadata only, so prompts and responses stay out of spans until you opt in per destination or per SDK client (ANTHROPIC_OPEN_TELEMETRY_TRACES_CONTENT_MODE=content in the SDK). Metadata still includes agent and tool names and descriptions and MCP server names. Full content is capped at 0.75 MB per span by default; Anthropic says a full 1M-token context needs about 4 MB. Organizations under a HIPAA, FERPA or K-12 restriction get metadata-only destinations regardless of setting, though SDK spans are unaffected. Managed Agents is not eligible for zero data retention, and tracing does not change that. OpenTelemetry
Destinations take an OTLP/HTTP protobuf endpoint on HTTPS port 443, with up to 10 per organization. Delivery is at least once and best effort. Anthropic says exported spans “aren’t guaranteed to be a complete record of your API usage” and points to the Usage API for tracking usage. OpenTelemetry A destination is disabled after 24 hours of failures, a redirect or a non-public IP. API tracing Anthropic also warns that span names, attributes and SDK options can change during the beta “in ways that break your code, your queries, or your dashboards”, and says to pin the SDK version. SDK tracing
The October 7 change that can break existing agents
A week earlier, Anthropic tightened Managed Agents networking. With limited networking, allowed_hosts now also applies to web_search and web_fetch: a blocked fetch returns url_not_allowed, and search drops results from those hosts. web_fetch now fetches only URLs already seen in the session, such as in the text of a user message, a search result or a fetched page. A URL that appears only in the system prompt, an attached document, or the output of bash, read or an MCP tool returns url_not_in_prior_context. Anthropic’s stated reason is to reduce the risk of data exfiltration, and the fix is to send the URL in a user.message. Release notes
With limited networking, session creation also fails with a 400 when a web tool’s allowed_domains entry is not covered by allowed_hosts, and the two lists match differently: docs.example.com in the tool list is not within allowed_hosts of ["example.com"]. Web restrictions An agent that reads a URL list from its system prompt, or fetches links a script printed, will now fail on those calls.
What to test first
- Run a small workflow with a tight session budget and measure the overshoot against the thread count.
- Check whether the agent starts runs when you expect, and whether disabling
workflowsis needed for subagent-only agents. - Turn on metadata-only tracing first, review which agent and tool descriptions it exports, then decide on full content.
- Grep system prompts and tool outputs for URLs the agent is expected to fetch, and move them into user messages.
Still unknown: the unlisted server limits, which models a run supports, and how much the span schema will change during the beta. For background on fan-out designs, see our agent architecture patterns.