The working loop

Every aigile team runs the same loop, whatever its size or level of automation.

The forward flow has seven steps. A human writes the intent. The feature is cut into slices. Each slice gets a one-screen spec. An agent builds the slice. The change is reviewed as one unit. A human checks the running software at defined points. A retrospective sorts what was learned into the right documents.

What each step looks like

To make this concrete, here is the whole loop on one feature. The example team builds order software, and a customer’s operations lead has asked for a view that supports her month-end work.

1. Intent. The human writes one paragraph and one sentence:

A billing administrator closing the month needs to see, per billing
entity, every order in the period, which invoice line it landed on,
and every order that did NOT land on any invoice, with the reason.

Success: the ops lead completes her month-end close without
exporting to Excel.
Out of scope: corrections. Read only.

Known requirements (facts, not guesses):
- unmatched reasons are exactly: pending, disputed, ingestion-failed
- periods are calendar months in the entity's timezone

The intent shown here is the light form, which fits a small feature. Larger features, meaning anything with a new user-facing surface or more than a few slices, use a fuller form in which the owner also writes a primary scenario (a concrete walkthrough of a named user doing the real thing), lists the behavior decisions that are made, names the decisions that are deferred together with the demo that will decide each one, and attaches a sketch for any new screen. The scenario is the important part, because a person cannot write one without thinking the feature through, and that is the point: with agents, building became cheap, so the filter against half-thought features moves from cost to a short readiness check on the intent. An owner who cannot walk their own scenario gets the intent back at the price of a conversation. The division of labor stays the same at every size: humans author decisions and scenarios, machines draft slicings and specs, and agents may question the owner but never invent behavior for them.

The known requirements list deserves a comment as well, because it answers a common question about this method. The intent is short, but it is not a substitute for writing requirements; it separates two kinds of them. Facts the human already holds go into the list, at any length, because each line costs a sentence now and would cost an interruption later. What nobody knows yet is left open on purpose, because a classical requirements document forces the author to invent answers to look complete, and invented answers harden into wrong specs. The open questions get answered by the loop instead, mostly at the demos, and become acceptance criteria at the point where they are cheapest to verify. Cross-feature business knowledge, such as how the customer’s invoicing works, lives in small human-written files that a slice declares and loads, the same way technical standards are handled on the artifact layers page.

2. Slice. The feature becomes five slices. Slicing follows two rules that take a little practice. First, slice by the question a user can now answer, never by technical layer. A draft like “backend endpoints, read model, table component, filters, integration” looks orderly, but no item in it can be shown to a user, so validation waits until the end. The accepted slicing for this feature reads instead: which orders were invoiced (slice 1), which are still pending (2), which failed and why (3), other months and entities (4), and how complete the month is (5). Each slice cuts thinly through all layers and can be demoed on its own, and the infrastructure a slice needs is built inside that slice. Second, size is a binary test rather than an estimate: one human can review the change in one sitting, and one agent can build it in one session. A slice that fails the test is split before work starts. The first slice is always a walking skeleton: the thinnest end-to-end cut, ugly but real. Here that means one entity, one month, matched orders only, a plain table, real data. The practitioner guide on the downloads page shows a full slicing session, including the rejected drafts.

3. Specify. Slice 1 gets a one-screen spec, with acceptance criteria written as tests wherever possible. The artifact layers page shows a full example of such a spec.

4. Build. An agent implements the slice, tests first. When it finds that the spec is wrong somewhere, it follows the deviation protocol rather than working around the problem quietly.

5. Verify. The change arrives as one unit: code, tests, and any spec changes together. A human reviews it in one sitting, which for a slice of this size takes around twenty minutes.

6. Validate. The human drives the running slice herself. In this example, the first small demo showed within five minutes that the table listed one row per invoice line, while the ops lead thinks in whole orders. Fixing this cost half a slice of rework. Discovered five slices later, it would have affected the whole feature.

7. Learn. After the feature is done, a short retrospective writes down what was learned. A wording that confused the agent becomes a written norm; a fact about the system that surprised everyone becomes a spec change.

The three paths back

The dashed lines in the figure carry learning in the reverse direction, and they are what distinguishes this loop from a small pipeline. When a wrong spec is found during the build, the fix to the spec ships in the same pull request as the code. When demo feedback arrives, it becomes spec changes before the session ends. And retro findings become written artifacts, because agents keep nothing in memory between sessions.

The steps marked purple in the figure, intent and validation, remain with humans at every level of automation. This is a design decision rather than a limitation of current agents, and the validation page explains the reasoning.

Full treatment: Why feedback beats upfront specs and Making review affordable. The complete example, artifact by artifact, is in the practitioner guide on the downloads page.