Get unstuck faster: decision trees, orchestration, and the stuck trigger
The real time sink is not typing, it is spinning: an agent looping on a solved problem, or dithering between approaches with no house opinion. Three features turn a stuck agent into a moving one, and knowing which to reach for is the skill.
Wall-clock time disappears in two specific places, and neither is keystrokes. The first is an agent looping on a problem someone on your team already solved, burning tokens on rediscovery. The second is an agent dithering between plausible approaches with no sense of how your team actually decides. Cognition has a distinct, purpose-built answer for each, plus a coordination layer for goals too big for one pass. The skill is matching the tool to the failure mode.
The stuck trigger: when the agent is looping
Cognition watches for the signature of being stuck: several tool calls in a row with no real progress, the same file read repeatedly, an approach tried and reverted. When it sees that pattern, it surfaces a teammate's trace that got past the same wall, without you having to ask. Getting stuck is itself the signal; you do not have to recognize it and intervene manually.
You can also pull this forward before the loop starts. If you can feel the agent about to spin, ask "what have we figured out about this?" It routes to cognition_browse and shows existing coverage of the topic, so you start from what is known instead of from scratch.
Decision trees: when the question is "what should we do?"
Some problems are not hard, they are ambiguous: there are three reasonable ways forward and the agent has no basis to pick. Left alone it will either flip a coin or, worse, pick the locally easiest path that your team learned to avoid for good reasons. A decision tree routes the situation through your team's stored decision patterns instead.
"what should we do here?" → cognition_decision_tree
The behavior worth understanding: it is not a generic recommendation engine, it is your team's house style encoded as branches. A branch might say "IF the change touches auth THEN require a second reviewer" because that is a rule your team actually adopted. When it hits a branch flagged ask or refresh, it stops and checks with you rather than applying a possibly-stale policy, then reports the outcome so the pattern stays current.
Orchestration: when the goal has parts
Some work is not one task, it is a goal with many steps that need coordination, sequencing, and the occasional human checkpoint. For that, the controller loop runs the goal as a coordinated sequence with approval gates and a run diary.
- 1Give the goal: "run this with Cognition" (cognition_run).
- 2It loops: claim the next step, execute it, submit the result, ask for the next step.
- 3It stops at done, blocked, or an approval gate, never silently doing something consequential.
- 4Every step lands in an inspectable run diary you can read afterward to see exactly what happened.
Orchestration is for goals that genuinely have parts. A single edit, a one-file fix, a quick question, does not need a controller and is slower with one. Reach for it when coordination, not typing, is the bottleneck, when the hard part is sequencing and not-dropping-steps rather than the individual actions.
Choosing between them
A quick decision guide, since reaching for the wrong one wastes the time you were trying to save:
| The problem is... | Reach for | Plain-English ask |
|---|---|---|
| The agent is looping, no progress | the stuck trigger / browse | "what have we figured out about this?" |
| Several valid approaches, no clear pick | a decision tree | "what should we do here?" |
| A multi-step goal to coordinate | the controller loop | "run this with Cognition" |
These compose. A long orchestrated run will hit decision points, and Cognition routes those through your decision patterns mid-run. You do not have to pick one for the whole session; you pick the one that fits the moment in front of you.
next steps