Lead and Workers
Turn a chat into the session's lead so it splits the work and starts and directs Workers in sessions of their own.
One switch in the composer turns a chat into the session's lead. The lead splits the work, starts Workers as sessions of their own, follows each one from a live card in its chat and reads their work when they finish. Only the lead starts and directs Workers, so a Worker cannot make itself lead.
How the lead works
Turned on, the chat is briefed as the session's lead. It coordinates through the agents bus with the krad-ade-agents CLI; krad-ade-agents help lead prints the guide it follows:
- Split the work into self-contained tasks, each with acceptance criteria, written into the spawn task so the Worker needs nothing else.
- Spawn one Worker per task, then wait for each.
- When a Worker stops, read its conversation and the files it changed, and check the acceptance criteria.
- If the work falls short or the Worker is stuck, send a precise correction and wait again. If it waits for a permission, tell you to answer it in the Worker's session.
- Finish with a short report: what each Worker did, what it verified and what is left for you.
The lead starts Workers only when you ask for work to be done, such as build, fix, implement, review or run a task. For questions, it just answers.
Commands the lead uses
krad-ade-agents list
krad-ade-agents spawn --agent claude --worktree api "Add the endpoint and its tests"
krad-ade-agents send 12 "The tests must cover the empty case too"
krad-ade-agents wait 12 --timeout 1500
krad-ade-agents read 12 --lines 80| Command | What it does |
|---|---|
list | The agents of the environment: id, title, agent state and group |
spawn --agent <harness> [--worktree <name>] "<task>" | Starts a Worker in a session of its own and prints its id once it has started; if it cannot start, the error says why |
send <id> "<instruction>" | Sends the Worker an instruction as its next message, as you would; a closed Worker reopens with its conversation to take it |
wait <id> --timeout <secs> | Blocks until the Worker stops working |
read <id> --lines <n> | The end of the Worker's conversation; reading a Worker that has finished closes it |
--agent takes claude, codex or opencode. Use --worktree for Workers that edit the same repository in parallel, so each one works in its own worktree.
Workers
Each Worker gets a new session in the group and runs there as a chat. Opening it does not move your selection or your keyboard focus. The Worker belongs to the lead. In the lead's chat it appears as a card that stays up to date with the Worker's task, agent state and most recent activity. Clicking the card goes to the Worker's session.
A Worker closes:
- if its harness does not start, in which case the lead's
spawnreports the error; - after it is done and the lead has read the result: its process ends and its session disappears from the sidebar, but the chat is saved by its resume id and the card can open it again;
- when its lead is removed or its session deleted; the app asks first if a Worker is still working.
Workers are not subagents. A subagent is a helper a harness starts inside its own turn, with a fresh context and no terminal; the bus does not know it. The chat shows a subagent as a card you can open to read its whole conversation.
Workers run on the same host as their environment, including remote hosts. Gateway chats cannot be started as Workers.