Claude Managed Agents July 22: Three Polling Gaps Closed in One Release

Anthropic pushed five changes to the Claude Managed Agents API on July 22. Three of them address the same underlying problem: operators were forced to poll or make redundant round-trips to know when things were ready. This post covers those three and explains what you need to change before they matter to you.

The other two — making the version field optional on agent updates and adding effort to agent model config — are real but narrow enough to be addendum material, not the story.

The three gaps July 22 closes

Before July 22, the Managed Agents event model had these observable polling traps:

1. Session cold-start required two sequential calls: POST /v1/sessions to create the session, then a separate POST /v1/sessions/{id}/events to send the first user message. Any caller that needed to start work immediately had to wait for the first response before making the second request.

2. Subagent (thread) output was opaque until complete: The session-level stream (GET /v1/sessions/{id}/stream) let you preview text from the top-level agent, but if the orchestrator delegated to a subagent, you could not stream that subagent's output as it generated. You got the final rolled-up result only.

3. Environment and memory store readiness required polling: When an environment was created, archived, or failed, and when a memory store was created, updated, or deleted, the only way to react was to poll GET /v1/environments/{id} or GET /v1/memory_stores/{id} on a timer.

All three are now closed.

initial_events: collapse two calls into one

POST /v1/sessions now accepts an initial_events field. Pass up to 50 events — any mix of user.message and user.define_outcome — and the agent loop starts in the same call. A non-empty list is enough; you do not need to call POST /v1/sessions/{id}/events afterward.

Before July 22:

# Step 1: create the session
session=$(curl -fsSL https://api.anthropic.com/v1/sessions \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  -d '{"agent":"$AGENT_ID","environment_id":"$ENV_ID"}')
SESSION_ID=$(jq -r '.id' <<< "$session")

# Step 2: send the first message — separate network call, separate latency
curl -fsSL "https://api.anthropic.com/v1/sessions/$SESSION_ID/events" \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  -d '{"events":[{"type":"user.message","content":[{"type":"text","text":"Run the audit"}]}]}'

After July 22:

session=$(curl -fsSL https://api.anthropic.com/v1/sessions \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  -d '{
    "agent": "$AGENT_ID",
    "environment_id": "$ENV_ID",
    "initial_events": [
      {
        "type": "user.message",
        "content": [{"type": "text", "text": "Run the audit"}]
      }
    ]
  }')
# Agent is already running. SESSION_ID is in the response.

The practical saving is one network round-trip on every cold start. If you're launching sessions in response to user actions — chat turns, webhook triggers, scheduled jobs — that round-trip adds latency on the critical path. At high volume it also adds one more request class to your gateway's concurrency accounting.

One constraint worth noting: the 50-event limit per create call is not a burst-fire mechanism. If your bootstrapping logic sends more than 50 seed messages, you still need a follow-up send. In practice, most session setups fit well under that.

Thread-level delta streaming: your subagents now push text

When a Claude Managed Agent orchestrates subagents, each subagent runs in a thread. The session-level stream endpoint (GET /v1/sessions/{id}/stream) accepted an event_deltas[] query parameter that previewed the top-level model's text generation. Threads did not.

As of July 22, GET /v1/sessions/{session_id}/threads/{thread_id}/stream accepts the same event_deltas[] parameter.

curl -N "https://api.anthropic.com/v1/sessions/$SESSION_ID/threads/$THREAD_ID/stream?event_deltas[]=text_delta" \
  -H "anthropic-beta: managed-agents-2026-04-01"

A thread stream connection previews only the thread it targets — it does not aggregate across threads. If you have an orchestrator with three subagents running in parallel, you need three separate SSE connections to stream all three simultaneously.

Why this matters for routing architecture: In multiagent pipelines, the orchestrator thread is often short — it delegates and waits. The latency budget is dominated by the subagent threads. Prior to this change, the only way to show incremental progress to a downstream user was to (a) stream the top-level session and get sparse orchestrator commentary, or (b) poll the thread's event log on an interval. Neither is good. Thread-level deltas let you proxy a specific thread's output to a frontend in real time, the same way you'd stream a direct API call.

The useful pairing: session.thread_created webhook → open a thread stream connection → stream text deltas to your client. That three-step pattern now works end-to-end without polling at any stage.

Seven new webhook event types: stop polling environments and memory stores

The Managed Agents webhook catalog now covers the full lifecycle of two resource types that operators were previously forced to poll.

Environment events (4 types):

Memory store events (3 types):

Webhook payloads follow the existing pattern: they deliver the event type and its ID, not the full resource object. When you receive a webhook, you fetch the current resource state with a GET call. This keeps each delivery small and avoids stale data on retries.

What was happening before: If your operator infrastructure creates environments dynamically (one per tenant, one per deployment, etc.), you had no push signal for readiness. Common workaround: poll GET /v1/environments/{id} every few seconds, check status, give up after N retries. Same problem for memory stores in workflows that create and then immediately attach them to sessions.

What you can do now: Register a webhook endpoint that catches environment.created and environment.failed, fetch the environment object on receipt, and route accordingly. A single webhook handler replaces a polling loop and its error-handling boilerplate.

One operational point: these events are subject to the same delivery-at-least-once semantics as other Managed Agents webhooks. Your handler must be idempotent by event ID. If you were already handling session lifecycle webhooks, you already have this.

Cross-provider context

OpenAI's Realtime Agents and Gemini Managed Agents both cover session lifecycle webhook events, but neither currently exposes environment or memory store lifecycle events to operators. The environment.failed event type in particular — a push notification when a cloud sandbox fails to provision — has no equivalent in either competing framework as of this writing. Polling for sandbox readiness is the norm elsewhere.

The thread-level stream is also differentiated: Gemini Managed Agents stream orchestrator output but do not expose subagent-level streams; OpenAI does not offer a thread-scoped SSE for subagent text. If your routing architecture needs to show subagent progress in a UI — a common requirement for coding agents and research agents with visible parallel workstreams — Claude's thread stream is currently the only way to get per-subagent text deltas without custom logging infrastructure.

version and effort additions (addendum)

Agent version now optional on update: PATCH /v1/agents/{id} previously required version for optimistic concurrency control. It's now optional. Omit it to apply updates unconditionally; include it if you want a 409 on version mismatch. If your code was passing the current version as a required field, no change needed. If you were working around the requirement by always fetching before patching, you can now simplify that logic.

effort on agent model config: You can now set effort inside the model object when creating or updating an agent. This joins the existing per-session config override mechanism — effort can be set at the agent definition level and overridden per session. Useful when you want a lightweight default and a heavier-effort override for specific task types routed to the same agent.

{
  "model": {
    "name": "claude-sonnet-5-20261015",
    "effort": "low"
  }
}

The effort levels (low, medium, high) behave as documented in Anthropic's effort levels reference. If you're already using per-session effort overrides (covered in the July 2 release), this gives you a cleaner default-setting path at agent definition time rather than requiring every session creator to pass the override.

What to change in your routing architecture

These changes are backward-compatible. Nothing breaks. But three things are now worth updating:

1. Session initialization code: If you create-then-send in two steps, collapse to initial_events. One round-trip removed from every session cold start.

2. Webhook handler: Add cases for environment.* and memory_store.*. If you have a polling loop anywhere that checks environment or memory store status, you can replace it once your webhook handler covers the new event types.

3. Multiagent UI rendering: If you render subagent activity to users, add thread ID tracking from session.thread_created events and open thread stream connections per subagent. The previous approach (session-level stream with sparse orchestrator commentary) undersells what's actually happening inside the run.

The optional-version change and agent-level effort are additive and require no changes unless you want to simplify existing code.