Co-founder OS — Founder Mission Control

An AI operating system for solo founders that turns goals and evidence into auditable workflows, coordinating product, engineering, finance, and risk agents with human approval.

Comment

Inspiration

Solo founders do not just need ideas or another chatbot. What they really need is a system that can continuously help them move work forward.

In real startup work, even a simple goal often spans product definition, engineering execution, budgeting, risk assessment, research synthesis, and sequencing of next actions. Most AI tools can generate answers, code, or documents in isolation, but they usually lack shared task state, clear responsibility boundaries, approval checkpoints, and deliverable management.

That is why I built Co-founder OS: an AI-native operating system for solo founders and small teams.

It is not just a simulated “AI co-founder.” It is a system that organizes multiple models, specialized agents, tools, and human decisions into an executable, recoverable, and auditable workflow.

What it does

A founder can submit a business goal together with supporting text, documents, or image-based evidence.

Co-founder OS then performs the following workflow:

  1. Organizes the input into a structured Evidence Board;
  2. Uses an Executive Orchestrator to break the goal into bounded tasks with dependencies;
  3. Chooses an appropriate model path based on task complexity, risk, context, and tool needs;
  4. Dispatches specialized roles such as Product & Engineering, Finance, and Risk;
  5. Applies a Policy Gate before high-risk write actions, budget decisions, or external actions;
  6. Requires the founder to approve, reject, or request changes before key actions proceed;
  7. Synthesizes the outputs into a deliverables package with supporting rationale and traceability.

The output is not just a generic answer. It is a set of working artifacts such as:

  • a product requirements document;
  • a technical execution and testing plan;
  • budget and resource recommendations;
  • a risk register and mitigations;
  • a prioritized action plan;
  • model-routing, approval, and execution records.

Mission Control provides a unified view of the task tree, routing rationale, agent status, approval requests, deliverables, and audit logs, so the founder can understand what the system is doing, why it is doing it, and where human judgment is still required.

How I built it

Co-founder OS uses a local-first, cloud-enhanced control-plane architecture.

The backend is built with Python and FastAPI, with strict Pydantic data models describing Runs, Tasks, Artifacts, Approvals, and Audit Events. Instead of relying on open-ended recursive agent conversations, the system uses an explicit Agent Registry and a task lifecycle state machine to control which agents are allowed to execute work and when tasks can move through states such as ready, running, blocked, failed, and completed.

The model gateway exposes a unified interface and applies deterministic routing rules. Each routing decision records not only the selected model, but also the task complexity, risk level, context size, tool requirements, and fallback rationale.

To make workflow execution reliable, I implemented:

  • atomic task claiming;
  • idempotent execution;
  • bounded retries;
  • terminal failure states;
  • approval pause and resume;
  • file-based artifact storage;
  • append-only audit events;
  • replayable task lifecycles.

This makes the system capable not only of generating outputs, but also of reasoning, executing, failing, retrying, recovering, and leaving behind a complete audit trail.

How I used Codex and GPT-5.6

Codex acted as an engineering execution partner during Build Week.

I used Codex to inspect the codebase, break down the architecture into smaller development phases with clear exit criteria, generate and revise implementation code and tests, analyze failures, review diffs, and verify whether each milestone had been completed.

GPT-5.6 was primarily used for higher-level reasoning and engineering review, including:

  • defining role boundaries across agents;
  • designing execution, approval, and retry semantics;
  • reviewing model-routing and risk-control strategy;
  • identifying hidden loops and uncontrolled behavior in the architecture;
  • shaping founder-task evaluation scenarios;
  • analyzing conflicts across agent outputs;
  • translating technical implementation into a coherent product experience.

I made the final product, architecture, and engineering decisions myself, and manually reviewed the generated code, tests, and documentation. Codex accelerated implementation and validation, while GPT-5.6 helped maintain system boundaries and overall coherence in a solo-development workflow.

What I extended during Build Week

Co-founder OS existed as a broader product concept before Build Week, but this submission focuses on the meaningful work completed during Build Week, including:

  • a unified local-and-cloud model gateway;
  • an explicit Agent Registry and Executive Orchestrator;
  • strict task and artifact data models;
  • atomic task claiming, idempotent execution, and bounded retry handling;
  • structured outputs from specialized agents;
  • an Artifact Store, Policy Gate, and audit-event pipeline;
  • the Founder Mission Control interface;
  • a repeatable founder-task evaluation structure;
  • an end-to-end workflow from founder goal to final deliverables package.

Commit history, tests, and Codex session records are used to distinguish prior concept work from Build Week implementation work.

Challenges

Turning agents into a system

The biggest challenge was not getting multiple roles to generate different outputs. It was making them share task state, obey execution order, and handle failure correctly.

Instead of using a free-form group-chat style agent pattern, I designed explicit contracts for task claiming, dependencies, retries, approvals, and terminal states.

Explainable model routing

Simply switching between models is not enough. The system needs to explain why a task was run locally, why it was escalated to a stronger model, and why a fallback path was selected after failure.

That is why routing decisions are treated as formal audit events instead of being hidden inside prompts.

Balancing autonomy and control

Founders want AI to move work forward, but they do not want the system acting independently on budgets, publishing actions, external communication, or other high-risk operations.

I therefore designed human approval as a core workflow step, not just an after-the-fact safety patch.

Building as a solo founder

As a solo builder, I had to cover product design, architecture, backend, frontend, testing, deployment, and submission preparation at the same time.

Codex and GPT-5.6 allowed me to structure the development process itself as a “human lead + AI engineering team” workflow, which also became a real validation of the product vision behind Co-founder OS.

Accomplishments

What I am most proud of is not how much content the system can generate, but that it establishes a runtime with explicit operating semantics:

  • tasks cannot be executed by unregistered agents;
  • the same task cannot be claimed by multiple executors at once;
  • retries have bounded limits;
  • failures are not silently disguised as success;
  • high-risk actions pause for human approval;
  • every artifact can be traced back to its task and executor;
  • the workflow can be inspected, resumed, and replayed.

As a result, Co-founder OS is not just an AI interface. It is an early operating system for founder execution.

What I learned

This project reinforced several beliefs:

  1. The core of multi-agent systems is not the number of roles, but the execution contract.
  2. Model routing must be observable, explainable, and degradable.
  3. Founders need deliverables and decision support, not just longer answers.
  4. Human approval is not a limitation on automation; it is a foundation for trustworthy automation.
  5. AI-native organizations need task state, permissions, auditability, and evaluation, not just prompts.

What's next

Next, I plan to:

  • expand into Growth, Operations, Legal, and HR roles;
  • connect to more secure local tools and MCP services;
  • strengthen multimodal evidence handling across documents, images, and structured data;
  • build richer evaluation for quality, cost, latency, and human intervention;
  • support long-running work, recurring reviews, and cross-project memory;
  • evolve Co-founder OS from a hackathon prototype into an ongoing work system for solo founders.

The long-term goal is not to replace the founder, but to give a single founder access to the kind of organizational capability that previously required a full team.

Built With

Share this project:

Updates