When to use it

Process has a cost. A spec, a plan, and an independent verification pass are worth it when the work is genuinely uncertain or coupled — and pure overhead when it isn't. A plan for a one-liner is the failure, not the diligence. Agentry is built to run the least process that wins, so the question is which shape a task earns.

The floor: just one-shot it

A trivial, clear, reversible change with no hidden decision should be a single bounded edit, then a quick verify — nothing more. Renaming a variable, fixing an obvious typo, adjusting a constant: reach for /agentry:go if you like the recall and the verify, but don't expect — or want — a spec and a plan to wrap a five-second change. The floor is the default, and staying on it is the system working as intended.

Spec-first: when a design fork hides in the goal

When "done = X" isn't actually clear — the ask is product-shaped, or a real decision is buried in the goal — shape a Spec with observable acceptance criteria and gate it before building. The signal is a fork you'd otherwise resolve silently mid-edit: which records win on a tie, what the boundary of "better" is, which behavior is in scope. Surface it first; a hidden decision fork is exactly what vetoes a one-shot.

Decompose + verify: when it's multi-file or structurally non-trivial

When the work spans multiple coupled parts with real design forks, it earns the full shape: spec → plan → split into bounded tasks → build → independent verify → assemble. This is where the conducting pays for itself — bounded contracts keep parallel work safe, and a separate verifier catches the "every task passed but the product is broken" gap.

When not to reach for it

• The change is trivial and you're already in the file — just make the edit; let the floor stay the floor.
• You don't actually have a task yet — Agentry conducts work, it doesn't replace deciding what the work is.
• You want process for its own sake — ceremony a task didn't earn is cost, not rigor.