oc8

• 🔒 Isolated AI Agents — each agent runs in its own container, with access only to what oc8 explicitly grants it.
• 📚 RAG Knowledge Base Management — retrieval-augmented knowledge, scoped per agent or department.
• 🧠 Works With Any LLM — Anthropic, OpenAI, OpenRouter, local Ollama, or any OpenAI-compatible endpoint.
• 🛡️ Sovereign by Design — self-hosted; your data and credentials never leave infrastructure you control.
• 🏢 Scoped and Built for Enterprise Usage — tenant isolation, audit trails, and approval thresholds from day one.
• 🔌 Works With Your Existing Stack — oc8 orchestrates the CRM, ERP, and tools you already run; nothing to rip out and replace.
• 🧑‍⚖️ Human in Control — every consequential action waits for approval unless you've explicitly said otherwise.
• 🧩 Extensible in Every Direction — the capa system: connectors, skills, tool packs, and department templates as installable folders.
• 🔗 Built on Open Protocols — every tool call goes through the same governed MCP gateway, compatible with standard agent tooling.
• 📈 Built to Scale — from a single agent to a full digital workforce.
• 🗂️ Knowledge & Tool Management for Agents — assign exactly what each agent can read, call, and use.
• 🏙️ Your Digital Company — departments, agents, and approvals that mirror how your business actually runs.

Status: oc8 is under active development. Read Scope and limitations before a production deployment.

oc8 turns "hire someone to do this" into a configuration you can inspect, approve, and audit. You describe the outcome, the agent proposes how it'll get there, and every consequential step — a write, a send, a spend past a threshold — waits for a human unless you've explicitly said otherwise. Your existing software landscape stays exactly where it is — oc8 orchestrates it, it doesn't replace it.

oc8 is for you if

• ✅ you want an AI agent to actually do recurring work — triage tickets, draft and send replies, update records in a real business system — not just answer questions in a chat window.
• ✅ you need to know, after the fact, exactly which agent did what, when, and under whose approval — not just trust that it behaved.
• ✅ you'd rather self-host on infrastructure you control than hand your business data and credentials to someone else's cloud.
• ✅ you want to plug in the tools you already use (a CRM, a helpdesk, a knowledge base) without hand-rolling an integration for each one — or ripping out and replacing what already works.
• ✅ "run this in an isolated container, not my agent host" is a requirement, not a nice-to-have.

How it works

Step	What happens
1. Describe	State the outcome in plain language: "classify incoming tickets, draft a response, escalate anything about billing."
2. Configure	Assign a model, the knowledge and tools it needs, and the autonomy/escalation boundary — or let the built-in Copilot draft the configuration for you to review.
3. Run	The agent executes on a schedule, an event, or a chat message; every governed action is checked against its permissions before it happens.
4. Govern	Anything over a value threshold or on an always-ask list waits for a human — from the inbox, or from Telegram/WhatsApp.

Any agent runtime that can be sandboxed and driven through oc8's gateway is hireable.

What's under the hood

                         ┌─────────────────────────┐
                         │        caddy (edge)      │
                         └────────────┬─────────────┘
                    ┌──────────────────┴───────────────────┐
                    │                                       │
           ┌────────▼────────┐                    ┌─────────▼─────────┐
           │     frontend      │                    │      backend       │
           │  (React/Vite SPA) │◄──────REST/WS──────│  (FastAPI, API v1) │
           └────────────────────┘                    └─────────┬──────────┘
                                                                 │
                     ┌───────────────────┬───────────────────┬─┴───────────────┐
                     │                   │                   │                 │
              ┌──────▼──────┐    ┌───────▼──────┐   ┌────────▼───────┐  ┌──────▼──────┐
              │   worker      │    │  scheduler    │   │ ingestion-worker│  │  postgres    │
              │ (run executor)│    │ (cron/trigger)│   │  (RAG ingest)   │  │  + pgvector  │
              └───────┬───────┘    └───────────────┘   └─────────────────┘  └─────────────┘
                      │
                      │ isolated-runtime agents (opt-in per agent)
                      ▼
              ┌──────────────────────┐
              │  runtime-provisioner   │  the ONLY process with Docker socket access
              └──────────┬─────────────┘
                         │ one container per agent — spawned, reaped, never shared
        ┌────────────────┼────────────────┬────────────────┐
        │                │                │                │
  ┌─────▼─────┐    ┌─────▼─────┐    ┌─────▼─────┐    ┌─────▼─────┐
  │  agent A   │    │  agent B   │    │  agent C   │    │  agent N   │
  │ container  │    │ container  │    │ container  │    │ container  │
  │ own tools, │    │ own tools, │    │ own tools, │    │ own tools, │
  │ own creds  │    │ own creds  │    │ own creds  │    │ own creds  │
  └────────────┘    └────────────┘    └────────────┘    └────────────┘

Every isolated agent gets its own container — no shared filesystem, no shared credentials, no visibility into another agent's tools or data. The runtime-provisioner is the only process in the stack that ever touches the Docker socket, so the backend and worker processes themselves never carry that (host-root-equivalent) privilege.

This is the beginning of the README. Read the rest at the original. Read the full README ↗