// engineering The six stages, and where each stands
The AOA is not a big prompt. It's a six-stage pipeline, each with input, output, and
stop criterion. Below, what runs today — and what is still partial, stated plainly.
| stage | what it does | how | status |
|---|
| S1 Decompose | Breaks intent into subtasks with declared dependencies | directed graph + topological sort (Kahn) | in production |
| S2 Assign | Matches each subtask to the craft specialist | type → specialist map, with Manager as default | in production |
| S3 Route | Chooses capacity tier by benchmark score | threshold by task type, calibrated in the bench | in production |
| S4 Review | Quality gate with automatic escalation | max 2 cycles per tier, then escalates | in production |
| S5 Publish | Assembles the result and deploys with prior backup | syntax validation before deploy | in production |
| S6 Learn | Logs verdict per task and recalibrates thresholds | learning log + bench recalibration | partial |
How complexity is estimated
Before routing, the AOA needs a number. It comes from a base weight by subtask type,
plus modifiers when the request is more demanding. No "the model decides" — it's auditable
arithmetic. But the simplicity is apparent: calculating the score is the visible tip of a
loop that recalibrates with every verdict.
base weight by type publish 15
review 20
research 25
copy 30
image 40
design 45
SEO 50
video 50
GEO 55
code 65
modifiers - +10objective > 200 characters
- +10more than one modality in the same task
- +15technical domain declared
- +10quality requirement above 85
The score is capped at 100. A code subtask in a technical domain with high quality
requirements hits 90 and lands in Titan; the same publish task stays at 15 and never
leaves Cronos.
Why it's not that simple. These modifiers aren't arbitrary constants — they're
parameters calibrated by stage S6 (learning). Every time a node passes the quality gate and
receives APPROVE or REJECT, the system logs: calculated score,
executing tier, final verdict. When a modifier systematically overestimates or underestimates
real complexity, the weight is adjusted. The loop closes: today's estimated complexity is the
child of yesterday's verdicts.
The thresholds that decide the tier
Below the number, the tier handles it. The values aren't guesses: they come from the benchmark,
measured by task type, and change when the measurement changes.
| task type | Cronos up to | Cronos+ up to | Analysis up to | beyond |
|---|
| Copy & writing | 40 | 60 | 80 | Titan |
| Code & build | 45 | 65 | 85 | Titan |
| Technical SEO | 50 | 70 | 85 | Titan |
| GEO & citability | 45 | 65 | 85 | Titan |
Code demands less to escalate than copy because a wrong function breaks; a mediocre paragraph
only disappoints. The threshold carries that judgment, and that's why it's per-type and not
global. These thresholds aren't fixed walls — they're moving boundaries.
Stage S6 recalibrates: if a tier starts taking REJECT on nodes that used to pass,
the threshold rises. If it takes consistent APPROVE near the ceiling, the
threshold drops. The hard cost cap prevents the learning loop from converging on "always
use the most expensive tier."
