CoCo Super Intelligence

Summon an advisory board of 495 world-class minds — right inside your AI coding session.

CoCo Super Intelligence is the orchestration layer that turns Claude Code, Cursor, or Codex into an entire engineering department: routed expert panels that deliberate and decide, then 226 skills, 386 commands, and disk-persistent state that ship what they decided.

Open-core (MIT core · proprietary Super Intelligence) · installs in 90 seconds · 100% local · no telemetry

One developer writing single prompts? That was last year.

CoCo Super Intelligence convenes a cross-team board of 495 named experts to pressure-test your hardest calls — then puts an orchestrated team of agents to work executing the verdict: parallel build waves, deterministic verification gates, and phase state that survives every /clear.

npx cocosuperintelligence
# or: npm i -g cocosuperintelligence && coco
# alternate: git clone https://github.com/coco-research/coco.git && cd coco && bash install.sh

What CoCo Is (and Isn't)

CoCo is not a new AI model, and it is not another agent harness. It doesn't run a model or an agent loop of its own. It's a portable layer of Markdown and YAML that installs into the agent harness you already use — Claude Code, Cursor, Codex CLI, or any AGENTS.md-compatible tool — and upgrades it with an expert advisory board, a skills library, persistent project memory, specialized subagents, and verification gates.

Your model, your tool, your keys, your machine. When you see "parallel subagent waves," those subagents are executed by your host harness's own agent machinery; CoCo supplies the orchestration structure that makes it all behave like a coordinated team. That is exactly why CoCo is vendor-neutral: it's the operating layer, not the engine.

⭐ The Board — CoCo Super Intelligence

A cross-team advisory board of 495 world-class minds

Super Intelligence is CoCo's signature capability. It lets you summon custom, real-world expert panels directly inside your coding session to guide architectural, engineering, risk, finance, and business decisions — each contribution attributed to a named expert, grounded in cited public sources.

/SI-Decide "Should we migrate our database to pgvector?"
/SI-AI-Decide "Which embedding model gives the best cost/performance?"
/SI-Eng-Pre-Mortem "Review our zero-downtime cache migration strategy"
/SI-GRC-Review "Check this customer onboarding flow for GDPR compliance"

495 expert personas, organized across 13 specialized departments:

• 342 generated slash commands. 17 cross-team meta commands (like /SI-Decide or /SI-Tradeoff, routing across domains) plus 325 per-team commands (25 verbs × 13 teams, such as /SI-AI-Decide or /SI-Eng-Pre-Mortem). These are generated locally at install time from the team registries — no command files are transmitted or stored remotely.
• 70 expertise cells. Each department is subdivided into focused cells (e.g. Engineering has 11, AI has 8) so the router can assemble a precise panel rather than a generic crowd.
• Cross-team meta-orchestration. For complex queries spanning domains ("build and sell an AI audit tool"), a local router scores your prompt against team registries and cells, then greedily assembles a proportional 16–32-person panel.
• Citable and grounded. Every stance is verified from public sources and carries a direct evidence URL. Personas are validated against a strict anti-fabrication gate.
• --debate deliberation. Panels can argue in reacting rounds before returning a verdict, surfacing named dissent instead of false consensus.

The selection algorithm (two-stage routing + approval)

The meta-orchestrator uses a staged algorithm so it never has to load the entire persona filesystem at runtime:

1. Stage A — team & cell routing (cheap). Reads the meta-registry (systems/superintelligence/registry.json) and scans only team descriptions and cell definitions, scoring relevance by keyword and domain overlap to select the top 1–4 teams. If one team dominates, it delegates to that team's own orchestrator.
2. Stage B — scoped persona selection. Loads compact persona records (slugs, cells, domains, stances, conflict mappings) for only the selected teams, allocates the 16–32-person budget proportionally, runs the greedy scorer (0.40·domain + 0.30·cell-coverage + 0.30·conflict-pairing), and applies a cross-team tension pass to pair opposing viewpoints (e.g. security vs. growth).
3. Stage C — approval & execution. Presents the roster grouped by team with a one-line rationale. The action verb then consumes the approved roster and returns output with full line-by-line attribution (e.g. "Aswath Damodaran (Finance): …").

Persona build & validation pipeline

The 495-persona roster was compiled with a systematic multi-tier workflow. Candidate generation was evaluated across local Qwen (via LM Studio), a hosted small model, and Gemini Flash, but Claude research agents proved the quality winner for resolving historical data and citing verifiable signal. Personas are checked by an advisory validation gate (validate_persona.py) that enforces five things: every required frontmatter field is present; at least 4 cited URLs resolve live (non-404); every public_stance carries an evidence_url, so no stance is uncited; at least 2 recent signals within 12 months (or 2 persistent signals for historical archetypes); and any pairs_well_with / productive_conflict_with slug refers to a real roster member. Two limits are worth stating plainly: the gate confirms that a stance is cited, not that a quotation is authentic, and home_team is only checked for presence, not validated ag