Delegation
Zimster starts by deciding whether another agent would improve the work. The availability of a cheaper model is not, by itself, a reason to delegate.
Good delegation boundaries are narrow, useful, and easy for the implementation owner to check.
Model routing
Once a task has already been selected for delegation, Zimster can inherit the current model, use a configured mapping, or propose a model for that bounded job.
- Inheritance: keep the parent model.
- Mapping: use a configured model for a known task type.
- Proposal: ask Zimster to suggest a suitable model without hard-coding the answer.
Correction and review limits
Automatic corrections and review rechecks need boundaries. Zimster records the budget for those loops and stops clearly when the allowed capacity is exhausted.
The limits are there to keep a run from circling indefinitely, not to block an ordinary local fix that still fits inside the approved budget.
Local records
Evidence receipts, review packages, snapshots, and related run records stay local to the repository by default.
Those files help answer practical questions later: what was run, what was reviewed, which head the evidence belongs to, and why a completion state was or was not allowed.