AI Orchestrator

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.

What it does

• A hub-and-spoke router sends bounded work to specialist agents without giving one specialist access to another specialist’s private context
• Deterministic Python routines handle validation, scheduling, deduplication, state reconciliation and repeatable checks before model judgement is used
• 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
• 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

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.