Plan With the Expensive Model, Execute With the Cheap One

Once you have more than one agent working on a codebase, you have an organizational problem, not a prompting problem. Who decides the design? Who is allowed to touch main? What happens when two workers edit the same file? Who reviews, and does it mean anything if the reviewer is the same model that wrote the code?

Tiknix answers these explicitly in AGENT_ORCHESTRATION.md, and the answers are deliberately scaled to reality: a handful of subtasks per plan, three concurrent workers, one instance. Not a thousand-agent swarm. The rules below are worth reading even if you never run the pipeline, because they generalize.

The pipeline

Three stages, three distinct roles: PlanRunner → PlanExecutor → AuditRunner.

1. The planner owns design. Full stop.

The planner is the only agent permitted to make architectural decisions. It runs on a frontier model, it is grounded on the reuse inventory (see Give Your AI Assistant a Map), and it must classify every capability as REUSE, EXTEND, or NEW before proposing any work.

It then decomposes the work into subtasks, each carrying:

• files — what it will touch
• reuses — which existing primitives it builds on
• depends_on — which subtasks must land first
• engine — which agent should execute it

2. Workers implement the spec. They do not redesign it.

A subtask description is a spec, not a suggestion. Workers implement it; they do not re-decide architecture. If a worker finds the spec wrong, it stops and reports — it does not redesign.

This constraint is the load-bearing one. A worker that improvises produces code that is locally reasonable and globally incoherent — three subtasks each solving the same problem three compatible-looking, incompatible ways. Stopping and reporting is cheap; silent divergence is expensive and invisible until integration.

The corollary is a diagnostic rule most teams could adopt directly:

Spec clarity is the bottleneck, not execution. A subtask a cheap model can't execute without a judgement call is an under-specified subtask — fix the plan, not the worker.

That reframes worker failure as a planning defect. It is usually true, and it points the fix at the place that also improves the next twenty tasks.

3. The auditor reviews with a different model. Deliberately.

AuditRunner drives the running site with Playwright as ROOT, ADMIN, and MEMBER, captures screenshots, and writes audit.json. And it carries a hard rule:

The review model MUST differ from the worker model. Same-model review catches correlated errors poorly.

This is the single most transferable idea in the document. A model reviewing its own output shares its blind spots — it will confidently approve the specific mistakes it is prone to making. Decorrelation is what makes review informative rather than ceremonial. The minimum is a different tier (workers on a mid model, auditor on a frontier one); the ideal is a different engine entirely.

Frontier plans, cheap executes

The cost model is explicit and, in the codebase's own framing, borrowed from measurements rather than intuition: roughly 8× cost difference at equal quality between running everything on a frontier model and splitting planning from execution.

So Tiknix tiers per engine — planner_model, worker_model, auditor_model, resolver_model — declared in a registry (conf/aibuilder.ini + lib/EngineRegistry.php) rather than hardcoded. Planning defaults to a frontier tier but is selectable. Mechanical edits go to cheaper engines. Members can override tiers for their own runs.

The escalation rule is bounded:

A task that fails auto-retry on a cheap engine may be re-queued once on a higher tier before it is marked failed.

One retry at a higher tier. Not infinite escalation — that is how a cost lever quietly becomes a cost sink.

Coordination beats throughput

Concurrency is capped at three. Not because more is technically impossible, but because merge quality degrades faster than throughput improves. The supporting rules:

• Workers never run git. The orchestrator commits and merges. One writer to history.
• File-overlapping tasks must be chained via depends_on. Two agents editing one file concurrently is a conflict you chose to create.
• The megafile rule: the planner flags any task touching a file over ~2k lines and either splits the work or serializes every task that touches it.
• Only the plan may declare intentional breakage — "this task breaks X until task Y lands" is a planning decision recorded in the task, never a worker's improvisation.

Conflicts go to a neutral third party

When branches do collide, neither author resolves it. A fresh agent — new session, no history with either side, running on a different model tier — gets a resolution-only brief: keep both intents, commit the merge, change nothing else.

The reasoning is the same as the review rule. An author resolving a conflict against their own branch is not a neutral party; they will preserve their intent and quietly discard the other.

What they deliberately did not build

This section of the document may be the most valuable, because restraint rarely gets written down:

• No custom version control. Systems built for hundred-agent swarms solve a problem that does not exist at three concurrent workers. Git worktrees plus orchestrator merges are correct at this scale — building beyond that is named as an over-engineering trap, to revisit only if concurrency grows tenfold.
• No planner hierarchy. Planners spawning planners is the wrong depth for a handful of subtasks. One planner per plan.

Knowing which sophisticated thing not to build is a design skill. Both decisions are recorded with the condition that would reverse them, which is what makes them decisions rather than assumptions.

Run N+1 learns from run N

Codify surprises: when an audit failure or a repeated auto-retry reveals a convention gap, the fix lands in CLAUDE.md or the brief builders — not in a one-off prompt.

Every agent gets the same field guide: the project conventions, the MCP reuse tools, and a deterministic expansion of the planner's reuses into exact routes, columns, and method names. When something goes wrong, the correction goes into the guide, so it applies to every future run rather than to one conversation that ends.

That is the difference between prompting and engineering. A one-off prompt fix helps the current task. A guide fix compounds.