Which tool when

Note

The board gives you seven ways to hand over work, from a chat to a Goal that runs until it is done. Pick the smallest one that can finish the job: every step up buys reach and costs tokens and review time.

The problem it solves

A ticket, a Loop and a Goal can all end with the same diff. What differs is who decides what happens next (you, the agent or a pipeline), how often it runs, and how much you review before anything is written. Picking the wrong one is rarely fatal, but it is the most common reason a run costs more than it should or stops somewhere you did not expect.

How it works

I want to … use …

I want to	Use	Where
Ask something, think out loud, no deliverable yet	A chat	The Chats tab. Put it on the board when it turns into work (Ask in Chats).
Get one change done: a bug, a feature, a report	A ticket	Create, Type set to Task (an agent runs it).
Track a piece of a bigger ticket separately	A subticket	Create with a Parent, or let the agent split it (Split big work).
Group related tickets with no agent of its own	An epic	Type set to Epic (no agent, groups subtasks).
Run one skill or slash command, such as a report	A command	Type set to Command (runs a /skill), or the Report library (Run a repo report).
Do the same job on a clock, or a pipeline of steps	A Loop	Type set to Loop (runs on a cron schedule) (Run a Loop).
Keep going until an objective is met	A Goal	Type set to Goal (loops until an objective is met) (Run a Goal).

Auto or a plan

The Mode field decides whether the agent may start writing straight away.

Choose	When
Auto	You could write the acceptance test yourself, and a wrong first attempt is cheap to send back: bug fixes, tests, small features, reports.
A plan mode	The direction is still open, the change touches many places, or a wrong turn is expensive to undo. The agent writes a plan and parks; nothing is edited until you Accept plan.

A plan is the cheapest place to change direction: a comment on a plan costs a paragraph, the same comment on a diff costs a rewrite. See Plans you can point at.

Which plan type

Plan type	Mode in the form	Fits
Text plan	Plan (verbose text plan first)	Backend and refactoring work, where the plan is a list of files and steps. You comment on selected words.
Flow plan	Flow plan (visual behavior graph)	Behaviour with branches: a sign in flow, a state machine, a pipeline. You edit and comment on blocks.
Interactive plan	Interactive plan (visual)	Anything you want to see: a screen, a report layout, a comparison. You annotate any element of an interactive page.

The type an agent picks when it files a plan on its own is Default plan type in Settings > Agents.

One agent or a Loop

Situation	Use
One coupled change, even a large one	One agent. Splitting a coupled change adds handoffs and merge conflicts, not speed.
Many independent targets (every package, every open PR) whose work would not fit one agent’s context	A Loop, one subticket node per target or per batch of targets.
Independent strands that must run in an order, or need a human gate in the middle	A Loop: its edges are the order, and a gate parks it for you.
Steps that are not agent work (read GitHub, run a command, post to Slack)	A Loop with source, shell and sink nodes, which run no model at all.
The same job repeated until a result is reached, with no fixed number of steps	A Goal.

With orchestration on (Settings > Agents > Orchestration), an agent makes this call itself: it stays solo by default and builds a Loop only for independent strands.

What you control

• The type, mode, model and thinking level of every ticket you create.
• Whether agents may split work at all, and how many children they may start (Settings > Agents > Orchestration).
• Every Loop’s pipeline, which you can edit before its first run.
• A Goal’s caps, which bound it when it never reports that it is done.

Limits and trade-offs

• A command runs one skill and nothing else; for anything open ended, use a task.
• An epic runs no agent. Its children do the work.
• A Loop’s children run at the same time unless an edge orders them, so they can conflict when they touch the same files. The orchestrating ticket resolves that when it merges them.
• A Goal judges “done” by a model reading its ledger. Write the Done when sentence as a test someone could check.

Where you meet it on the board

• The Type and Mode fields of the Create ticket form.
• A plan card in Pending Action, with Execute by subagent and Execute by loop when orchestration is on.
• The Loop pipeline and Goal sections of a Loop or Goal ticket.

Related

• Recipes: tickets that work, for a ready-made ticket per job.
• Write a ticket an agent can finish, to pick a mode.
• Loops and Goals, for how a pipeline and a Goal run.