Skip to main content

Agents

An agent is the persistent worker: a system prompt, a model, a tool set, and its own container with a filesystem. A run is one conversation with that worker. The agent keeps its configuration, its files, and its accumulated memory across all of its runs — that's the practical difference between the two.

The manual's Creating & Configuring Agents covers the how-to. This page is about how agents behave.

What defines an agent​

  • Name — unique among siblings under the same parent. You and other agents refer to it by name in prompts and delegation, so name by role: code-reviewer beats agent-7.
  • System prompt — the core instructions: who it is, what it does, how it should behave. Present in every run, never compacted. See Context.
  • Model — changeable at any time; new runs pick up the new model. Some models also expose a reasoning-effort setting.
  • Tools — which capabilities it has, from file editing to web browsing to delegation. See Tools.
  • Container — its own isolated Linux environment, with private storage at /workspace and team storage at /shared. See Persistence for what survives restarts and what resets.
  • Place in the tree — standalone, or a child of another agent.

One thing that trips people up: children inherit nothing. Making an agent a child means the parent can delegate work to it and they share the same /shared volume — it does not copy the parent's prompt, model, or tools. Every agent is configured on its own.

Hierarchy vs. folders​

Taurus has two ways to organize agents, and they do different things.

Hierarchy (parent/child) is the runtime relationship. Parents can delegate to their direct children, everyone in one tree mounts the same /shared volume, and children automatically show up in the parent's team roster so it knows whom to delegate to.

Folders are purely visual. They group agents in the sidebar and have zero runtime effect — a folder doesn't enable delegation or shared storage. You can mix agents from different trees in one folder if that's how you like to look at them.

Rule of thumb: if agent A needs to hand work to agent B, make B a child of A. If you just want tidiness, use a folder.

Status​

The dot next to each agent in the sidebar is derived from its runs — you never set it directly:

StatusMeaning
IdleNo active runs. Ready for work.
RunningActively working on a run.
Waiting for inputPaused, waiting for you (or a parent agent) to respond.
Waiting on childBlocked on a delegated task or subrun finishing.
ErrorThe most recent run ended with an error.

Separately, you can disable an agent in Settings → Advanced: it keeps its configuration and files but won't start runs or accept scheduled triggers until you re-enable it.

System access​

By default, only your primary agent can manage your whole account. The Full system access toggle in Settings → Advanced gives another agent the same power — an Admin tool that can create, update, delete, and orchestrate any agent in your account, not just its own children.

Most agents don't need this; the Supervisor tool (managing direct children) covers normal team workflows. Reserve system access for coordinator agents, and note the safeguard: an agent with system access cannot grant system access to others.

Further reading​