Sub-agents and delegation

Two different reasons.

For research, several scopes can be explored at once — "how do auth, billing, and notifications interact" is three searches that do not depend on each other.

For implementation, a scoped change can be drafted by a sub-agent while the main thread stays on the plan.

Scouts explore folders, search your code, and research the web. They run in parallel, each as its own inline card with live thinking and nested tool calls in true order.

The main agent keeps working and folds in each result as it finishes. Built-in roles cover the common shapes: explorer for recon, architect for planning.

A writer sub-agent does not write anything.

Its edits come back as a proposal PER FILE. The main agent reads each diff and decides. Accepting writes the sub-agent's exact bytes — nothing is retyped along the way — and a file that is not already on your allow-list still asks you, exactly as it would for any other edit.

So a delegated change goes through the same approval you would get if the main agent had made it itself.

A long sub-agent moves to the background on its own instead of holding the turn. The running-tasks chip lists sub-agents alongside background commands, so you can watch progress or stop one without waiting.

Results are delivered automatically when each finishes.

Sub-agents are addressed by the NAME the agent gave them when it started them — part of the name is enough — so you can follow what is happening without tracking ids.

You can read a sub-agent's live narration, or hard-stop one that is stuck or no longer needed, which also stops its token spend. A quiet sub-agent is usually still thinking.

Define reusable agents in .atlarix/agents/ — a system prompt, a mode, an optional model, and a tool allowlist — committed with your repo so your whole team gets them. They appear in the mode picker.