Product Copilots & Agents

Build a system of agents to power every part of your product and operations, from chat to proactive assistance.

Software is becoming agentic and many parts of your product will become agent-driven.

Most products start with a chat copilot, then add more agent-driven surfaces: smart empty states, inline workflow recommendations, personalized help notes, proactive nudges. Each one is its own agent with its own job.

Agno runs all of them in one place. Sessions, memory, knowledge, and auth are shared across every surface, so the product feels like one system.

from agno.agent import Agent
from agno.db.postgres import PostgresDb
from agno.models.openai import OpenAIResponses
from agno.os import AgentOS

db = PostgresDb(db_url="postgresql+psycopg://ai:ai@localhost:5532/ai")

agent = Agent(
    name="Product Copilot",
    model=OpenAIResponses(id="gpt-5.5"),
    db=db,
    add_history_to_context=True,
    num_history_runs=5,
    enable_agentic_memory=True,
)

agent_os = AgentOS(agents=[agent])
app = agent_os.get_app()

if __name__ == "__main__":
    agent_os.serve(app="copilot:app", port=7777)

That is the start of your product copilot. Persistent multi-turn history, per-user memory, and an HTTP API with streaming, sessions, and auth.

Auth and tenancy are built in

Your AgentOS ships with JWT-based authentication. Turn it on and identity is read from a bearer token. user_id, session_id, and scope claims all come from the token.

from agno.os import AgentOS

agent_os = AgentOS(agents=[agent], authorization=True)
# Every endpoint now requires a valid JWT. user_id, session_id,
# and scopes are read from the token before any agent code runs.

The mental model

The agent runs in your AgentOS as a service. Every product surface is a client that calls it over HTTP.

Surface	How it reaches the agent
In-app copilot panel	POST /agents/{id}/runs scoped to user_id and a per-thread session_id
Inline action (“summarize this”, “draft a reply”)	The same endpoint, a short-lived session_id
Slack / Telegram / WhatsApp	An interface adapter maps the channel onto runs and sessions
Backend event (webhook, cron)	A custom FastAPI route calling agent.arun(...)

Every surface shares the same (user_id, session_id) state. A user the agent met in the chat panel is already known to the inline action agent.

Guided paths

You have	You want	Start with
A B2B SaaS product	Per-customer, per-user isolation out of the box	Serve as an API
Users in Slack or the browser	The same agent where they already work	Interfaces
Internal docs, Drive, databases	An agent grounded in live company data	Connecting your data
Multi-day user relationships	Memory that persists per user across surfaces	Sessions and memory

Explore

Serve as an API

Turn the agent into an HTTP service with streaming, sessions, and auth.

Sessions and memory

Persistent multi-turn history and per-user memory, with no state layer to build.

Connecting your data

Give the agent live access to Slack, Drive, databases, and MCP servers.

Interfaces

Slack, Telegram, WhatsApp, and browser surfaces with one line each.

Developer Resources

• Runtime overview
• Sessions
• Memory
• Scout tutorial