Decision Framework · Production Patterns
How to route tasks to the right model. How to structure sub-agent trees that don't collapse under their own weight. The decision framework, production patterns, and anti-patterns that separate reliable hybrid agents from expensive toys.
Model Routing
Every model has a profile: cost efficiency, acceptance reliability, taste, and throughput. The hybrid approach routes each task to the model that can meet its acceptance criteria at the lowest cost. Here is the baseline routing matrix — recalibrate as pricing and model behaviour change.
| Model | Cost Efficiency | Reliability | Taste | Throughput | Best Role |
|---|---|---|---|---|---|
| DeepSeek-v4-pro / Fable-5 | 3 | 10 | 10 | 4 | Orchestration & final arbitration |
| Opus | 5 | 8 | 9 | 6 | Architecture & tasteful senior review |
| DeepSeek-chat / Sonnet | 8 | 6 | 7 | 9 | Mechanical execution & verification |
| Codex (when available) | Varies | 9 | 8 | 7 | Independent peer engineering review |
The matrix is a default map, not a ceiling. Upgrade only when a cheaper model misses a specific acceptance criterion, or when the task is high-stakes enough that a weaker pass would be false economy. Spend expensive tokens on judgment, not bulk context gathering.
The most common failure mode is using an expensive orchestrator model for mechanical work. The orchestrator should delegate, not do. Every time Fable-5 or v4-pro writes a boilerplate function or runs a grep, it is burning premium tokens on work that a model one-tenth the cost could handle. Keep the orchestration context lean.
Decision Framework
Veles and Veles Forge are complementary architectures, not competitors. The choice depends on the task profile. Here is the decision framework for production use.
You need the system to remember decisions, data sources, and design constraints across multiple sessions. The project spans days or weeks. Memory is not optional — it is the difference between re-discovering the same facts on every run and building on accumulated knowledge.
Use VelesYou want a formal design document reviewed and revised before any code is touched. The task benefits from the Plan → Design → Implement → Review structure with explicit review-revise loops. Stateless execution is acceptable — each run is independent.
Use Veles ForgeThe task involves design decisions, brand judgment, and multi-skill orchestration (accessibility, performance, design system). A single model cannot handle the full pipeline. You need the Reasonix + Veles combination: Reasonix for creative direction and skill pipelines, Veles for code review and verification.
Use Both — Reasonix builds, Veles reviewsYou need to define custom agents, personas, and skills as configuration files. The team needs to add agents without touching orchestration code. File-based configuration (markdown + TOML) is the primary extensibility mechanism. You want MIT-licensed open source.
Use Veles ForgeProduction Pattern
For high-stakes work, run two independent reasoning passes in parallel — Opus for taste and architecture, Codex for independent engineering perspective — without sharing either answer with the other. The orchestrator (Fable-5 or v4-pro) synthesises the outputs, makes the final call, and delegates execution to the cheapest model that can meet the acceptance criteria. The verifier audits everything before it ships.
Production Patterns
The canonical hybrid agent flow. Every production deployment of Veles and Veles Forge follows this pattern. It is simple enough to audit and robust enough to ship.
The orchestrator never sends raw context. Every delegation is a design packet: goal, constraints, owned paths, invariants, acceptance criteria, and verification commands. Sub-agents receive only what they need.
The verifier has no stake in the implementation. It runs tests, checks evidence, and returns PASS/FAIL with line references. It is structurally incapable of rubber-stamping. Its only loyalty is to correctness.
Never delegate bulk work to a fork of the orchestrator. Forks inherit expensive context. Spawn fresh-context workers (Sonnet or DeepSeek-chat) for mechanical execution. The orchestrator keeps only compact evidence packets.
“The orchestrator decides. The executor builds. The verifier audits. They are never the same model. This separation is not a design preference — it is the structural guarantee that makes autonomous software engineering defensible in production.”
The Hybrid Architecture Principle
Anti-Patterns
These are the failure modes observed across production deployments. Every one of them has caused a real project to underperform. Avoiding them is not theoretical — it is operational.
Using one model for orchestration, implementation, and verification. It is like a surgeon who operates, administers anaesthesia, and audits their own outcomes. Conflicts of interest are structural, not personal. The model cannot effectively review its own output.
Using Fable-5 or v4-pro to write boilerplate, run grep, or format code. Every mechanical action burns premium tokens. The orchestrator should delegate, not do. Every time it touches a file directly, it is a routing failure.
Spawning a fork of the orchestrator to handle a sub-task. Forks inherit expensive context, so the intended cheap worker runs at orchestrator prices. Spawn a fresh-context Sonnet or DeepSeek-chat worker instead.
Deciding a change is too small to warrant verification. Small changes cause big failures — a one-line config change, a missing import, a typo in a path. The verifier costs seconds and catches what human judgment misses. Never skip it.
Letting an orchestrator run without a deterministic stop condition, maximum attempts, or budget. It will iterate until it hits a context limit or a rate limit. Every autonomous run needs: completion criteria, max attempts, and a report shape.
Defaulting to maximum reasoning effort for every task. Most tasks do not need it. Start at high effort; escalate to maximum only when the risk or evidence warrants it. Maximum effort burns budget without necessarily improving outcomes.
These anti-patterns are not hypothetical. They have been observed across production deployments of both Veles and Veles Forge. The fix in every case is the same: separate concerns, route tasks to the cheapest model that can meet the acceptance criteria, and never skip the verifier. The architecture is sound — the failure modes are operational.