Three ways to work

Stellar has no one right way to be used. It has three, and the difference between them is how much you delegate — and how much you pay for it. Choose by the size and the risk of the work, not by enthusiasm.

Efficient

One terminal card, one agent, you beside it. No Queue, no contract, manual consent on every request.

When to use it: a localized fix, a question about the code, an exploration whose outcome you cannot describe yet.

How to set it up: open a card of the provider that makes sense and talk. If the work grows, that is when it becomes a task — not before.

Where it fails: when the work grows and stays a conversation. The sign is you scrolling the scrollback to remember what was decided: that should have been in a contract.

Productive

An orchestrator card reads the Queue, writes contracts and dispatches implementers, each in their own territory. The orchestrator does not implement: it briefs, reads the diff, verifies and integrates.

When to use it: several tasks that do not touch the same files, and a human available to decide what is product.

How to set it up:

1. One task per unit of delivery, with a contract: the measured defect, the territory, the gate and the shape of the report.
2. One implementer per territory. Two cards writing to the same file is a collision, not parallelism.
3. allowCommit: false on the implementers. Whoever commits is the orchestrator, one slice per task, after verifying in a clean worktree at HEAD.
4. Review proportional to risk: a mechanical change is accepted by reading the diff; a published contract, production data or shared state ask for a reviewer.

Where it fails: when the orchestrator becomes the bottleneck — rewriting each card’s brief by hand, re-reading what the card already read, committing a whole file with another card’s work inside it. A short brief that points at the task; a separate commit per piece when two cards touched the same file.

Maximum

The board in autonomous mode, with dependencies chaining investigate → fix → review, a concurrency cap, a sprint and a provider chosen for the shape of each task.

When to use it: a lot of independent, well-specified work, and a cost the result pays for.

The cost, plainly: agents in parallel spend many times the tokens of a single agent. Anthropic itself measured, in a research system with a lead agent and subagents, about 15× the tokens of an ordinary conversation — with a result far better than the single agent. It pays off when the work is large and parallelizable; it does not pay off on a task one agent would do alone.

How to set it up:

• Provider per task shape: investigation on a fast, cheap model, implementation on the one that writes the best code, review on a third. Check that it is ready, and not just installed.
• Quota runs out mid-work. A card that dies from quota does not call report — read the scrollback before concluding it failed.
• The concurrency cap is a decision about your machine and your account, not a detail: each agent card is a real process.

Where it fails: when autonomy hides what is happening. Tasks that finish without a report, cards that stop silently, verdicts nobody checked. Use the app’s signals (reports and signals) and the sweep for work without a trace before closing a sprint.

Switching modes

The modes are not exclusive. A productive board opens an efficient card to clear up a doubt; a maximum board has a human who stops everything when a decision is product. What does not mix is the rule of who commits and who judges: that is declared in the contract, not improvised.

Before scaling up a mode, read the anti-patterns — each one cost dearly at least once.