Claude Dynamic Workflows events vs Sume's single terminal run event

Anthropic's release notes for October 9, 2026 describe Dynamic Workflows for Claude Managed Agents, a beta behind the managed-agents-2026-04-01 header. An agent writes a workflow for work with many pieces, runs many agents in phases, combines the results, and you follow progress through workflow_run.* events on the session event stream.

Sume's model is the opposite on the wire. There is no SSE or WebSocket transport on the Developer API. A run emits one signed terminal event, and the fan-out is something you queue yourself or ask Sume to queue for you.

Progress on Sume

Three pull or push options exist, and none is a live stream. For Format runs, GET /v1/format-runs/{run_id}/events returns the phase timeline, oldest first. For generation jobs, GET /v1/jobs/{id}/events returns a public timeline snapshot. For completion, a run webhook (format.run.terminal, action.run.terminal or agent.run.terminal) fires exactly once per turn, whatever the number of artifacts.

Action runs differ: there is no events endpoint for them, and events_url is always null on the receipt.

Fan-out without a workflow engine

For many pieces of work, POST /v1/formats/{handle}/{slug}/bulk-runs queues up to 100 Format runs with a concurrency window from 1 to 16, and returns a 202 queue receipt. Poll GET /v1/format-run-queues/{queue_id} for counts and read each child at GET /v1/format-runs/{run_id}. There is no public cancel for the queue; cancel children one at a time.

Each item is one ordinary run: one sandbox, one agent turn. The queue is not a different engine, so a workflow that depends on agents calling each other is not what this gives you.

• Use communication.webhook_url to avoid a poll loop per child.
• Dedupe on request_id, which equals run_id and is stable across retries.
• Branch on outcome (ok, degraded, error), not only status.

Choosing

If you want an agent that plans its own phases and streams events, Anthropic's beta is built for that. If you want durable, billable runs with receipts and a spend cap that you start from your backend, Sume's run model fits. See one terminal event vs a stream for the delivery side.

Handling the single event

Because the terminal event fires once per turn, your receiver is simpler than a stream consumer. Verify the signature on the raw body, store the event under request_id, return 2xx, and process afterwards. Branch on outcome. A degraded run billed you and produced real artifacts but could not fill your output_schema, so route it to review, not to retry.

Canceled and skipped runs send no webhook. After you call cancel, poll status_url until the status is canceled. If a delivery fails ten times, Sume marks it exhausted; fetch the receipt from result_url or use Redeliver on the Format run, which does not consume one of the automatic attempts.