The Agile Agent Manifesto

1. 1

   Rules live in code, not in prompts

   If a rule can't break the build, it's a wish.

   AGENTS.md files and Copilot instructions help, but agents don't always follow them, and nobody notices when they drift from the code. A rule only counts when it can stop a change: a lint rule that fails the build, an architecture test that runs with the unit tests, a required review.

   $ npm run build
   ✖ src/booking/controller.ts:14:1  architecture/no-layer-skip
     Controllers must not import from db/. Use the repository layer.
   Build failed: 1 rule violation.

2. 2

   Make the code boring

   Homogeneous code is what agents build on.

   Agents copy what they see. When there is one way to build an endpoint, one way to handle errors and one folder structure, agents write code that looks like the rest. Invest in consistency first; every other layer depends on it.

3. 3

   Automate first, agents second

   Scripts for everything repeatable, agents for the rest.

   Use AI to write the scripts, generators and codemods that automate every repeatable task. A script does the same thing every time and costs almost nothing to run. Use agents for the work a script can't do.

4. 4

   The business writes code

   Business analysts and product owners open merge requests for what they know best.

   With an agent and a platform that turns a prompt into a merge request, BAs and POs change texts, configuration, feature toggles and features that follow an existing pattern themselves, in the repositories they are allowed to change. Nobody waits for a sprint to fix a label.

5. 5

   Refine by building

   Pair and build the story instead of only talking about it.

   A refinement meeting discusses work someone will do later. In an Agile Agent team, a developer and a BA pair online and build the story in that same time. The goal is a 3-point story built in the time refinement used to take.

6. 6

   Developers fly the plane

   Agents are the autopilot. Responsibility never moves to the agent.

   A developer reviews and approves every merge request, with AI help, and takes the controls when the autopilot fails. Architecture, security, performance and data migrations stay with developers.

7. 7

   Prove it, don't promise it

   Every change to how we work starts as a measured pilot.

   One team, six to eight weeks. Measure lead time, review time, change failure rate and production defects before and after, and decide with the data.

A developer approves every change. Code owners rules in the repository protect the red zone, and repository permissions decide who can open a merge request where.