English | 中文

AI Team OS

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

⚡ v1.10.2 — Cross-session orchestration: wake system v2 (dynamic /loop, event watcher, turn-end guard) + targeted sibling-session driving + agent reuse recommendation + context watermark observability. Patch: server event-write exactly-once + model-tier charter (Fable orchestrates, Opus executes).

168 MCP tools · 217 REST endpoints · 22 dashboard pages · 1,758 tests · 25 agent templates · 47 ecosystem research tools · 5 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.

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. Size guardrails (<=40 entries x 400 chars), supersedes swap to prevent bloat, invalidate-never-delete for auditability.
• 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: 24 capability-domain toolsets; a startup env var decides which modules register. default core profile = task/team/memory/infra/reports (44 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_create:

• 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 silence 173.8s) and set at 5.2× the worst healthy case — it flags late rather than crying wolf
• Project-detail integration: workflow team rows carry an inline run summary (status / agent count / duration / finish time) plus a "view swimlane" deep link; members display semantic phase labels (e.g. audit:sourceA) instead of ids
• Leader auto-detection: a project's Leader session / model / liveness is probed directly from the ~/.claude/projects/ file truth by the backend — zero registration dependency, /model switches surface in real time
• MCP tools: workflow_list (browse runs), workflow_get (full archive + per-agent rows), workflow_reconcile (repair from on-disk snapshots after the OS was offline)
• Self-healing ingestion: hook receipt anchors + on-disk snapshot reconciliation + a reaper backstop close offline gaps automatically — finished runs on disk are ingested idempotently; cross-project attribution matches the on-disk path slug against registered projects

5. Ecosystem Research Platform — 47 tools

A project-isolated knowledge base that accumulates research findings over time. Each repo progresses through 4 stages (a progressive funnel, since v1.5.0), with token-efficient triggers and append-only history:

• Stage 0 — Auto shallow-summary on archive: newly-archived repos automatically get a 200-400 char ai-engineer summary (core function / positioning / advantages). 8-class failure handling with self-learning (3+ same-class fails → pattern_record, future agents read lessons via pattern_search)
• Stage 1 — On-demand architecture analysis: user picks research direction ("memory_system") → batch-dispatch backend-architect agents to read architecture key files
• Stage 2 — Multi-perspective debate: triggers existing debate_start (NOT a built-in debate engine — reuses meeting system)
• Stage 3 — Reference / Integrate marking: mark_as_reference adds tag for future quick recall; `