Orchestration | Jivoo
Orchestration decides how work runs.
Six stations, a named person deciding at each one, three model tiers and a task-to-tier rule that keeps most work on the cheapest model that does it well. It is a design, not a framework choice.
The six stations.
At each station an agent drafts and a person decides. What leaves a station is the artefact the next one builds on, and the thing the evidence record cites.
Six stations, the named decision at each, and what leaves. Knowledge, guardrails and the thread run under all six.
| Station | The agent drafts | Default tier | A person decides | What leaves |
|---|---|---|---|---|
| 1 Plan | A story with Given/When/Then criteria, a data class and a region tag | Tier 2, Tier 1 for tagging | The product owner approves the story | An approved work item and its ID |
| 2 Design | A decision record with options and trade-offs | Tier 3 | The architect chooses the option | A decision record linked to the work item |
| 3 Build | Code and unit tests, built and run locally | Tier 2, Tier 1 for search | The engineer reviews the diff and opens the pull request | A pull request linked to the work item |
| 4 Verify | Integration and end-to-end tests, and a first-pass review | Tier 2 | QA and a named reviewer approve | A merged change with passing tests and scans |
| 5 Release | Infrastructure as code and release notes | Tier 2, Tier 1 for notes | A named approver releases | A production release linked to its pull requests |
| 6 Operate | Incident summaries and evidence packs | Tier 1, Tier 3 for root cause | Security and delivery sign off | Audit-ready evidence |
The six stations of a software factory, with the draft, the default tier, the decision and what leaves the station.
Matching models to the work.
Most tokens go on work a small model does just as well: summaries, search, tagging, commit messages. The tier is what the factory refers to, so a model can be swapped without changing how anyone works.
A task starts on the smallest approved model that does it well. Escalation is a decision with a reason.
Fast.
Tier 1
Summarise, classify and tag, extract fields, search code, write commit and release notes, fix lint. Low effort, thinking off where the model allows it.
Escalate when the output fails its check, or the change spans files.
Standard.
Tier 2
Code and unit tests from a story, integration and end-to-end tests, first-pass review, infrastructure from an approved pattern. Medium effort, high across several files.
Escalate after two failed attempts at the same check.
Deep.
Tier 3
Decision records and trade-offs, security and threat review, root cause of a hard incident, large refactors. High effort.
A person decides when to go up. Tier 3 is the ceiling and never the default.
How a task finds its tier.
- Automated work points at one gateway, so routing and logging are the same whichever runtime is used.
- The task class sets the default tier and effort; the gateway applies both when the caller does not.
- Use the runtime's own split where it has one: plan on Tier 2 or 3, act on Tier 2, search on Tier 1.
- Escalation is deliberate and visible: retry one effort level higher, then move up a tier, and the evidence record shows both.
Rules that cut token use.
- One task per session; summarise a long session instead of carrying it.
- Point the agent at the files that matter, not the whole repository.
- Load only the tool connectors a role needs.
- Keep the canonical rule file short, and put detail in guides that load only when needed.
- Ask for a diff and a short answer, not a whole file.
- Never paste logs, query results or data dumps: query them through a connector with filters, which also keeps data out of the model's context.
Orchestration without a harness is a faster way to break things.
What bounds the machine, and what it must prove, is the other half of the design.