Your AI says it’s done.
Prove it.
The operating system for human + agent teams.
An open-source protocol engine that puts every process on rails — enforced as it happens, so ‘done’ isn’t something you take on faith.
“Ask your Claude” copies a short brief — let your own model judge the fit.
Claude — Codex & Antigravity when you turn them on — on the subscriptions you already pay for.
The model getting more capable does not make it more trustworthy. It makes it a more convincing liar.
The answer isn’t a smarter assistant you hope did the work. It’s a harness you own — it shows the work, blocks the shortcuts, and hands you the proof.
Watch the rails work.
A protocol is your process, written down — the steps every task must follow. The engine holds the AI to it, step by step. Pick one below and watch it run.
- 01Investigationread-only
Read-only. Explore the code and agree the plan before a single edit.
OpusAntigravityCodexyour call — answer to go on - 02Implementationedit tools unlocked
Edit tools unlock. Tests first, on the task branch.
- 03Code-reviewspec gate
The spec-compliance gate — multi-model review until it’s clean.
OpusAntigravityCodex - 04Documentationdocs only
Docs-only. Service docs and the work log sync.
writes back to the shared LLM wiki - 05Completionsquash & push
Squash, merge, push — the task is archived.
- any model
- Claude by default · or any model including the one you host yourself
- at the gates
- Codex + Antigravity — reviewing in parallel
- any skill
- your slash-commands · MCP tools · subagents
- runs inside
- Claude Code, as a native plugin — on your own git
- costs
- your existing subscriptions — the reviewers ride their own CLIs · no extra API keys
Your process becomes a protocol — and a protocol can’t be skipped. Nothing about a protocol is specific to code: it’s just JSON — steps and gates — so you drop your own in custom/ and it runs on the same rails, dev or not.
vendor-onboardingemployee-onboardingincident-response— a few your business might run
See it. Enforce it. Prove it.
Make the AI’s claims verifiable instead of trusting them. The work runs on a track you can watch, behind gates it can’t skip, leaving a record you can prove.
Watch every step as it runs — which stage it’s on, what’s allowed, what’s done. No black box, no “trust me, it’s handled.”
The gate stays shut until the step’s criteria are met — no skipping ahead, no editing the tests to pass, no talking its way through.
Every run leaves a record of exactly what happened — the protocol, the steps, the gates it had to pass. Local, version-controlled, yours to keep. The record also says what checked what: review gates are AI judgment; the test gate is deterministic.
Prompts ask.
teammanagement enforces.
A prompt is a request an agent can ignore, forget, or quietly route around. The interesting parts of this system aren’t requests — they’re walls.
- claim it’s done when the tests never ran
- edit the tests to make them pass
- alter the database or fixtures to fit
- skip a step it was told to follow
- can’t advance past the gate without
SPEC_REVIEW: PASSED - can’t edit frozen tests or fixtures mid-run — the runtime blocks it
- can’t touch edit tools in discussion mode — DAIC blocks them
- can’t skip ahead to a step it hasn’t earned
Forward is earned; backward is always open. The engine won’t let the agent jump ahead — but it can always step back, re-plan, and re-earn the path when review finds a real problem. Your part is the alignment up front — the later gates run without you until one needs a decision.
Tests first. Specs checked. Evidence required.
- tests first
- The task protocol expects a failing test before code — and optimize’s frozen-paths hook physically blocks edits to your tests or metric script mid-run.
- specs checked
- A spec-review gate compares the diff against the task’s success criteria — the step can’t complete until it passes.
- evidence required
- A step can’t complete on “looks good” — the advance must carry literal verification output, or name why none applies.
Your memory. Your standards. Your skills. Your models.
No one should be locked in — the agents follow your policy, and everything they run on stays yours.
The LLM wiki lives in your repo, versioned in your git. What agents learn stays with the project, not with a vendor.
Protocols are JSON you fork or author — your custom/ directory is never touched on upgrade. Your process is the policy the engine enforces.
Your slash-commands, MCP tools, and subagents keep working. The engine orchestrates them; it doesn’t replace them.
Claude by default — or any model, including the one you host yourself.
Bring your own model — as the main one.
team.management runs inside your harness — self-host the main model and nothing leaves your network — the engine is local files in your repo, and the cloud reviewers don’t join until you invite them.
Compose the team each process needs.
Protocols fan work out to specialist sub-agents — each in its own context window, each returning structured results. A roster ships in the box, but it isn’t fixed: make as many as you want, and point them at whatever a step needs — a code review, a security pass, a research dive.
Plug into the tools you already run.
Beyond the agent roster, team.management wires into the systems around your work — issue trackers and version control — so a protocol step can sync, file, or open the merge request for you.
Sync issues and open pull requests straight from a task.
Sync issues and merge requests as the work moves.
Mirror tasks to Jira tickets and keep status in step.
Write a connector for any system your team runs.
Everyone on the same rails.
Agents are only half the team. The same protocols and the same wiki make a group of people — and their agents — work like one. Enabling it is one commit — merge it, and every teammate is on the rails.
The LLM wiki is project-local and version-controlled. What one person’s agent learns, everyone’s agent reads next. Knowledge stops living in one head.
Same protocols, same gates, same definition of done — whoever is driving. A teammate’s task looks like yours because it ran the same rails.
A new hire doesn’t need the tribal knowledge. The protocols teach the workflow and the wiki carries the context — they ship correctly on day one.
No one quietly skips review or invents their own flow. The engine enforces the shared process, so the codebase stays coherent across the whole team.
Five minutes from now, you’re shipping.
create a task for implementing user authentication
open source, by default
Shared knowledge becomes
a common good.
The rails, the protocols, the wiki — yours to read, fork, and build on. MIT-licensed.
Standing on shoulders.
team.management draws on the projects and ideas that shaped its design.
- cc-sessionsby GWUDCAP
- Origin of the DAIC methodology and the sessions / hook-enforcement model team.management is built on.
- superpowersby Jesse Vincent (obra)
- Composable skills for coding agents — inspiration for the skill/protocol-driven workflow.
- get-shit-doneby open-gsd
- Meta-prompting, context engineering, and spec-driven development for Claude Code.
- LLM Wikiby Andrej Karpathy
- The compounding, AI-maintained knowledge-base pattern behind the LLM Wiki feature.
- autoresearchby Andrej Karpathy
- Autonomous, metric-driven overnight experimentation — inspiration for the optimize protocols.
How it compares.
Every alternative hands your agent advice and hopes. See what each one does the moment the advice gets ignored — tool by tool, number by number.