Agent Altitude Gate

The rest of this framework is built for agent products — and it quietly assumes you already know the thing you're building is an agent. This gate is where that assumption gets tested, before you spend a single step on a PRD, a system design, guardrails, or an eval harness the problem may not need.

The job of this gate is to talk you OUT of building an agent whenever a simpler tier will do. Most ideas that arrive described as "an agent" are actually a single model call or a deterministic workflow wearing an agent costume. Building the agent version anyway buys you planning loops, tool orchestration, non-determinism, and an eval/guardrail burden — for a problem that a linear pipeline would have solved more cheaply and more reliably. The default answer here is the lowest tier that works, not the most impressive one.

Conventions

Follow _conventions.md (read-first order, docs/ vs artifacts/, don't-clobber guard).

Before you start

Read PROJECT.md — especially §2 (the agent: core task, autonomy, real-world actions) and §5 (success definition). If it doesn't exist yet, ask the user the three questions the ladder turns on: what is the one task, what triggers it, and does anything about "what to do next" have to be decided at runtime rather than written down in advance?

The altitude ladder — pick the LOWEST tier that solves it

Climb only when the tier below genuinely cannot do the job.

The one gate question

Does the model need to decide what to do next at runtime — or can you write the control flow down in advance?

• If you can draw the flow as a fixed flowchart → it's a workflow (tier 3), not an agent. Code owns the branches.
• If it's a single transform with no next step → tier 2.
• If it's predicting a label/number from features → tier 1.
• Only if the next action genuinely depends on reasoning over what just happened, in ways you can't enumerate ahead of time → tier 4, an agent.

"No planning, no reasoning, very linear" is not a smaller agent. It's a different tier — say so plainly.

The four things that must ALL be true to justify tier 4

Borrowed from the same test the Claude API docs use for "should I build an agent?" If any one is "no," drop down a tier.

1. Complexity — the task is multi-step and hard to fully specify up front (not "extract the total from this invoice").
2. Value — the outcome justifies higher cost, latency, and non-determinism.
3. Viability — the model is actually capable at this task type today.
4. Cost of error — mistakes can be caught and recovered from (tests, review, undo). High-autonomy real-world actions with no recovery are a reason to lower autonomy, not to skip the question.

Downgrade signals — if you see these, you're building an agent for a non-agent problem

• The flow is linear or has only fixed, code-decidable branches.
• There's no planning and no reasoning over intermediate results — each step's input is known before you start.
• The task is one-shot (single request → single answer).
• Errors are cheap and the task runs unattended fine without judgment.
• You reached for "agent" because it sounds more capable, not because the control flow demands it.

Any of these → name the real tier and stop climbing.

Output — and the routing decision

Write artifacts/altitude.md (apply the don't-clobber guard) with:

1. The tier you landed on (0–4) and a one-paragraph justification tied to the gate question.
2. Why not the tier above and below — one line each, so the call is auditable.
3. The routing decision (below).

If tier 4 (agent) — clear into the pipeline

State specifically what forces the agent tier (which decisions must be made at runtime, why they can't be pre-written). Then hand off to agent-brainstorm — the rest of the pipeline now applies.

If tier 0–3 (not an agent) — route out, don't march on

Say plainly that the agent pipeline is overkill for this, name the architecture that actually fits (a workflow, a single prompt, an ML model, rules), and tell the user which few parts of this framework still earn their keep rather than "use it or don't":

• Tier 2–3 (any LLM in the loop): a thin PRD (agent-prd) is still worth it to pin the task and success bar, and agent-data-and-evals still applies — even a single generative call needs an eval set to know it works and doesn't silently regress. Skip the agent-loop design, guardrails, and the rest.
• Tier 0–1 (rules / classic ML): this framework doesn't apply. Point the user at normal ML/software practice (a labeled dataset + offline metrics, or plain tests).

Either way, this gate has done its job the moment the tier is named honestly.

End by stating the tier in one sentence, the single fact that decided it, and the routing call — into agent-brainstorm (tier 4) or out to the named simpler path (tier 0–3). If you're genuinely between two tiers, present both and let the user decide; bias the recommendation toward the lower one.