RoboCo
AI Agents Company - A virtual organization of 26 AI agents + 1 human CEO, designed to operate as a complete software development workforce.
[!WARNING]
RoboCo is early-stage, work-in-progress software (v0). It's under active development, runs in a homelab, and will have rough edges, breaking changes, and bugs. It is not production-ready and the API/database schema are not stable yet. Treat it as a working prototype to explore and build on — please don't expose it to the public internet as-is. Issues and PRs very welcome.
[!TIP]
📚 Full documentation: docs.roboco.tech — install & first run, the company model, a page-by-page panel reference, model providers, the optional subsystems, deployment, and the API.
Overview
RoboCo implements a structured organizational hierarchy with formal communication protocols, task management, and quality controls. The system enables a single human (CEO) to orchestrate complex multi-project development at scale.
CEO (You, the human)
│
├── Intake (on-demand interviewer: chats only with you to draft a task)
├── Secretary (on-demand chief-of-staff: reads company state, runs gated directives)
├── PR Reviewer (read-only main reviewer: inbound external/fork + internal PRs, and the root→master in-path gate)
│
└── Board (3 agents)
├── Product Owner
├── Head of Marketing
└── Auditor (silent observer, reports to you)
│
└── Main PM (coordinates all cells)
│
├── Backend Cell (6 agents: 2 Devs, 1 QA, 1 PM, 1 Documenter, 1 PR Reviewer)
├── Frontend Cell (6 agents: 2 Devs, 1 QA, 1 PM, 1 Documenter, 1 PR Reviewer)
└── UX/UI Cell (6 agents: 2 Devs, 1 QA, 1 PM, 1 Documenter, 1 PR Reviewer)
The 26 agents = Intake + Secretary + PR Reviewer + DevOps + the Board (3) + Main PM + the three 6-agent cells (18). Agents run on Anthropic Claude by default, or on xAI Grok, OpenAI Codex, Google Gemini, or Moonshot Kimi K3 (each on its own official CLI and subscription, no metered API key) — see the provider note under Configuration.
How it works
You hand a task to the company; it runs through a real build → review → document → merge pipeline and comes back to you to approve.
One full loop, put simply:
- You give the Board a task — they review it. The Product Owner and Head of Marketing turn your ask into requirements and acceptance criteria.
- You approve — the Main PM starts the work. A notification asks for your Approve & Start decision; approve, and the Main PM breaks it into per-cell subtasks.
- Each cell's PM delegates, supports, and triages its developers (UX/UI, Frontend, Backend).
- Developers build it, QA verifies and gates it, Documenters keep the books.
- Cell PMs merge their PRs into the Main PM's branch.
- The Main PM opens the final PR and notifies you "It's done!" — you approve and merge, or send it back for rework. (Only you ever merge to
master.)
— Full circle —
See the full walkthrough, with screenshots →
Or watch the full panel walkthrough (video) →
Project Structure
roboco/
├── roboco/ # Main Python package
│ ├── api/ # FastAPI routes & schemas
│ │ ├── routes/ # API endpoints (tasks, git, agents, etc.)
│ │ └── schemas/ # Pydantic request/response models
│ ├── services/ # Business logic services
│ │ ├── task.py # Task lifecycle management
│ │ ├── workspace.py # Multi-agent workspace management
│ │ ├── messaging.py # Agent communication
│ │ └── optimal.py # RAG/Knowledge base (in-house pgvector)
│ ├── models/ # Pydantic domain models
│ ├── db/ # SQLAlchemy ORM & session
│ ├── enforcement/ # Task lifecycle state machine
│ ├── runtime/ # Orchestrator for agent spawning
│ ├── agents/ # Agent base classes
│ ├── mcp/ # MCP server implementations
│ └── config.py # Application configuration
├── agents/
│ └── prompts/ # Agent system prompts (roles, teams, identities)
├── docs/
│ ├── rag/ # Agent knowledge base (indexed into RAG)
│ └── map/ # Exhaustive codebase map (agent-facing)
├── alembic/ # Database migrations
├── motion/ # Video/motion-graphics toolchain
├── panel/ # Next.js 16 control panel (served on :3000 via nginx)
├── scripts/ # Bootstrap and utility scripts (bootstrap.sh for make quickstart)
├── CLAUDE.md # Claude Code guidance
├── docker-compose.yml # Full stack, built from source
└── docker-compose.registry.yml # Full stack, pulled from the image registry
Running RoboCo
You need Docker + Docker Compose and a Claude Code auth directory on the host (~/.claude, mounted into the orchestrator so agents can reach the model). Copy .env.example to .env and set at least ROBOCO_ENCRYPTION_KEY and ROBOCO_AGENT_AUTH_SECRET (that file shows how to generate each). However you start it, the whole company is reachable at one origin: http://localhost:3000.
Optional — run agents on xAI Grok instead of Claude. RoboCo can spawn agents on xAI's official grok CLI authenticated by a SuperGrok subscription (no metered API key). Run grok login once on the host and point ROBOCO_HOST_GROK_DIR at the resulting ~/.grok so it mounts into Grok agents; the orchestrator keeps the ~6h token refreshed for you. See the Grok block in .env.example (ROBOCO_HOST_GROK_DIR, ROBOCO_GROK_AGENT_IMAGE, ROBOCO_GROK_CLI_MODEL, ROBOCO_GROK_REASONING_EFFORT).
Optional — run agents on Moonshot Kimi K3 instead of Claude. RoboCo can spawn agents on Moonshot's official kimi (kimi-code) CLI authenticated by a Kimi subscription (OAuth device-code login, no metered API key). Run kimi login once on the host; ROBOCO_HOST_KIMI_DIR points at the resulting ~/.kimi-code (optional — defaults sensibly) and mounts read-write, since every Kimi agent shares the host's one rotating credential chain. See the Kimi block in .env.example (ROBOCO_HOST_KIMI_DIR, ROBOCO_KIMI_CLI_MODEL — default kimi-code/k3, kimi-code/kimi-for-coding is the cheaper lever).
Optional: run agents on Nebius Token Factory (NVIDIA Nemotron). RoboCo can route the whole fleet through Nebius Token Factory, an OpenAI-compatible inference API serving 60+ open models (NVIDIA Nemotron, DeepSeek, Qwen, Llama) behind one metered API key. No host login or env var is needed: save the key in the panel under Settings -> AI Routing -> Nebius API key (stored Fernet-encrypted server-side), then click the Nebius mode button. The fleet-wide default model is NVIDIA's open-source Nemotron 3 Super (nvidia/nemotron-3-super-120b-a12b); the searchable picker can narrow it to the rest of the Token Factory catalog. Agents spawn on the opencode CLI with rate-limit parking and per-agent token/cost metering. This is the path judged in the Nebius x NVIDIA hackathon; see HACKATHON.md for what was built for it.
Option 1 — Run the pre-built images (quickest)
Every release publishes all RoboCo images to both the GitHub Container Registry and Docker Hub, so you can run the full stack without building anything. One command brings it up:
git clone https://github.com/rennf93/roboco.git && cd roboco
make quickstart # no make? run ./scripts/bootstrap.sh directly
make quickstart (scripts/bootstrap.sh) is idempotent — safe to re-run any time. What it does:
cp .env.example .env # only if missing — an existing .env is never touched
# ...generates ROBOCO_ENCRYPTION_KEY / ROBOCO_AGENT_AUTH_SECRET / ROBOCO_PANEL_AGENT_TOKEN in place
docker compose -f docker-compose.registry.yml pull
docker compose -f docker-compose.registry.yml up -d
# ...then polls until the stack is genuinely ready (health, migrations, Ollama
# models) and prints a doctor-style summary — or fails loud with what to check.
Note: ROBOCO_PANEL_AGENT_TOKEN is a standing CEO credential — blank it if you later arm cloud auth (see .env.example).
A fresh .env also gets ROBOCO_HOST_PROJECT_DIR and ROBOCO_HOST_DATA_DIR pinned to the checkout location — these are the host-side paths the orchestrator bind-mounts into every spawned agent. If you reuse an existing .env that doesn't set them, quickstart checks that the absence is safe: it only passes silently when the checkout is already at /opt/roboco (the compose default). Anywhere else, it fails loud with the exact line to add (e.g. ROBOCO_HOST_PROJECT_DIR=/your/checkout/path), because an unset var makes Docker create an empty directory at /opt/roboco and every agent spawn dies with IsADirectoryError before reading its system prompt. An explicitly-set value is always trusted as-is — split host/daemon setups (remote or rootless Docker, a bind-mounted checkout) legitimately name paths the script can't see.
Choose the registry and version with two env vars (defaults shown) — set them in .env before running make quickstart:
ROBOCO_REGISTRY=ghcr.io/rennf93 # or docker.io/renzof93
ROBOCO_VERSION=latest # or a pinned release, e.g. 0.15.0
The orchestrator spawns the matching pre-built agent images on demand — no build toolchain or source compile on your host.
Option 2 — Build from source
The same full stack, built locally from the Dockerfiles instead of pulled:
git clone https://github.com/rennf93/roboco.git && cd roboco
cp .env.example .env # then edit in your secrets
docker compose up -d # builds images on first run, then starts everything
Option 3 — Local development (no full stack)
For hacking on the code itself, run only the backing services in Docker and the API on your host. RoboCo's own code requires Python 3.13+ (uv will fetch it if needed):
uv sync
docker compose up -d postgres redis ollama # backing services only
uv run alembic upgrade head # migrate the database
uv run python -m roboco.cli # API + orchestrator
# Or just the API without the orchestrator:
uv run uvicorn roboco.api.app:app --reload --host 0.0.0.0 --port 8000
Configuration
Key environment variables (see roboco/config.py for all options). The panel's Settings → Feature Flags card is the authoritative source for the full set of 36 feature flags — toggle them there rather than editing env by hand. The bash block below shows the env-var equivalents of a few representative flags plus settings that have no panel toggle: