Model-Tiered Pipeline
custom agents: Haiku scans, Opus analyzes. Pay for intelligence only where it bends the outcome.
Model-Tiered Pipeline
A workflow pattern that routes task stages through agents matched to model capability and cost, running cheap scans and expensive synthesis in sequence.
How It Works
Model-tiered pipelines combine two features: custom agent definitions (which pair a model with a specific tool set) and skill routing (which directs a skill to a particular agent). The pattern uses this to construct multi-stage flows where early stages route to cost-optimized models and later stages route to capable ones.
Define agents upfront:
cheap-scanner: Haiku model with Read/Grep/Glob tools onlysmart-analyzer: Opus model with full tool access
A skill pipeline then invokes: cheap-scanner finds candidate items → smart-analyzer analyzes findings. This distributes work: 90% of reads/scans run at Haiku cost, 10% of synthesis runs at Opus quality.
What the Test Found
The pattern was validated in runtime testing using custom agent definitions and skill routing. Results confirmed:
- Custom agents enforce model and tool constraints consistently
- Skills successfully route to specified agents
- Tool restrictions are enforced at availability level (skills cannot call unavailable tools)
- Cost benefits hold: high-volume scanning at cheap rates, focused analysis at expensive rates
No hot-reload mechanism exists for agent redefinition; agents must be defined upfront before skills invoke them.
Why It Matters
Agent-model pairing is typically a one-per-session or one-per-project choice. This pattern makes it a per-task choice. Scanning, classification, and filtering scale poorly at Opus cost; reasoning and synthesis don't benefit from cheap models. Tiering separates these concerns, pushing Haiku to scale and reserving Opus for decisions that need it.
Caveats
- Requires upfront agent definition; cannot be modified mid-session
- Tool restrictions are enforced; skills cannot exceed their agent's allowed-tools list
- Optimal tier points are task-dependent; no automatic cost tuning
- file2.1.0/WORKFLOW-IDEAS.md
workflow_2a9e5de967ca0f66c569763ded255199b87705613b1e2fd064d57fa75a6b679d2856ceafad6b1daa8f982493871b6dd86f54e33febb2c8ad85b84d32129372b9b713d2b12fbcc0e062c38228f2143dbee14bdc53a1bcb3ad748abd241dbe771acc08068b061b6d43463fce331dab907Signed 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.