The AGENTS.md context block

Most teams running coding agents end up maintaining context by hand: a personal Obsidian vault, a CLAUDE.md that drifted three sprints ago, an AGENTS.md somebody wrote once. It is per-person work that produces per-person answers — the same question gets a different agent response depending on whose machine it ran on.

CC generates that context instead. cycle sync maintains a block inside AGENTS.md, derived from the same zones.yml the whole team reviews like code and from whichever task is currently open.

What it looks like with nothing open

This is CC’s own AGENTS.md between sessions, trimmed of one team-specific deploy note:

<!-- cc:begin -->
## CommitCycle

### No task is active

Nothing is open. Writes to the paths below will be denied until a task passes
the gate and binds itself to a branch.

### Where the tasks are

This repository answers to the board `pow/commitcycle` at
https://dash.commitcycle.com. Tasks, their specs and the record of what was
decided live there, not in this repository — `.zones/board.json` is the binding.

Nothing starts by editing files: a task is filed, scoped with four answers, and
passes the gate, which is what issues the branch and opens whatever it is
allowed to touch.

### Protected zones

- **Database schema** (`schema`, deny): apps/api/migrations/**, apps/api/src/db/schema/**
- **Shared contracts** (`contracts`, deny): packages/contracts/**
- **Enforcement layers** (`enforcement`, deny): packages/hook/**, packages/action/**
- **Brand and design system** (`brand`, read-only): .claude/skills/cc-brand/assets/brand/**, …

If you are blocked, do not look for another route. Ask for access with a reason
and an alternative, or carry on with the rest of the task and report the block.

Everything not listed above is unprotected *inside an active task*. There is no
task here, so that opens nothing: writes are denied everywhere — unprotected paths
included — until a task passes the gate and binds itself to a branch.
<!-- cc:end -->

The phrasing of the idle state is deliberate. It does not say “nothing is open, so you’re fine” — an agent with no task should expect to be stopped, and the last paragraph closes the loophole a shorter block once left open: “unprotected” describes what needs no approval inside a task, never a place to work without one.

The enforcement admission only appears when it is true. On a repository where no binary is installed, the block gains a section this one does not have — “Nothing here is enforcing this” — saying in so many words that no write will be blocked and the diff is checked at close instead. A context file that describes rules while staying silent about whether anything checks them is how a repository ends up believing it is guarded; this is the layer that has no teeth admitting which layer is missing.

What it looks like with a task in progress

When a grant exists, the block gains the task half:

### You are working on CC-42 — The audit trail page

Branch `task/CC-42-the-audit-trail-page`. Access expires in about 4 hours.

**What it should do.** Render the per-task audit record as a page a skeptic can read.

**What it must NOT do.** Do not change what the closing gate accepts as evidence.

**Open to you right now**, and nothing else:

- `schema` — write: apps/api/migrations/**, apps/api/src/db/schema/**

**Read before working** — the playbooks for this task's topics:

- .zones/playbooks/frontend.md

**Closed to this task.** You may not write there — nothing is stopping you, so this
one is on you:

- `contracts` (deny): packages/contracts/**
- `enforcement` (deny): packages/hook/**, packages/action/**

Non-goals are in there on purpose. “Don’t touch the pricing logic” is worth considerably more sitting in the agent’s context than in a ticket nobody re-reads.

Two details in there are worth naming. Read before working appears when the task declared topics that have playbooks — what earlier work on this subject already learned, handed over before the work rather than after the mistake. And the closed-zone wording changes with the enforcement state: where nothing is watching, it says so in the same sentence that states the rule, because a rule that pretends to be a wall teaches an agent that walls are negotiable.

The two rules that shape it

It is generated, so it is delimited. Everything between <!-- cc:begin --> and <!-- cc:end --> belongs to CC; everything outside is yours and is never touched. A tool that rewrites a file people also edit has to be able to say exactly which bytes are its own. There is one block no matter how many times sync runs, and a sync that changes nothing does not rewrite the file.

The task half disappears with the task. cycle submit clears it in the same breath as removing the grant. A stale “you have write access to billing” left in context after the grant expired is worse than no context at all — it is confidently wrong, and it is the first thing the agent consults when deciding whether to try.

The zone list survives both states. It is true whether or not a task is open.

Why AGENTS.md and not CLAUDE.md

AGENTS.md is the cross-tool convention, and CC writes nothing tool-specific. A team running two different agents should not maintain two files that have to agree.

This layer has no teeth, by design

Layer 1 cannot stop anything. It exists because Layer 2 is a blunt instrument: a hook that denies a write costs a round trip and a confused apology, and most of those are avoidable by saying so up front.

If Layer 1 and Layer 2 ever disagree, Layer 2 is right. The block is a courtesy to the agent, not a source of truth about what is permitted.

What this does not solve

It does not make the agent obey — nothing advisory does. It does not carry your architecture notes, your ADRs or your onboarding guide; every section in it is derived — the open task, the zone map, the board this repository answers to, and whether anything is enforcing it — and none of them is a section you maintain. And it does not replace a knowledge base: if your team keeps design context somewhere, keep it there. What CC removes is the part that describes boundaries, because that part can be derived from a file you already maintain and should never have been transcribed by hand.