Agents and Fleet

An agent is a configured AI entity: a model paired with a personality, a set of tools, and permissions. Each agent runs independently inside its own sandbox. You create agents in the app, give them a soul prompt that shapes their behavior, assign roles, tools, and skills, and point them at channels. From there, they handle work autonomously.

Soul prompts

The soul is a markdown description injected into the agent's system prompt at run time. This is where you define who the agent is -- its tone, priorities, boundaries, and domain knowledge. Everything the agent says and does is filtered through this prompt.

Write the soul in plain markdown. Be specific. "You are a helpful assistant" produces a generic agent. "You are a senior SRE who triages alerts, writes postmortems in plain English, and never suggests restarting as a first step" produces a useful one.

The soul is editable from the agent detail page in the app. Changes take effect on the next run -- no restart required.

Models

Each agent uses a single model for inference. The default is arcee-ai/trinity-large-preview:free via OpenRouter. The model itself is free, but you still need a configured provider key in Settings > Gateway for inference to run.

• Configurable per-agent in the app.
• Any OpenRouter-compatible model works. Set the model identifier and the agent uses it on the next run.
• Paid models (GPT-4o, Claude, etc.) work but can cause rate limit errors and unexpected costs during development. Stick with the free default unless you have a reason to switch.

Roles and ownership

Roles are the reusable operating defaults for agents. They let you apply the same posture across multiple agents without rebuilding each configuration by hand.

A role can shape:

• queue mode and work posture
• tool posture and access expectations
• network defaults
• reusable GitHub repo capability defaults

This matters because the app now separates structure from execution:

• Company is where you think about teams, staffing, and reusable role defaults.
• Agents is where you inspect one specific agent's soul, model, memory, tools, and overrides.
• Work is where you inspect the goals and tickets that agent is helping move.

Use roles when you want consistency. Use per-agent settings when one operator needs to diverge.

Memory

Agents remember things across sessions. During a run, an agent can create, update, or remove memories. These are stored per-agent in the database.

Three memory operations are available to the agent:

• add -- Store a new fact or observation.
• update -- Revise an existing memory with new information.
• remove -- Delete a memory that is no longer relevant.

Memories have a decay mechanism. Pinned memories persist indefinitely. Unpinned memories lose relevance over time and eventually drop out of the agent's active context. The agent decides when to create memories -- you do not need to manage them manually.

Sessions

A session ties a sequence of messages into a single conversation thread. The session key is derived from the source channel and context -- for example, telegram:12345 for a Telegram chat.

Same session key means same conversation. The agent sees the full thread history and can reference earlier messages. Sessions enable multi-turn conversations that span many individual messages and runs.

Tools

Agents have access to built-in tools across these categories:

• Execution -- Run shell commands, scripts, and code in the sandbox.
• Filesystem -- Read, write, list, and edit files.
• Memory & collections -- Store durable knowledge and structured data.
• Web & media -- Search, extract pages, and use enabled media capabilities.
• Work -- Search goals and tickets, post updates, assign ownership, and move queue state.
• Teams & policy -- Inspect teams, roles, and policy posture.
• Activity & receipts -- Query activity history and inspect prior runs.
• Credentials -- Access stored secrets needed for external services.

Tools run inside the agent's sandbox. Plugins can contribute additional tools that extend the built-in set.

See the Tools Reference for the full list with parameters and scope notes.

Queue modes

Queue modes control how an agent handles messages that arrive while it is already running.

• steer (default) -- New messages are injected into the running agent's context. The agent can change course mid-execution based on the new input.
• collect -- Messages accumulate in a buffer. When the current run finishes, the agent processes the batch together.
• followup -- Messages are queued strictly. The agent processes one message at a time, in order.

Queue mode is often best managed through a role when several agents should share the same operating posture.

Multi-agent collaboration

Multiple agents can share the same channel. They triage messages independently, claim exclusive turns, and silently pass when a message is not relevant. See Agent Collaboration for the full guide on how agents work together.

Network policy

By default, agents have open network access within their sandbox. You can restrict this per-agent by configuring a network policy that specifies which domains and IPs the agent is allowed to reach.

Use network restrictions when an agent should only talk to specific services -- for example, limiting a customer support agent to your internal API and nothing else.

Skills

Skills are knowledge packs deployed to the agent's sandbox filesystem. They contain markdown instructions, reference docs, scripts, and templates that teach the agent how to perform specific tasks. The agent reads them on demand during runs.

Skills are assigned per-agent, per-team, or globally. See Skills for the authoring guide and assignment details.

Budget limits

Every agent can have a cost budget configured in the app. Costs are tracked per-model and per-agent, so you can see exactly where inference spend is going. When an agent hits its budget limit, runs are paused until the limit is raised or reset.

See Costs & Budgets for configuration details and cost tracking.