Overview
Explore the agents, teams, and workflows registered in Demo OS.
This walkthrough follows Demo OS at the reviewed revision, which pins Agno 2.8.1. Use the application’s checked-in requirements.
Demo OS combines several application patterns in one AgentOS. The walkthroughs below describe its registered components and their actual configuration.
What's inside
The entrypoint registers seven native agents, three framework wrappers, four teams, and five workflows. These are top-level counts, excluding team members.
| Kind | Registered components |
|---|---|
| Native agents | Agno Expert, Researcher, Builder, Operator, Media Lab, Planner, Voyager |
| Framework wrappers | Repo Explainer (Claude), Forum (LangGraph), Abacus (DSPy) |
| Teams | Dash, Mentor, Clinic, Newsroom |
| Workflows | Classifier, Scribe, Code Scout, Troubleshooter, AI Digest |
Map: capability → demo
| Capability | Walkthrough |
|---|---|
| Documentation tools | Agno Expert and MCP |
| Knowledge and retrieval | Dash knowledge and RAG |
| User context and reusable lessons | Mentor memory and learning |
| Live request context | Clinic dependencies |
| Persisted task state | Planner |
| Confirmation, user input, external execution | Voyager, Operator, and Builder |
| Coordinated SQL work | Dash team |
The Investment Committee walkthrough describes a separate application.
Why a reference implementation matters
Use the registered source to see how tools, storage, retrieval, and runtime configuration fit together. Each example has its own assumptions; sample identity mappings and SQL guards are not a substitute for production access controls.
Run it locally
Install Docker and provide an OpenAI key in .env. Optional integrations need the additional credentials listed in example.env.
git clone https://github.com/agno-agi/demo-os.git
cd demo-os
cp example.env .env
# Set OPENAI_API_KEY in .env.
docker compose up -d --build
# Dash sample SaaS data and knowledge
docker exec -it demo-os-api python -m agents.dash.scripts.load_data
docker exec -it demo-os-api python -m agents.dash.scripts.load_knowledge
# Clinic synthetic appointment data and records
docker exec -it demo-os-api python -m teams.clinic.scripts.seed_clinic
docker exec -it demo-os-api python -m teams.clinic.scripts.load_recordsOpen localhost:8000/docs, then connect http://localhost:8000 in the AgentOS UI. Choose the component named in each walkthrough. Loading sample knowledge makes embedding calls; it is not performed automatically on application startup.
Deploy it to Railway
Install the Railway CLI and log in. Create the production env file before provisioning; this script does not read the local .env file:
cp example.env .env.production
# Set OPENAI_API_KEY and production credentials in .env.production.
railway login
./scripts/railway_up.shThe script creates the demo-os service and prints its domain. Production enables JWT authorization. If verification configuration was not supplied, the app cannot serve until it is added.
Connect the domain in the AgentOS UI, enable token-based authorization, and copy the verification public key into .env.production as a quoted multiline value:
JWT_VERIFICATION_KEY='-----BEGIN PUBLIC KEY-----
MIIBIjANBgkq...
-----END PUBLIC KEY-----'Use your actual public key, then apply it explicitly from the quoted, shell-compatible production env file and redeploy:
set -a
source .env.production
set +a
railway variables --set "JWT_VERIFICATION_KEY=$JWT_VERIFICATION_KEY" --service demo-os
./scripts/railway_redeploy.sh
railway logs --service demo-osThe reviewed railway_env.sh exits after its first variable on Bash 5 because its counter increment fails under set -e. The command above delivers the JWT key directly. Apply any other changed production variables explicitly through Railway until that upstream script is fixed.
Confirm that the app starts and protected requests authenticate successfully. Production data loaders need access to Railway’s private database network; run them inside the deployed container, not from a local process using its private hostname.