Agents

An agent is an isolated persona with its own home directory: config, provider keys, model choice, skills, sessions, and memory. The default agent lives at /root/.aios; named agents live at /root/.aios/agents/<name>.

Managing agents

Web UI → Agents (System section): card grid with gateway state. The ⋮ menu on each card offers Edit (description, provider, model — written into that agent’s config.yaml), Start/Stop/Restart gateway, and Delete (moves the agent’s folder to agents/.trash/ — recoverable, never destroyed). + New Agent creates one. Config edits apply on the next gateway restart.

CLI equivalent: aios profiles list|create|delete|use.

Talking to an agent

• Dashboard Chat / Vibe Code panel — agent tabs in the panel’s session dropdown open a live conversation with any agent.
• Telegram — each agent can run its own bot: set TELEGRAM_BOT_TOKEN in the agent’s .env, then systemctl enable --now aios-gateway@<name>.
• CLI, one-shot: aios -p "question" — add --resume <session> to continue a conversation, --output-format json for scripting.
• Remote HTTP: POST /api/vibe/aios {"prompt": "...", "resume": "..."}.

Per-agent memory

Every agent carries durable memory across sessions: MEMORY.md (notes) and USER.md (user profile) under <agent home>/memories/. Memory is injected into every turn automatically — agents recall it without being asked — and agents update it themselves via the memory tool (“remember that…”). Size-capped so it never bloats context. Memories are strictly per-agent: one agent never sees another’s.

Model assignment

Each agent’s config.yaml picks its provider/model. The harness then routes each turn to a cheap or frontier tier automatically (see the Harness chapter). When you switch providers, tier models realign automatically — e.g. switching to anthropic routes routine turns to Haiku and hard turns to Opus without touching harness.json.

Credentials: multiple keys per provider

A single ANTHROPIC_API_KEY-style entry in .env is the default and always works. If you’re hitting rate limits on one key, add more to a pool and the harness rotates through them automatically:

aios credentials add anthropic sk-ant-key-2 --label "second key"
aios credentials list                    # see status: healthy/exhausted/dead
aios credentials revive <id>             # manually clear a cooldown

Selection strategy defaults to round-robin; a key that gets rate-limited (429) cools down for an hour automatically, one that comes back 401 for 5 minutes — no manual intervention needed, it just skips that key until the cooldown clears. Pool keys take priority over the plain .env key when present; with no pool configured for a provider, nothing changes from the single-key behavior above.