ag-ui-claude-managed-agents

ag-ui-claude-managed-agents

Connect an AG-UI frontend to Claude Managed Agents, Anthropic's hosted agent runtime. Each AG-UI thread maps to one managed session. Each run drives one turn of that session and streams the agent's events back as AG-UI events.

Installation

pip install ag-ui-claude-managed-agents

Usage

Create a managed agent and an environment once (in the Console, or via the SDK), then wrap them:

from fastapi import FastAPI
from ag_ui_claude_managed_agents import ManagedAgentsAgent, add_managed_agents_fastapi_endpoint

app = FastAPI()

agent = ManagedAgentsAgent(managed_agent_id="agent_...", environment_id="env_...")
add_managed_agents_fastapi_endpoint(app=app, agent=agent, path="/agent")

managed_agent_id is the Anthropic managed agent's id (agent_...), named apart from AG-UI's own agent id so the two never collide. The endpoint helper accepts a POST with a RunAgentInput body and streams the encoded AG-UI events. Without FastAPI, iterate the events yourself:

async for event in agent.run(run_input):
    print(event.type)

The Anthropic client reads ANTHROPIC_API_KEY from the environment. Pass client to supply your own AsyncAnthropic.

What it does

Frontend tools (human in the loop)

Tools passed in RunAgentInput.tools are registered on the session as custom tools. When the agent calls one, the run emits the tool call and finishes, leaving the session parked. The client executes the tool and starts the next run with a role: "tool" message carrying toolCallId. The adapter forwards it into the session as the tool result and resumes streaming.

Backend tools

Tools your server executes go in backend_tools:

import json

from ag_ui_claude_managed_agents import BackendTool, ManagedAgentsAgent

agent = ManagedAgentsAgent(
    managed_agent_id=managed_agent_id,
    environment_id=environment_id,
    backend_tools=[
        BackendTool(
            name="get_weather",
            description="Get the weather for a location.",
            parameters={"type": "object", "properties": {"location": {"type": "string"}}},
            handler=lambda tool_input: json.dumps({"temperature": 21}),
        ),
    ],
)

The handler may be a plain function or a coroutine. A plain function runs in a worker thread so a blocking handler never stalls the event loop; a coroutine is awaited on the loop. The tool call and its result stream to the UI, and the result is returned to the agent. If the turn times out or the client disconnects mid-tool, an error result is posted for the call so the session is not left parked.

Options

Security: authenticate and bind threads to callers

AG-UI thread ids are supplied by the client and this agent keys thread↔session state by managed_agent_id:thread_id, so a thread id is effectively a bearer identifier: any caller who presents a thread id resumes that thread's session. The AG-UI protocol carries no user identity of its own, so authorization is your host's responsibility:

• Put the endpoint behind your own authentication. Never expose it unauthenticated.
• RUN_ERROR never relays the text of a failure this integration did not author. An SDK, session-store or API exception can carry session ids, request paths or credentials, so its message goes to on_error and the client gets a stable message plus the machine-readable code. Two things are deliberately still verbatim, because they are the point of the event: a session.error from the API (a structured field with its own type code, and the only account of why a session broke) and a backend tool's own exception message (your code, and what the agent needs to recover).
• In multi-tenant deployments, bind threads to the authenticated caller so one caller cannot resume another's session by guessing or replaying a thread id. Do this with a session_store whose keys include the caller identity derived from your auth layer (never from the request body):

The key the agent passes in is already scoped to the managed agent; treat it as an opaque string and prefix it with the caller identity rather than parsing it:

class PerCallerStore:
    def __init__(self, owner_id: str, inner: dict[str, SessionRecord] | None = None) -> None:
        self._owner_id = owner_id
        self._inner: dict[str, SessionRecord] = inner if inner is not None else {}

    def _scoped(self, key: str) -> str:
        return f"{self._owner_id}|{key}"

    def get(self, key: str) -> SessionRecord | None:
        return self._inner.get(self._scoped(key))

    def set(self, key: str, record: SessionRecord) -> None:
        self._inner[self._scoped(key)] = record

    def delete(self, key: str) -> None:
        self._inner.pop(self._scoped(key), None)

Reuse ONE store instance per caller — construct it once and cache it:

_shared: dict[str, SessionRecord] = {}
_stores: dict[str, PerCallerStore] = {}


def store_for(owner_id: str) -> PerCallerStore:
    if owner_id not in _stores:
        _stores[owner_id] = PerCallerStore(owner_id, _shared)
    return _stores[owner_id]

Runs are serialized per thread within a store instance, so a fresh wrapper per request would let a double-submitted thread post into the same session twice. Cache the store (as above) and construct the agent with store_for(owner_id).

Notes

• The default session store is in-memory: restarting the process starts new sessions. Managed sessions themselves persist server-side.
• Turns are serial per thread. A second run on a busy thread errors with run_in_progress.
• Only text parts of a user message are forwarded. A message carrying only images or documents has nothing to send and errors with empty_run.
• A client disconnect or timeout interrupts a newly created session. A reconnected session remains available for another observer; disconnecting does not cancel its pending work.
• Built-in tools (bash, file editing, web) execute inside the managed environment. This adapter surfaces them for display, so enable them on your agent as usual.
• Tool-result text blocks reach the UI verbatim: they carry literal output (a file read, a shell transcript), where < means those four characters. Only search_result blocks, whose bodies are extracted from HTML, have their entities decoded.
• A follow-up message posted immediately after a tool result can race the session's asynchronous un-park and be rejected with a 400. That specific rejection is retried, matched on the message containing waiting on responses — wording that has not been confirmed against the live API. If the API rewords it the retry stops firing and the 400 surfaces as a run error; nothing else is affected. See the comment on the matcher.
• The default in-memory store is bounded (IN_MEMORY_SESSION_STORE_MAX_ENTRIES, 10 000 mappings): thread ids are client-supplied, so past that the least-recently-used mapping is evicted and that thread starts a fresh session. Pass a smaller cap to InMemorySessionStore(max_entries=n), or supply a persistent store.
• A run that is interrupted — a turn timeout, a client disconnect, or a blocked action this integration cannot answer — forgets the frontend tool calls it had recorded as parked. The interrupt cancels whatever the session was waiting on, so answering one of those calls on the next run would be rejected as stale. If the interrupt itself could not be delivered the ids are kept, since the session may still be parked on them.
• A session that registers custom tools holds a full replacement tool list, frozen at the last update, so the agent's own tools are re-read once per run to catch a Console edit to them. A session with no custom tools runs the agent as-is and skips that read entirely.

Running the examples

cd integrations/claude-managed-agents/python/examples
uv sync
export ANTHROPIC_API_KEY=sk-ant-...   # or ANTHROPIC_AUTH_TOKEN
uv run python setup.py               # provisions an environment plus one agent per Dojo feature (idempotent)
uv run dev                           # http://localhost:8025

Setup writes the provisioned IDs to examples/.managed-agents.json (gitignored). It reuses existing agents by name and does not modify them. To apply prompt or model changes from examples/agents.py, archive the agent and re-run setup.

The examples default to claude-sonnet-5-5, which supports runtime context via native system messages. MANAGED_AGENTS_MODEL overrides this default; choose a model from the system-injection support list. Existing agents created on Sonnet 5 are not upgraded by changing this variable or rerunning setup. To migrate, archive the old example agents, rerun setup to provision replacements and rewrite the saved IDs, then restart the example server and start new sessions. Existing sessions remain bound to their original agents.

Reconnect to an existing managed session

A server-side resolver can adopt a session created elsewhere, including after a process restart:

from ag_ui_claude_managed_agents import ManagedAgentsAgent, SessionBinding

async def resolve_session(thread_id: str) -> SessionBinding | None:
    # Authorize using the authenticated server-side caller, never forwardedProps.
    saved = await authorized_bindings.lookup(thread_id)
    if saved is None:
        return None
    return SessionBinding(
        session_id=saved.session_id,
        session_thread_id=saved.session_thread_id,  # optional child identity
        last_user_message_id=saved.last_user_message_id,
    )

agent = ManagedAgentsAgent(
    managed_agent_id="agent_...",
    environment_id="env_...",
    resolve_session=resolve_session,
    session_store=persistent_store,
)

The callback may be synchronous or asynchronous and must authorize access to the bound tenant and session. It runs when the store has no binding. The resulting binding is saved in the configured SessionStore. Native tools and MCP settings are preserved for adopted sessions. No session identifier is read from client forwardedProps.

Supply last_user_message_id when importing a binding to identify which user message was already sent. If absent, adoption treats the latest input user message as history and does not replay it. A later new user message can continue the session. A child binding reads that child's history and stream; sending a user follow-up to a child is explicitly unsupported by the native API.

Reconnection opens the stream before reading every history page, deduplicates live event IDs, and recovers unanswered requests. Custom tool requests retain the native event ID as toolCallId; answer with a matching role: "tool" message. Recovered backend requests are surfaced without automatically running the backend handler again. A user follow-up never rejects unanswered tools.

Native tool and MCP confirmations finish with outcome.type: "interrupt" and reason: "tool-approval". Both interrupt id and toolCallId are the native event ID; metadata includes the native event type and tool details. Continue with resume: [{"interruptId": "native_event_id", "status": "resolved", "payload": "allow"}] (or "deny"). A "cancelled" response maps to denial. Invalid or unmatched responses are rejected before posting any answers. Partial responses leave the other requests pending. Native responses route to child threads automatically by call ID.

Resumed runs emit managed_agents.session with resumed: true, sessionId, threadId, and optional sessionThreadId. Terminated bindings remain stored and return session_ended; unavailable sessions return session_unavailable. Neither condition silently replaces the user's conversation with a new session.

SessionRecord.last_event_id persists the last observed native event. On a reconnect, events after that cursor are replayed as RAW events and canonical text/tool-result events without executing historical tools. A trusted importer may supply SessionBinding.last_event_id; absent an initial cursor, previously imported history is not replayed.

If a saved non-null event cursor is missing from the native history, recovery returns history_cursor_unavailable without advancing it. Cursor writes follow successful event translation. Recovered live approvals require explicit resume responses even when a default automatic confirmation policy is configured.