Kero orchestrate

One agent doing the work well is the default. Splitting is a tool for when it measurably helps: independent pieces, output too large for one context, or a tool that does one thing much better. Every split costs tokens, latency and a merge, and parallel agents make implicit decisions that can collide.

Decide first

• Do it directly when the change is small, when there is back and forth with the person, when every piece needs the same heavy context, or when latency matters. Delegating a five minute task costs more than doing it.
• Split when pieces are independent (no shared files or state, fixing one does not fix another), when research would flood the main context, or when a specialist tool clearly wins.
• Scale effort to the task: a single agent with a few calls for a fact, two to four workers for a comparison, more only for wide research or many independent files. A multi agent run uses many times the tokens of one agent.

The brief

Every brief is self contained; the worker has none of this conversation. It names:

• Goal and why, in two lines.
• Scope: the files or areas it owns, and what it must not touch.
• The project skill and the rules that apply, by path.
• Acceptance: an observable check (a test, a command output, a screenshot, an audit run) and what counts as done.
• Return: the exact shape of the report, short, with paths to artifacts instead of their content, ending in one status: DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT or BLOCKED.