The problem
Using several AI CLIs creates operational questions beyond choosing a model: which worker may read a repository, what happens after a timeout, and who accepts the result?
My contribution
- Led the orchestration requirements and choices around routing, permissions, and acceptance.
- Used AI-assisted implementation and reviewed failure paths, regression evidence, and installation behavior.
Decisions & tradeoffs
Declare routes rather than guess intent
- The choice
- Select a worker, ordered profile, or route explicitly and filter candidates by required capabilities.
- The tradeoff
- Setup takes more thought than automatic selection, but the reason for choosing a worker remains inspectable.
- How it is checked
- Schema validation and deterministic routing tests check selection and rejection paths.
Leave authentication with each CLI
- The choice
- Use reviewed adapters and provider-native login instead of storing credentials or executable commands in policy files.
- The tradeoff
- Adding a provider requires an adapter change and review; arbitrary commands are intentionally outside the configuration model.
- How it is checked
- The security contract and schema checks define the admitted configuration surface.
Treat completion as evidence to review
- The choice
- Bound execution time and output, record cleanup, and stop automatic cross-worker retries once a writer starts.
- The tradeoff
- A partial write needs inspection before another worker can continue; process success does not accept the work.
- How it is checked
- Windows regression and installer lifecycle suites exercise process handling in PowerShell 5.1 and 7.
See the work
Explore the work
Follow the boundary, not just the happy path
Synthetic flow demonstration based on the public v0.3 contract and deterministic tests. These are illustrative states, not production logs or live CLI calls.
Explicit selection
workspace.read
A named repo-review route requires workspace.read. Filter candidates by capability, preserve the declared profile order, then select an eligible worker.
Transport & execution
Worker exit · 0
A bounded work order travels through the reviewed adapter. The synthetic worker returns output with exit code 0; this establishes transport success only.
Containment & cleanup
Confirmed in this scenario
Even after successful root completion, the runner closes the contained process tree and cleans owned temporary artifacts. Cleanup remains a separate result to inspect.
Acceptance
Review required
A human or orchestrator must still inspect the output, files, diff, and task-specific checks. The worker cannot grant its own acceptance.
Real cleanup failure is reported separately and cannot trigger fallback. Timeout fallback is read-only, opt-in, and requires confirmed termination plus remaining budget. A started write worker is never automatically replaced. Read the tests ↗
What the work shows
The v0.3.0 release provides documented adapters, configuration examples, installation and removal paths, and a structured result contract. Public CI records show the Windows PowerShell 5.1 and PowerShell 7 test jobs completing successfully.
Follow the evidence
What this does not establish
- The supported execution environment is Windows; this is not a cross-platform service or a sandbox for malicious local programs.
- Provider binaries and native profiles remain trusted dependencies. MiniMax has no reviewed workspace read/write capability in v0.3.