Skip to main content
The agent invoke registry maps an agent id to a template agent, so a request handler can resolve and invoke the right agent by id.

Quick Start

1

Default (single-tenant)

Use the module-level functions — no registry= kwarg needed. This is what almost every user wants.
2

Scoped (multi-tenant / multi-embedding)

Construct an AgentRegistry() per tenant and pass it via the registry= kwarg. Two AgentOS gateways in the same interpreter can now hold isolated agent sets.

How It Works

Every invocation resolves through resolve_session_agent, which clones the registered template per request so concurrent callers never share mutable conversation state. unregister pops the id atomically under a lock (dict.pop), so a concurrent unregister can’t race between the membership check and the delete — the previous split check-then-delete returned uncaught 500s on concurrent deletes, which is the reason the class exists.

Configuration Options

AgentRegistry methods: Module-level functions (backward-compatible):

Best Practices

The module-global is already thread-safe, and the registry= kwarg is the escape hatch, not the default path. Use plain register_agent(agent_id, agent) / get_agent(agent_id) for single-tenant setups.
Two AgentOS gateways sharing the module global will step on each other’s agent ids. Construct one AgentRegistry() per gateway and thread it through your register_agent(...) calls.
Every invocation goes through resolve_session_agent, which clones the template per request via clone_for_channel. Do not stash mutable state on the registered agent expecting it to survive across calls.

AgentOS Chat Session Isolation

Session isolation cloning path

Serve Agents Auth

Surface where this registry is invoked