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.

Atlarix has two built-in sub-agents, one for each: explore and build.

An explore sub-agent searches your code and researches the web — it chains web_search and read_url, following sources until it has an answer. It cannot edit anything.

Several 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.

There is no separate "deep research" mode: an explore sub-agent working through search results and pages IS the deep research.

A build sub-agent drafts a scoped edit, but it 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.

Beyond the two built-ins, 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.