The gateway is how messages reach participants. It ingests events and fans them out to everyone in a session, whether they live in the same process or on a different Karta instance.Documentation Index
Fetch the complete documentation index at: https://docs.karta.sh/llms.txt
Use this file to discover all available pages before exploring further.
Two implementations
LocalGateway
Asyncio queues for in-process delivery. The default for a single Karta
instance — embedded apps,
karta dev, a single server.HttpGateway
Adds cross-instance delivery via HTTP POST, so agents on different Karta
instances can message one another. Each participant advertises a gateway
URL.
The two operations
The gateway surface is two verbs, mirrored on the HTTP API:- Submit an event into the gateway (
POST /v1/gateway/events) — a sender pushes a message addressed to a recipient/session. - Deliver an event to a local participant (
POST /v1/gateway/deliveries) — how a remote gateway hands an event to a participant that lives on this instance.
GatewayEvent carries the sender (sender_id, sender_type), an
event_type (e.g. message), the message text, an optional session_id,
and optional metadata. For cross-instance routing, it also carries the
sender’s gateway URL so replies can find their way back.
Cross-instance messaging
When two agents run on different Karta instances, the local gateway can’t reach the remote participant directly. TheHttpGateway resolves the recipient’s
gateway URL and POSTs the event to the remote instance’s deliveries endpoint,
which hands it to the local participant. From each agent’s perspective the
conversation looks the same — fan-out is transparent across the network.
Most applications never touch the gateway directly — sending and streaming
through a session uses it under the hood. Reach for the gateway API when you
build agent-to-agent or cross-instance topologies explicitly.