AI Orchestrator
Python-based orchestration for scoped specialist agents, deterministic routines, model routing, persistent context, recorded hand-offs, and human approval gates.
What it does
Cheapest capable model first
Budget gateBlocks expensive paths
Human approvalConsequential actions
Scope
A hub-and-spoke router sends bounded work to specialist agents without giving one specialist access to another specialist’s private context
Deterministic first
Deterministic Python routines handle validation, scheduling, deduplication, state reconciliation and repeatable checks before model judgement is used
Model choice
A model router sends each task to the cheapest capable model: local models first, then lower-cost cloud routes, and frontier models only for work that needs tools, file access or harder reasoning
Budget boundary
A token budget meter gates every session: each prompt is stamped with current spend, and expensive paths are blocked when the budget runs low
- Persistent context is separated by project and specialist rather than merged into one global memory
- Recorded request and reply hand-offs preserve provenance and make the routing path auditable
- Per-project knowledge graphs, so agents query the structure of a codebase instead of re-reading files
- Scheduled jobs handle bounded monitoring and preparation; the system reports exceptions rather than generating activity for its own sake
- Chat interfaces expose an approval queue: the system proposes and prepares, while consequential actions remain human decisions
- Tool access through MCP (Model Context Protocol) integrations: calendar, mail, file storage, and design tools
Background
I run several engineering and creative projects from one workspace, and I wanted more than one general assistant trying to remember everything. I built a hub-and-spoke orchestration layer in Python: specialist agents work inside isolated scopes, deterministic routines handle repeatable operations and verification, and a central coordination layer controls what context and authority move between them.
The design constraints are cost, context separation and control. Frontier models are capable but expensive; local and lower-cost models are useful but limited; and an agent with broad context can cross boundaries that should remain separate. The interesting engineering is therefore in the routing, verification and authority model, not in any single model.
Limitations
- Single machine, single user; it is a personal system, not a product
- The free cloud tiers it leans on change their limits regularly, so the router needs occasional retuning
- The system is a personal control plane rather than a formally certified policy engine; consequential actions still require human approval
The repository is private because the system operates my real accounts and files.
What I learned
Most day-to-day tasks do not need a frontier model. The more important lesson is that agent reliability comes from system design rather than model size: narrow scopes, deterministic checks, recorded hand-offs, current state on disk, hard budgets and human approval at consequential boundaries.