Agent instance answers a Slack DM, a Telegram message, and an AG-UI browser stream. Memory carries across all of them, scoped per user_id.
Available interfaces
Two categories. Chat surfaces meet humans where they already are. Protocol surfaces are how other systems talk to your agent.Chat surfaces
Protocol surfaces
Setup
Each interface registers its own routes on the FastAPI app. Slack lands events at/slack/events. Telegram at /telegram/webhook. The agent=... parameter tells the interface which agent to dispatch incoming messages to.
Credentials at a glance
Per-interface setup pages have the full OAuth flows, scope lists, and webhook configuration. The summary:Sessions per surface
Every interface maps surface state to AgentOS sessions, so a conversation in Slack carries forward like any other session. The next reply in the same thread reuses the same session and history, no re-mentioning required.Resolving Slack user IDs to names
By default Slack hands you opaque user IDs likeU07ABCXYZ. If your agent’s responses or memory are clearer when grounded in human names, set resolve_user_identity=True on the Slack interface:
users.info and passes the resolved name through to the agent. Off by default because it costs an extra Slack API call per message and isn’t always wanted.
One agent, many surfaces
A single agent can answer on every surface at once. Memory follows the user across surfaces, provided you can map their Slack ID to the sameuser_id the AG-UI client passes:
user_id, a session_id, and a message.
Conditional registration
Don’t register interfaces you don’t have credentials for:Custom interfaces and one-off webhooks
The interface API is small. SubclassBaseInterface, return your routes from get_router, and dispatch incoming messages to the agent. See BaseInterface for the full surface.
For one-off webhooks (a CRM event, a GitHub action, a custom dashboard), don’t write an interface. Add a route directly to the FastAPI app: