English | 中文

AI Team OS

Your AI coding tool stops when you stop prompting. Ours doesn't.

⚡ v1.11.2 — A data-integrity patch: every delete path now asks "can this be rebuilt?" first. The container-team reaper refuses to touch rows carrying token ledgers or unharvested transcripts — and the 325M tokens of attribution one purge did destroy were restored byte-exact from backup + journal, behind a clock-regime gate that caught a wall-clock backup masquerading as UTC. Dispatch identity is pinned to the CC agent id (same-name dispatches can no longer overwrite each other's ledgers), roster tools shrank back under the MCP result cap (67k → 2k chars on a 51-member team), commits landing on another agent's active branch are blocked at the hook, and template-name validation warns without ever silently swapping your agent type.

Full version history: CHANGELOG.md

113 MCP tools · 208 REST endpoints · 23 dashboard pages · 2,307 tests · 25 agent templates · 42 ecosystem research tools · 14 machine-checked invariants

AI Team OS turns Claude Code into a self-driving AI company. You're the Chairman. AI is the CEO. Set the vision — the system executes, learns, and evolves autonomously.

The Problem With Every Other AI Tool

Every AI coding assistant works the same way: you prompt, it responds, it stops. The moment you step away, work stops. You come back to a blank prompt.

AI Team OS works differently.

You walk away at night. The next morning you open your laptop and find:

• The CEO checked the task wall, picked up the next highest-priority item, and shipped it
• When it hit a blocker that needed your approval, it parked that thread and switched to a parallel workstream
• R&D agents scanned three competitor frameworks and found a technique worth adopting
• A brainstorming meeting was organized, 5 agents debated 4 proposals, and the best one was put on the task wall

You didn't prompt any of that. The system just ran.

How It Works

You're the Chairman. The AI Leader is the CEO.

The CEO doesn't wait for instructions. It checks the task wall, picks the highest-priority item, assigns the right specialist Agent, and drives execution. When blocked, it switches workstreams. When all planned work is done, R&D agents activate — scanning for new technologies, organizing brainstorming meetings, and feeding improvements back into the system.

Every interaction makes the system understand you better. Memory System v2 distills your preferences and corrections into a team direction layer that every dispatched Agent inherits at birth — you never say the same thing twice, and no next Agent repeats a pit an earlier one already fell into.

Core Capabilities

1. Cross-Session Orchestration (new in v1.10.0)

A single CC session can now observe and drive its sibling sessions for one operational turn, instead of only being able to spawn brand-new ones:

• Wake system v2: the /api/wake/actionable single-source predicate feeds both the event watcher and the turn-end guard; SessionStart moves from a fixed 30-minute cron to dynamic /loop intervals; a Stop-hook turn-end guard always lets decision:block and user-stop keywords pass through; a session-scoped event watcher carries a 1-hour hard timeout. No resident daemons.
• Fleet downlink primitive: headless claude -p --resume <session_id> drives a target sibling session for one turn, reusing the existing wake machinery (semaphore, fuse, allowlist, per-session dedupe, full audit trail).
• agent_reuse_recommend MCP tool: a three-way reuse decision (reuse / slim-then-reuse / spawn-new) scored by domain match, reachability (live / resumable / cross-session / expired), and context watermark.
• Context watermark ledger: exact token usage read from the transcript tail (cheap-checks-first), surfaced as a three-color watermark bar on agent views and on the new fleet / worktree observability cards.
• Compaction checkpoint (v1.11.0): PreCompact freezes the OS-side operating picture — agents in flight, open tasks, decisions queued for you — and SessionStart(source=compact) hands it straight back. CC's own summary body is deliberately not stored: after compaction it is already in the model's context; what a compacted Leader loses is the OS-side state it no longer knows to ask about.
• CC session registry as a second liveness track (v1.11.0): ~/.claude/sessions/<pid>.json carries a real pid and CC's own idle/busy state, which distinguishes "process gone" from "process alive but quiet" — a distinction transcript freshness cannot make. It runs alongside the existing verdict and only records where the two disagree; the verdict itself is unchanged until the divergence data says otherwise.
• Background daemon sessions are visible (v1.11.0): GET /api/hooks/background-jobs reads CC's own job state, so a --bg session that outlives its foreground window no longer looks like "nobody is working".

Usage guidance:

• A new session's SessionStart briefing already points you at running /loop once - follow it instead of guessing at intervals.
• Check the project detail page for the fleet card (per-session CEO / model / in-flight tasks / watermark) and the worktree card (branch ownership + unlanded-work status) before you act.
• Call agent_reuse_recommend before dispatching a follow-up agent - reusing a live or resumable sibling session beats spawning a fresh one.
• The S4 worktree teardown guard and per-template isolation: worktree defaults apply automatically; no configuration is needed.

2. Memory System v2 — two-layer memory, every Agent inherits at birth (new in v1.9.0)

The OS's signature differentiator: your team's preferences, corrections, and hard-won lessons flow automatically to every Agent it dispatches.

• Direction layer (user preferences / corrections / design intent, 4 kinds): resident injection via both the SessionStart and SubagentStart hooks — every sub-Agent inherits the team's values and red lines the moment it's born, so you don't repeat yourself. The size guardrail is a single axis: storage cap = injection budget (per-bucket character quotas, global 1200 + 1500 per project + user 300 = 3000 chars, <=400 chars per entry), so whatever fits is what actually ships; a full bucket hands back its complete contents and demands a cleanup before the retry. supersedes swap to prevent bloat, invalidate-never-delete for auditability. Writes are scanned for invisible Unicode, instruction-override phrasing, and credential shapes — the direction layer lands in every Agent's system prompt, which makes it an injection amplifier.
• Episodic layer (task_memos ledger): task-level execution memos promoted to a dedicated table (row IDs / invalidation axis / quality score / scope_path), recalled on demand via pure-Python BM25 Chinese retrieval; 123 legacy memos backfilled with zero loss.
• On-demand reconcile (memory_reconcile): zero-LLM BM25 candidate clustering, then merge / invalidate / score / distill on agent confirmation — "the agent computes, the tool persists", with no background resident process introduced.

Surfaces: MCP memory_add / memory_list / memory_invalidate / memory_search / memory_reconcile_candidates / memory_reconcile_apply.

3. Progressive Tool-Loading Governance (new in v1.9.0)

Treats the resident context budget as the scarce resource it is — however many tools exist, they never drown your Agent.

• alwaysLoad dynamic rotation: at session start a single SQL recomputes the hot-tool whitelist by 7-day real call frequency (>=2-day span gate against bursty spikes + 20% hysteresis, hard cap <=5), and CC skips ToolSearch for them. Not additive, not hand-tuned; any stats failure silently degrades to all-defer, and every whitelist is logged for audit.
• AITEAM_TOOLSETS group switch: 16 capability-domain toolsets; a startup env var decides which modules register. default core profile = task/team/memory/infra/reports (29 tools, hard cap <=50), with incremental default,ecosystem — fits non-CC clients that cap tool counts.
• AITEAM_READONLY read-only profile: an orthogonal overlay that strips every write tool by explicit allowlist and keeps only read tools — ideal for audit / observer sessions.
• 5 templates on least privilege: meeting-facilitator / debate advocate & critic / technical-writer / project-manager carry disallowedTools structural denials; engineering / testing templates untouched.

4. Workflow / ultracode Persistent Observability (v1.7.0)

The OS does not intercept CC's built-in ultracode/Workflow — it becomes its persistent governance layer. Every Workflow run is automatically tracked into the OS, with no manual team setup:

• Auto-tracking: a hook turns each Workflow run into an OS "team" (workflow-<wf_id>) the moment it starts
• Dashboard /workflows: a live feed of run cards, a phase swimlane timeline, and per-agent telemetry — tokens / duration / status / tool-call counts, advancing live via incremental journal tailing while a run executes
• Calibrated stall detection: the stall threshold was calibrated on 3,378 real agent intervals (p99 = 77.6s, longest healthy sile