Chief OS is an MCP server, built on the NitroStack SDK, that looks at an incoming email, meeting request, or task and decides which specialized module should handle it, then holds any consequential action behind a human approval step before it runs.
What this enables
- Routes email, meeting, and task requests to purpose-built MCP modules instead of one generic assistant.
- Returns a recommended agent, priority level, and confidence score for every routed request.
- Extracts action items and categories directly from email content.
- Keeps scheduling changes and other consequential actions behind an explicit approval workflow.
- Logs every action and approval decision to a separate audit trail module.
The problem with one assistant doing everything
Most inboxes, calendars, and task lists are managed the same way today: a person switches between three or four separate tools, decides what matters, and manually acts on it. Handing all of that to a single AI assistant creates a different problem. An assistant that can both read a calendar and reschedule a meeting, both draft a task and mark it complete, ends up mixing judgment and execution in one place, which makes it harder to trust and harder to audit later.
Chief OS treats each domain as its own concern instead. Email triage, meeting scheduling, task management, approvals, and audit logging are five separate modules, each with its own tools and its own schema. A request still needs somewhere to land first, which is where the routing layer comes in.
Why MCP is a reasonable boundary here
MCP lets each domain expose a small, typed set of actions instead of one broad natural-language assistant. The email module only knows how to analyze, categorize, and extract action items from email. The meeting module only knows about slots, attendees, and rescheduling. That separation matters once a request needs to move from "here is some information" to "take this action," because the tool boundary is also where a permission boundary can sit.
Inside the build
The repository organizes the server around five NitroStack modules, registered through a single @Module declaration in app.module.ts:
- Email Triage exposes
analyze_email,categorize_emails, andextract_action_items, and flags high-priority messages for approval. - Meeting Scheduler exposes
find_available_slots,schedule_meeting,get_calendar_summary, andreschedule_meeting. - Task Manager exposes
create_task,triage_tasks,update_task_status, andget_task_summary, with priority levels from critical to low. - Audit Log exposes
log_action,log_approval,get_audit_trail,get_approval_history, andgenerate_audit_report. - Approval Workflow exposes
request_approval,get_pending_approvals,approve_request,get_approval_status, andescalate_approval.
Sitting in front of those five modules is a routing tool, demonstrated in the project's walkthrough as chief_route_work. It takes a work item ID, a work type, a title, and a description, and returns which specialist should handle it, an assigned priority, an estimated confidence score, and a suggested next action. The tool itself does not touch a calendar, an inbox, or a task list. It only classifies and recommends, which keeps the decision about what to do separate from the modules that actually do it.
Each tool response maps to one of six widgets: a dashboard overview, plus dedicated views for email triage, meeting review, task lists, the audit trail, and pending approvals. The data flow follows the same shape every time: a request reaches an MCP tool, the tool validates and processes it, the action is written to the audit log, and the response carries a widget route back to the client for rendering.
Where NitroStack fits
The NitroStack SDK's module system is what makes five independently maintained domains behave like one coherent server. Each module owns its own tools, resources, and prompts, and Zod schemas enforce the shape of every request before it reaches business logic. That structure is also what makes the audit and approval modules reusable across domains: a write action in the email module and a write action in the meeting module can both route through the same approval and logging tools instead of each module inventing its own permission check.
For deployment, the MCP server runs on NitroCloud while the Next.js dashboard is hosted separately on Vercel. That split means the conversational and tool-execution layer can scale and redeploy independently of the interface that renders the widgets, which is a reasonable default once a server is meant to serve more than one client.
The interesting part is the separation, not the AI
The more useful design decision in Chief OS is not that an AI reads an email. It is that classification, execution, approval, and audit are four different concerns living in four different modules. A router recommends. A domain module can act. An approval module decides whether a given action is allowed to proceed. An audit module records what happened regardless of the outcome. None of those responsibilities are duplicated across modules, which is what keeps five independently built domains from turning into one tangled agent.
What the build demonstrates, and what it does not yet
Chief OS demonstrates a working routing and approval architecture on top of five real MCP modules, each backed by typed tools and its own widget. What it does not yet demonstrate is live production use. The project's own roadmap lists database persistence, and integration with real email providers like Gmail or Outlook and calendar systems like Google Calendar, as future work. Today, the workflow logic, the module boundaries, and the approval and audit path are real and testable. Connecting them to a live inbox and calendar is the next step, not a completed one.
Reusable takeaway
The pattern worth borrowing is not "route work with AI." It is separating the decision about what should happen from the modules that make it happen, and giving approval and audit their own dedicated tools rather than folding permission checks into every action module individually. That structure scales more cleanly as new domains get added, because each new module only needs to call the existing approval and audit tools instead of building its own version of both.
Explore the Chief OS repository to see the full module and widget structure, or start a new MCP server with the NitroStack SDK to try the same modular pattern.