Orbit — AI Operations OS

# Orbit — AI Operations OS **Project Brief** --- ## What it is A multi-tenant AI operations platform for small service businesses (clinics, law firms, agencies, MSPs). A business connects its phone line, inbox, ticket queue, CRM, calendar and document vault — and a supervisor-orchestrated agent mesh runs the entire front office from a single shared memory. Every AI action is confidence-scored, citation-backed, cost-tracked, and routed through a human approval queue. --- ## The core idea AI systems fail in production not because the model is weak, but because nobody can see what the system did and correcting it is expensive. Orbit's answer is a **trust layer**. High-confidence actions execute autonomously. Low-confidence actions land in a human approval queue. Every human correction becomes a labeled example that feeds an eval harness, so changes are measured rather than guessed. --- ## The six agents | Agent | Does | |---|---| | **Reception** | Answers inbound calls, checks live calendar, books and reschedules, sends SMS confirmations | | **Triage** | Classifies tickets by intent and urgency, retrieves past resolutions, drafts grounded replies | | **Docs** | Flags risky contract clauses in plain English, compares third-party paper against the tenant's playbook | | **Growth** | Qualifies leads against an ICP rubric, enriches, writes personalized outreach, updates CRM | | **Knowledge** | Internal RAG copilot — staff ask questions, get cited answers from documents, tickets and transcripts | | **Migration** | One-time onboarding agent that ingests the tenant's prior system so the platform is useful on day one | A LangGraph supervisor routes every inbound event to the right agent, holds workflow state, and enforces that nothing commits a side effect without a score. All agents share one **MCP tool server** — CRM writes, calendar operations, email, SMS, and DB queries defined once with strict schemas and per-tenant credential scoping. Adding a seventh agent costs zero new integration work. --- ## Why it's one product, not six tools A call handled by Reception creates a ticket in Triage, which cites a clause surfaced by Docs, which updates the CRM through the shared tool layer — all against the same tenant's memory. The integration between modules is the value. --- ## Stack **Backend:** FastAPI (core API and orchestration), Django (admin plane, RBAC, billing), Flask (isolated ML inference service) **Agents:** LangGraph, LangChain, MCP **Data:** PostgreSQL + pgvector, MongoDB (traces and transcripts) **Frontend:** React dashboard, Node/Express BFF **Voice:** Twilio + Retell AI **Automation:** n8n / Make.com for tenant-configurable workflows **Models:** OpenAI + Gemini APIs, Hugging Face locally for embeddings, PII redaction and classification **Infra:** Docker, AWS CodePipeline A **model router** sends each task to the cheapest model that can handle it — small models for classification, frontier models for reasoning, local models for embeddings — with every routing decision logged, making cost per resolved ticket a visible metric. --- ## The dashboard Live agent activity feed · human approval queue · per-agent accuracy over time · token spend and cost per tenant · trace viewer that replays any decision step by step. --- ## Build order 1. Tenant core, auth, document ingest, Knowledge agent 2. MCP tool server and integrations 3. Triage agent, confidence scoring, approval queue, trace viewer 4. Voice module 5. Docs and Growth agents 6. Eval harness, cost dashboard, CI/CD, Migration agent Phases 1–3 are a complete, sellable product on their own. Building all six before showing anyone is the main risk to the project.