Six gates from request to release
Six gates stand between a request and a release
Follow one change through this playbook: Acme Inc's checkout squad asks for annual billing. It has to pass six gates on its way to release, and each step chapter frees it at one.
- Step 1, Boundary
Write the team rules
Without it, customer data ends up in chats.
- Step 2, Context
Put what your best people know where every agent reads it
Without it, everyone re-explains the job.
- Step 3, Skills
Turn your best way of working into skills anyone can run
Without it, the same task gets done four ways.
- Step 4, Execution
Run agents inside the rules
Without it, live work gets overwritten.
- Step 5, Verification
Make done mean the same on every team
Without it, reviewers reread everything.
- Step 6, Delivery
Ship through one path, with a named owner
Without it, nobody owns the result.
Why teams stall at Assisted
Everyone uses AI. Almost nobody wrote down how.
Most product and engineering teams already use AI every day. Few have written down how, so each person works their own way and delivery does not speed up.
The squad gets one request: launch annual billing. Four people each ask their own AI in their own way, and four different results come back. Nothing one of them learns reaches the rest.
75%
of knowledge workers use AI at work.
Usage is already there.
60%
of leaders worry their organization's leadership lacks a plan and vision to implement AI.
The written plan is what is missing.
Teams stall at the second stage, where AI is daily but private
The same change on the same track, at each of the four stages. Acme sits at Assisted: everyone uses AI every day, and the changes pile up in review because nothing is shared.
The way out is six layers your team writes into the repo
.agents/settings.json.agents/rules/customer-data.mdAGENTS.md.agents/rules/billing-service.md.agents/skills/launch-brief/SKILL.md.agents/skills/launch-brief/checklist.md.agents/skills/billing-change/SKILL.md.agents/skills/billing-change/plan-template.md.agents/agents/reviewer.md.agents/rules/testing.md.agents/skills/release/SKILL.md.agents/agent-memory/reviewer/MEMORY.md
Each layer is a few plain text files. Anyone can read them, copy them and improve them, the way open source works. The six step chapters write them one gate at a time.
Find your stage
Mark where each team is before anyone trains
Before you train anyone, write down where each team is today. A baseline turns "we use AI" into a stage you can move.
- 1
Is there one written rule, approved by a person, for what agents may see and change?
- 2
Does each task pull its context from one shared source that someone keeps current?
- 3
Are your best people's ways of working written down as skills anyone can run?
- 4
Does every piece of AI work pass agreed checks before a person reviews it?
- 5
Does every change ship through one path, with a named owner approving it?
Mark the team's stage
- Experimenting
- Assisted
- Governed
- AI-native
Mostly no means Experimenting or Assisted. Mostly yes means Governed. The assessment scores all six layers in two minutes. Take the assessment
- Who
- Heads of product and engineering, with each team lead
- How long
- Twenty minutes per team
- Pause point
- Nobody trains until every team has a stage marked.
Keep it current
Before you start Both heads agree on one goal before anyone writes a rule.
Six weeks later Mark the sheet again, so the change shows.
Step 1 of 6 Write the team rules
Agents go wherever nobody wrote a limit
The change stops at the first gate: nobody wrote down what agents may read, so customer records are as open as anything else. Boundary is what each agent may see and change, written down and approved by a person.
78%
of AI users bring their own AI tools to work.
Personal tools on company data is the risk the rules close.
What to do
- List the data each team works with, and mark what no agent may read.
- Write what agents may change, and where they must stop and ask.
- Have the heads of product and engineering approve it, by name.
Write it down: .agents/settings.json
- acme-checkout/
- .agents/
- agent-memory/1 file
- agents/1 file
- rules/
- billing-service.md
- customer-data.md
- testing.md
- settings.json
- skills/5 files
- AGENTS.md
- db/
- docs/
- exports/
- services/
- web/
- .agents/
.agents/settings.json
- {
- "permissions": {
- "allow": ["Bash(npm run test:*)"],
- "ask": ["Edit(db/migrations/**)"],
- "deny": [
- "Read(./.env*)",
- "Read(./exports/customers/**)"
- ]
- }
- }
.agents/rules/customer-data.md
- ---
- paths: ["services/billing/**", "db/**"]
- ---
- Agents read the seed copy in db/seed/ only.
- Names, emails and cards never enter a prompt.
- Approved: head of engineering, with legal.
- Who
- Heads of product and engineering
- How long
- About an hour
- Pause point
- Nobody pastes customer data into an agent until this file is approved.
Keep it current
Each quarter Read the rules again and sign them again.
A new data source arrives Add it to the file before any agent sees it.
- BoundaryGoverned
- ContextAssisted
- SkillsGoverned
- ExecutionGoverned
- VerificationExperimenting
- DeliveryAssisted
Step 2 of 6 Put what your best people know where every agent reads it
Agents start from zero when knowledge lives in heads
Past the first gate, the change stalls again: the agent never saw the decisions behind annual billing, so its code is generic. Context is the knowledge each task needs, kept in one place someone maintains.
61%
of developers spend more than 30 minutes a day searching for answers or solutions to problems.
Shared context gives that time back, to people and to agents.
What to do
- Pick the five documents every spec and change needs, and move them into the repo.
- Give each source a named owner who keeps it current.
- Keep AGENTS.md short: cut any line whose removal would not cause a mistake.
Write it down: AGENTS.md
- acme-checkout/
- .agents/
- agent-memory/1 file
- agents/1 file
- rules/
- billing-service.md
- customer-data.md
- testing.md
- settings.json
- skills/5 files
- AGENTS.md
- db/
- docs/
- exports/
- services/
- web/
- .agents/
AGENTS.md
- # Acme checkout
- Annual billing ships before usage pricing.
- ## Commands
- npm run test:billing (40 seconds)
- npm run lint
- ## Style
- Money is integer cents, never floats.
- Prices come from plans.ts, never typed.
- ## Gotchas
- Invoice numbers never skip or repeat.
- Read docs/decisions/ before a billing spec.
.agents/rules/billing-service.md
- ---
- paths: ["services/billing/**"]
- ---
- Call billing through its client, never its tables.
- Proration rounds down to the cent.
- Who
- Engineering lead, with the product lead
- How long
- Half a day for the first five sources
- Pause point
- An agent task starts only from sources with a named owner.
Keep it current
A decision changes Update the source the same day, in the same change.
Each month Delete what nobody read. Old context misleads.
- BoundaryGoverned
- ContextGoverned
- SkillsGoverned
- ExecutionGoverned
- VerificationExperimenting
- DeliveryAssisted
Step 3 of 6 Turn your best way of working into skills anyone can run
Four people do the same task four ways
Four people write the launch brief four ways, and each one comes out different. A skill is how your best people do a task, written down so every person and every agent does it that way.
4 in 5
people say they want to learn more about how to use AI in their profession.
Writing a skill on real work is how a team learns it.
What to do
- Pick one task your teams do every week, such as a launch brief or a billing review.
- Ask the person who does it best to write the steps, and what good looks like.
- Run it on a real task, then fix the skill from what the review found.
Write it down: the launch-brief skill
- acme-checkout/
- .agents/
- agent-memory/1 file
- agents/1 file
- rules/3 files
- settings.json
- skills/
- billing-change/2 files
- launch-brief/
- SKILL.md
- checklist.md
- release/1 file
- AGENTS.md
- db/
- docs/
- exports/
- services/
- web/
- .agents/
.agents/skills/launch-brief/SKILL.md
- ---
- description: Write a launch brief from a
- request. Use for any new plan or price.
- argument-hint: [request link]
- ---
- 1. Read AGENTS.md and docs/decisions/.
- 2. Name the customer, problem and goal.
- 3. List what changes for support and sales.
- 4. Run checklist.md before you hand it over.
- One page. A PM and an engineer start from it.
.agents/skills/launch-brief/checklist.md
- # Before you hand it over
- - [ ] Prices match plans.ts
- - [ ] Legal wording copied, not rewritten
- - [ ] Support has the answers a week early
- Who
- The person who does the task best
- How long
- One real task, then one fix
- Pause point
- Nobody else runs the skill until it has passed one review.
Keep it current
After each review Fix the skill with what the review found.
Each quarter Retire the skills nobody ran.
- BoundaryGoverned
- ContextGoverned
- SkillsAI-native
- ExecutionGoverned
- VerificationExperimenting
- DeliveryAssisted
Step 4 of 6 Run agents inside the rules
One big change on live work stalls everything behind it
The brief turns into one large change written straight onto live work, and nobody can review it in one sitting. Execution is how work starts from a request and runs in its own space, many tasks at once.
66%
of developers say their biggest frustration is AI solutions that are almost right, but not quite.
Small changes from clear requests are easier to get right.
What to do
- Start every agent task from a written request with its acceptance checks.
- Give each task its own branch or copy, never the live work.
- Keep changes small enough that one person can review them in minutes.
Write it down: the billing-change skill
- acme-checkout/
- .agents/
- agent-memory/1 file
- agents/1 file
- rules/3 files
- settings.json
- skills/
- billing-change/
- SKILL.md
- plan-template.md
- launch-brief/2 files
- release/1 file
- billing-change/
- AGENTS.md
- db/
- docs/
- exports/
- services/
- web/
- .agents/
.agents/skills/billing-change/SKILL.md
- ---
- description: Turn an approved brief into
- small billing changes.
- ---
- 1. Explore: read the brief, then the code.
- 2. Plan: one task per ten-minute review.
- 3. Implement each task on its own branch.
- 4. Write each task's test before its code.
- 5. Commit on the branch. Never on main.
- Stop and ask if a migration is needed.
.agents/skills/billing-change/plan-template.md
- # Plan: {brief title}
- ## Tasks, each small enough to review
- ## Tests written first
- ## Migrations: none, or ask a person
- Who
- Engineering lead, with one squad
- How long
- One launch, as a pilot
- Pause point
- Other squads start only after the pilot ships.
Keep it current
Each change Keep it small enough to review in minutes.
After the pilot Write down what the squad changed, then roll out.
- BoundaryGoverned
- ContextGoverned
- SkillsAI-native
- ExecutionAI-native
- VerificationExperimenting
- DeliveryAssisted
Step 5 of 6 Make done mean the same on every team
Without checks, every change waits for one reviewer
Small changes now arrive faster than one reviewer can read them, and the queue grows. Verification is the checks every piece of work passes before a person reviews it.
46%
of developers distrust the accuracy of AI tools.
33% trust it.
Checks earn trust one passed change at a time.
What to do
- Write down what done means for code, copy and data, in plain words.
- Turn each line into a check that runs before a person looks.
- Have a separate reviewer agent read each change cold, and send failures back.
Write it down: the reviewer agent
- acme-checkout/
- .agents/
- agent-memory/1 file
- agents/
- reviewer.md
- rules/
- billing-service.md
- customer-data.md
- testing.md
- settings.json
- skills/5 files
- AGENTS.md
- db/
- docs/
- exports/
- services/
- web/
- .agents/
.agents/agents/reviewer.md
- ---
- name: reviewer
- description: Reviews each billing change
- before a person does.
- tools: Read, Grep, Glob, Bash
- ---
- You did not write this diff. Read it cold.
- Check proration, currency and refunds.
- Run npm run test:billing and npm run lint.
- Send it back if a rule in testing.md fails.
.agents/rules/testing.md
- ---
- paths: ["services/**/*.test.ts"]
- ---
- Every bug fix ships with the test that
- would have caught it.
- Who
- Team leads, with the product lead
- How long
- One afternoon
- Pause point
- Loosen review only for checks that pass for two weeks.
Keep it current
Each week Track review wait and rework, so the change shows.
A bug reaches users Add the check that would have caught it.
- BoundaryGoverned
- ContextGoverned
- SkillsAI-native
- ExecutionAI-native
- VerificationAssisted
- DeliveryAssisted
Step 6 of 6 Ship through one path, with a named owner
Fast code still waits when nobody owns the release
The change passed every check and still waits, because nobody knows who signs off on billing. Delivery is one path from request to shipped, with a named owner approving.
Amplifier
is how the research describes AI's main role in software delivery: it magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.
One clear path is the strength worth amplifying.
Source: DORA, 2025 State of AI-assisted Software Development
What to do
- Draw the one path every change takes from request to release.
- Name the approver for each kind of change.
- Mark a layer as owned when a team runs it without help.
Write it down: the release skill
- acme-checkout/
- .agents/
- agent-memory/
- reviewer/
- MEMORY.md
- reviewer/
- agents/1 file
- rules/3 files
- settings.json
- skills/
- billing-change/2 files
- launch-brief/2 files
- release/
- SKILL.md
- agent-memory/
- AGENTS.md
- db/
- docs/
- exports/
- services/
- web/
- .agents/
.agents/skills/release/SKILL.md
- ---
- description: Ship an approved change.
- disable-model-invocation: true
- ---
- Only a person runs this. Agents cannot.
- 1. Check the reviewer passed the change.
- 2. Billing: the head of product approves.
- 3. Anything else: the engineering manager.
- 4. Release to 10% of accounts, then all.
- 5. Watch the first hour. Roll back on errors.
.agents/agent-memory/reviewer/MEMORY.md
- # What the reviewer has learned
- Upgrades to annual charged twice. Check it.
- Invoice numbers skipped once. Check it.
- Who
- Engineering manager
- How long
- One meeting
- Pause point
- A layer counts as owned only when a team runs it without help.
Keep it current
Each release A person runs the release skill. No agent can start it.
Tools change Review the files the same quarter.
- BoundaryGoverned
- ContextGoverned
- SkillsAI-native
- ExecutionAI-native
- VerificationAssisted
- DeliveryGoverned
Make it stick: train the people who keep it running
Training sticks when your leads write the files
The files stay useful only if people on your side can write and change them. Training works best on your own repo, on a launch you already planned.
- Week 1Your team: WatchesKaaS: Leads
- Week 2Your team: PairsKaaS: Leads
- Week 3Your team: PairsKaaS: Pairs
- Week 4Your team: LeadsKaaS: Reviews
- Week 5Your team: LeadsKaaS: Advises
- Week 6Your team: Runs itKaaS: Advises
- Week 2Your launch planned with the factory
- Week 6Your team ships it, and your approver signs off
39%
of people who use AI at work have had AI training from their company.
The other 61 in every 100 got none from their employer.
Your leads write the rules, skills and checks for their own teams, on a launch you already planned. By week six the team runs it, and the files stay with you.
Every layer has one named owner
Boundary Head of engineering, with legal
Context Engineering lead, with the product lead
Skills Product lead
Execution Engineering lead
Verification Team leads
Delivery Engineering manager
When someone leaves, the files stay, and so does the way of working. A new person, or a new tool, starts from what is written.
Questions leads ask
Short answers to what product and engineering leaders ask before they train a team this way.
What is an AI-ready team?
A team where the rules, context, skills and checks for AI work are written down in the repo, owned by named people, and used by everyone.
Do we need new tools?
No. The files are plain text in your repo and work with the tools your teams already use. They survive a switch.
Who should be trained first?
The leads who will own the files: a product lead and an engineering lead from one pilot squad.
Is this only for engineers?
No. PMs write the product context and the product checks, and use the same skills for specs and briefs.
What does open mean here?
Every rule, skill and check is a readable file. Your teams copy it, change it and review it like code.
How do we know it worked?
Take a baseline of cycle time, review wait and rework before you start, and report against it.
Terms
The terms this playbook uses, each in one sentence.
- Boundary
- What each agent may see and change, written down and approved by a person.
- Context
- The knowledge each task needs, kept in one place someone maintains.
- Skills
- How your best people work, written down so every agent works that way.
- Execution
- Work starts from a request and runs in its own space, many tasks at once.
- Verification
- Checks every piece of work passes before human review.
- Delivery
- A clear path from request to shipped, with a named owner approving.
- Experimenting
- People try AI on their own.
- Assisted
- Daily use, no shared rules.
- Governed
- Shared rules, named owners.
- AI-native
- Runs on AI, kept current.
- AGENTS.md
- The one short file every agent reads first: commands, house style and gotchas. Any agent tool reads it, or a copy under its own name.
- Path rule
- A rule file that applies only to the folders named in its paths line.
- Reviewer agent
- A separate agent that reads each change cold, with read and run tools only, before a person does.
- Agent memory
- What an agent learned on past changes, kept as a file the team can read and correct.
Train your team on your own repo
A custom training for your product and engineering teams, run on a launch you already planned. Your leads write the rules, skills and checks, and your team ships the launch the new way.
Training only your leads? See the cohort