← Atlas Class

Capability Tiering

Model and tools differentiated by agent role. Forced by the cost of inference: you pay for intelligence only where it bends the outcome.

Capability tiering is the practice of assigning different models and tool sets to different agent roles within a multi-agent system, forced by the economic cost of inference rather than by architectural preference.

Forced-by constraint

Inference cost scales with model size. Running a frontier model on every subtask in an agent pipeline is economically unviable at production throughput. Capability tiering is the structural response: match model capability to task complexity, and restrict expensive models to roles where their reasoning ceiling is actually needed. The constraint is not optional -- it is imposed by the unit economics of token-based billing.

Members of the class

Changelog-derived evidence places three tiers in active use in this system:

  • Haiku-class workers -- high-volume, low-complexity subtasks; pushed hard for token efficiency.
  • Sonnet-class workers -- mid-complexity synthesis and execution tasks; the default workhorse tier.
  • Opus-class synthesis -- reserved for final synthesis, adjudication, or decisions where reasoning depth is the bottleneck.

Tool access follows the same gradient. Workers in lower tiers receive narrower tool sets matched to their defined scope; senior tiers receive broader authority. This pairing of model tier with tool tier is the defining feature of capability tiering as a primitive class.

Why it matters

Tiering is not merely cost optimisation. It enforces accountability boundaries: a worker operating below its capability ceiling cannot accidentally make decisions that belong to a higher tier. It also makes orchestration legible -- the tier of a delegate signals its expected scope before any output arrives. Agent fields are described as instances of this primitive, meaning a deployed agent field concretises the abstract tiering policy into specific model assignments and tool grants for each role.

Caveats

This article is changelog-derived and has not been runtime-verified. The tier labels (Haiku, Sonnet, Opus) reflect a specific provider's model family and may not generalise across providers. The assignment of tools to tiers is asserted as a pattern, not as a measured outcome. Whether tiering produces the intended accountability boundaries in practice -- or whether cost savings are offset by coordination overhead at tier boundaries -- remains untested in this record.

Members 1 across 1 version
Evidence & receipt
  • fileAGENTIC-ESCALATION-ARC.md
◇ ed25519 receipt
idprimitive-class_e87fbb5cc510b34a605be0c8
alged25519
pubkey9b87705613b1e2fd064d57fa75a6b679d2856ceafad6b1daa8f982493871b6dd
sigbfd7ab90aeb970e1a676b1f82bfd354c0540b56a3ee7c71ac994cee807a2ebd4a51315d3925c3b437cf652399b5c5d0651e50842090d36a9c3127fa390198005

Signed with an ed25519 key held off the repo. Anyone can verify against the published public key; nobody without the secret key can forge it. Click verify: it recomputes the signature in your browser. The signature proves integrity and authorship of this exact content — not a third-party timestamp or that the underlying claim is objectively true. signedAt is when the @f3/attest pipeline ran, not when the work happened; the evidence refs carry the source dates.