Skip to content
Kiberon LabsAgentic Engineering Ebook

Model Usage

Model choice is a per-role and per-task decision, not a global one. The three roles in the delivery loop demand different model profiles, and selecting deliberately for each is one of the cheapest quality levers available. The single-agent fundamentals (default to frontier, downgrade only with evidence, stay within a model family where possible) are covered in Working With Models; this chapter is about deploying those rules across a pipeline.

The three roles

Section titled “The three roles”

There are primarily three roles in the SDLC, each with a distinct model profile:

  1. Planning. Requires slow, careful reasoning, strategic questioning, and constraint analysis. A reasoning-first model run with a deliberate posture (see Planning & Execution). This is where spending more on a stronger model pays back most, because a wrong plan is the most expensive error to discover late.

  2. Implementation. Requires code fluency, fast generation, and reliable tool use. A coding-first model paired with a strong Agent-Computer Interface. Model selection here may also depend on information-leak risk: open models served through shared providers (OpenRouter, for example) are inappropriate for sensitive code when full in-house sandboxing is unavailable; route that work to self-hosted or Bedrock.

  3. Validation. Requires strict instruction following and an adversarial posture. Use a different model from the implementer to avoid shared blind spots and model self-bias; a validator that shares the implementer’s failure modes will bless the implementer’s mistakes (see Verification & the Outer Loop).

Routing heuristics

Section titled “Routing heuristics”

Two empirical findings should shape model selection:

  • Upgrade the model before you buy more tokens. On hard tasks, token usage explains most performance variance, but moving to a stronger model is a larger gain than doubling the token budget on a weaker one. For hard work, buy capability; for easy work, cap tokens hard and use a cheaper model.
  • Multi-agent fan-out costs roughly 15 times a single agent in tokens. Reserve true parallel fan-out for provably breadth-first work (see Coordination Model); do not pay the multiplier for tasks a single agent handles.

A third, less obvious: iterations are part of the price. A cheaper model that needs twenty attempts can cost more than a stronger model that needs five, in tokens and in wall-clock both. Cost per successful outcome, the metric the Evaluation Harness tracks, is the number routing should optimise, not cost per call.

Multi-model architectures

Section titled “Multi-model architectures”

When one model per role stops being enough, the field’s catalogue of multi-model shapes is worth knowing. In rough order of adoption:

  • Cascade with a quality gate. A cheap model attempts first; a deterministic gate (schema validation, confidence threshold, tests) decides whether to accept or escalate to a stronger model. The bulk of routine work resolves at the cheap tier, and the gate, not the cheap model’s self-report, decides. Never ask the cheap model whether it succeeded; that is verification doctrine applied to routing.
  • Orchestrator and specialists. An expensive model decomposes; cheap specialists execute in parallel; the strong model synthesises. This is the shape of Ikidna’s own pipeline stages, and its handoffs work only when the intermediate representation is structured (a plan artifact with explicit steps and dependencies), never free prose. The plan artifact is exactly this interface.
  • The advisor inversion. A small model executes the whole task end-to-end and consults an expensive model only at decision points, with a hard cap on advisor calls. Published results (Anthropic’s advisor-strategy work, as reported via the sources in Prior Art) found small-plus-advisor beating mid-tier models solo at a fraction of the cost. Worth evaluating wherever the work is execution-heavy but occasionally judgment-hard.

Adopt in that order, and only on evidence: a single frontier model is the right architecture until measured spend, quality variance, or queue latency says otherwise. The migration trigger is a number from the eval harness, not a sense that the system should be fancier.

Concrete selection (complexity classification from Ticket Enrichment, domain sensitivity, budget envelope, and confidence) is the job of Smart Routing.

Section titled “Related chapters”