A bounded task tells a coding agent what to do. But before that task exists, someone must clarify the product, compare technical choices, and turn the work into a sequence that does not collapse under its own ambition. That is where model hierarchy matters.

The idea is simple: assign models different roles based on the consequence and difficulty of the decision. Use the strongest judgment where a wrong answer multiplies downstream; use faster, cheaper models for narrow, well-specified jobs; and use an independent model to check the result.

What "frontier reasoning" means here

A frontier reasoning/coding model is one of the strongest available models for hard reasoning, unfamiliar codebases, architecture tradeoffs, or security-sensitive decisions. This lesson deliberately names no brand and no leaderboard. Models change every few months; any fixed ranking would be stale before you finish the project. When you need current prices and options for a routing decision, compare them live — for example the catalog at OpenRouter — and run candidates through a routing layer such as OpenCode with the same bounded task and acceptance checks.

The durable rule: use the strongest *demonstrated* judgment for decisions that shape everything downstream — product scope, architecture, difficult bugs, ambiguous plans — and prove the choice with real tasks on your project rather than a logo or a price tag.

The development spine

The part's end-to-end workflow is the spine every feature travels:

Idea and user problem
  → product definition conversation
  → PRD.md
  → architecture and technology-stack decision
  → ROADMAP.md
  → one small scoped task
  → implementation
  → validation and risk-based review
  → checkpoint/version history
  → next task

A PRD (Product Requirements Document) is the durable description of the problem, the user, the requirements, the constraints, and the acceptance criteria. A roadmap is the sequenced list of small phases, dependencies, validation steps, and progress markers. Each exists so the project remembers *why* long after any single chat is gone.

Each stage has a human owner, a best AI role, and a durable artifact:

No single AI should make every decision alone. The planner that shaped the scope should not be the sole judge of its own implementation.

Concrete routing: the research dashboard

Make it tangible with the research dashboard — pick a company, gather approved sources, produce a source-linked brief. A top-tier reasoning model drafts the PRD: user jobs, source rules, private-data boundaries, acceptance criteria. The same class of model compares architectures — simple server-rendered app versus scheduled background pipeline — with cost, freshness, and complexity stated. A coding model implements one feature ("display source date"); a low-cost model drafts three headline variants; a separate reviewer inspects the diff for broken access control or unrelated edits.

Each handoff is a file, not a memory: PRD to architecture note to roadmap to task to diff to validation record.

Cheap does not mean inferior

This hierarchy is not a pyramid where the expensive model is better at everything. A cheaper model can be excellent at a narrow, well-specified job: copy variants, structured extraction, test-case phrasings. The frontier model earns its cost where being wrong is expensive: scope, architecture, security-sensitive design, stubborn bugs, ambiguous plans.

Least-context routing and privacy

Powerful orchestration creates a privacy obligation. Do not automatically send every model the full repository, customer records, private documents, .env files, API keys, production logs, or authenticated browser sessions.

Give the copy model approved product notes, not a production database export. Give the reviewer the relevant diff and sanitized fixtures when that is enough. Give the coding model only the folders and credentials its bounded task requires. A parallel worker is not entitled to the full project simply because it is helping the project.

Model choice includes the provider and data boundary, not just quality, cost, and speed. Before sending sensitive code anywhere, check the provider's current data-handling terms — the privacy habit from Part IV and the secrets discipline from Parts II and V.

Privacy checklist for every routing decision:

• What information does this job actually require?
• Can identifiers or records be replaced with fixtures or redacted samples?
• Does the worker need read access, write access, or no system access at all?
• Where will its prompt and output be retained, and for how long?
• Is this provider and model approved for this category of information?

If you cannot answer those, shrink the context before you send anything.

The routing checklist

For each job, ask five questions:

1. How expensive is being wrong here? 2. Is this an open-ended decision, or a narrow mechanical task? 3. Does the model need deep project context, broad reasoning, or just a clean input/output contract? 4. Can a second model independently check the result? 5. What does the result cost in tokens, time, API spend, and human correction?

High cost of error plus open-ended reasoning points to frontier judgment. Anything involving auth, money, private data, or infrastructure always gets the stronger review regardless of where it was built.

Turn hierarchy into CLI sessions

Separate terminal sessions from Lesson 36.1 make the hierarchy visible. Give each a named job, a short Markdown brief, only the access it needs, and one artifact: planner produces the next TASK.md; implementer returns code plus a changed-file summary and evidence; copy-editor returns reviewed copy; test-runner returns test output; reviewer (read-only) returns ranked findings with file:line cites.

No session silently inherits another's swollen conversation. You review the handoffs and control the sequence. That orchestration is often more valuable than any single model's cleverness.

Review effort follows risk

Not every change deserves the same scrutiny. Use this risk-based review policy:

The hierarchy makes development faster: costly reasoning and human attention go to decisions that multiply downstream, while routine bounded work moves quickly with cheaper models and clear checks.

Exercise: write MODEL-ROUTING.md

For one project, list its next five jobs in a MODEL-ROUTING.md. For each record: task, risk level, model role, allowed inputs, output artifact, evidence required, approver. Example: "Display source date — Medium — coding model — TASK.md + citation folder only — preview with dated/undated sources — builder approves after reviewer findings cleared."

Check your understanding

• When is a frontier model worth its cost, and when is a cheaper model better?
• What does least-context routing require you to withhold, and why?

Finish line

You are done when you have a MODEL-ROUTING.md plus pointers to PRD.md, ARCHITECTURE.md, ROADMAP.md, and the first TASK.md — one idea to an approved first phase without asking one AI to decide everything alone.

Verify: trace one feature from idea to task across your documents. Every handoff should name its artifact and approver.

Common failure mode: routing everything to the most famous model with the full repository attached "so it has context." Cost climbs, sensitive data spreads, and no independent eye ever sees the work. Recovery: reassign two jobs to narrower models with minimal context and add the independent reviewer.

Next, you will run several of these roles at once: parallel workspaces with branches, boundaries, and one integration owner — so agents stop colliding.