--- title: "What is CommitCycle? The gate for AI agents | CommitCycle" description: "Change management for AI coding agents — grants bound to one task and one branch that expire, paths with owners, and one approval to move a wall." url: https://commitcycle.com/docs/start/what-is-cc/ language: en --- # What is CC? > Change management for AI coding agents — grants bound to one task and one branch that expire, paths with owners, and one approval to move a wall. CommitCycle — written **CC** everywhere in the product — is change management for AI coding agents. It exists because agents got good at writing code before anyone decided what they were allowed to touch. The model is three ideas, none of them exotic: ## Zones A **zone** is a set of path patterns with an **owner**, a **risk level** (`high` / `medium` / `low`) and a **default policy** (`deny` / `read-only` / `open`). The policy decides whether the zone can be read without asking — `deny` closes reading too — while writing into any zone always takes a grant that opens it (`packages/contracts/src/matcher.ts`). Migrations are a zone. Shared contracts are a zone. Everything you _don’t_ declare stays unprotected — which is the correct default for most of a repo. CC’s own guidance is to start with three zones, not thirty: an over-eager gate costs you more than a missing one, because a gate that blocks legitimate work gets uninstalled in week two. Zones live in [`zones.yml`](https://commitcycle.com/docs/reference/zones-yml/), committed to the repo, reviewed like code. Zones are optional. A repository runs in one of two [modes](https://commitcycle.com/docs/concepts/modes/): **memory**, the default for a repository with no zones, where the only rule at the edit is that it needs an active task; and **governance**, which adds zones, owners, approvals and grants bound to a branch. A person chooses it on the board. ## The board Work enters through a board with **five fixed states** — Triage, Todo, In Progress, In Review, Done (plus Canceled). The states are the data model, not a preference: they live in a database `CHECK` constraint precisely so there is nothing to add a row to. A one-line request lands in **Triage**. Scoping it — filling the [four-field task spec](https://commitcycle.com/docs/concepts/task-spec/) — moves it to **Todo**. The transition to **In Progress** is the main gate: it mints a time-boxed [grant](https://commitcycle.com/docs/concepts/grants/) for exactly the zones the task declared, bound to a git branch. The board is the only issuer: after this, an owner’s answer to an access request is the one thing that widens a grant, and a renewal re-issues the same zones with a new expiry. There is no command that opens a zone directly, so there is no back door to find. ## Enforcement that is a boundary, not a request An `AGENTS.md` file politely asks the agent to stay out of `migrations/`. Asking works right up until it doesn’t, and there is no log line where you can see that it didn’t. CC’s position is that anything enforced by prompt is advisory, so enforcement lives in [three layers](https://commitcycle.com/docs/concepts/three-layers/): context (advisory, and honestly labelled as such), a pre-tool-call hook that decides every call locally, and a CI status check that compares a pull request’s diff with what its task declared. That check is advisory unless branch protection requires it, and today it runs only in CommitCycle’s own CI. Worth being precise about, because it is the thing most easily overclaimed: **in-flight denial is not what makes CC different.** Several agent harnesses ship it, and the one you are most likely using includes it for free. What none of them has is the object being enforced — access scoped to a _task you declared_, bound to a branch, attributed to an _owner_ who can be asked, and ending on a clock. The zone model is agent-agnostic; this layer needs one small adapter per harness, and it has been seen to block in exactly one, Claude Code. The hook files `cycle init` writes for Codex, Cursor and Windsurf have never been exercised against a real install. The enforcing hook never touches the network. Grants and events are local files first; the backend coordinates and mirrors. A flaky connection can’t stop your day, and a dropped backend can’t open a zone. The plugin’s context hooks are a different thing: they ask the board for related tasks to show the agent, and they can only add context, never decide a call. ## What CC deliberately is not The spec carries an anti-features table, and it governs these docs too. CC never runs your code to prove anything — it demands evidence and checks it. The one exception is [`cycle discard`](https://commitcycle.com/docs/concepts/spike-mode/), which runs the `spike_cleanup` and `spike_verify` commands your own zone map declares. It does not host preview environments. It does not replace your tracker, and it does not integrate with one: intake is a form, an API endpoint (`POST /v1///tasks` with a title and a board credential) and an [MCP tool](https://commitcycle.com/docs/reference/mcp/), so a small bridge you write can file into it from whatever you use today. And the MCP server, which has since landed, is a client of the same API rather than a second door — **it is not the gate**. No tool approves an access request, and none decides a transition or reaches the hook, because an agent _chooses_ to call an MCP tool and enforcement has to be a capability boundary rather than a request. What a tool can do is ask the gate, and relay its refusal verbatim. The measured claims in these docs come from CommitCycle’s own task and audit records — the same records the product generates for its own development. Phase 0’s containment results, the fail-open finding, the hook’s latency budget: all of it is on the record, limits included, and the [three layers page](https://commitcycle.com/docs/concepts/three-layers/) states what was _not_ proven alongside what was.