The I-7 Loop: A Working Method for Delegating to AI

You describe what you want. The agent starts building. A few minutes later six files have changed, something outside the request got refactored, and you are reading a diff to work out what you agreed to.

I-7 is a set of names for the points where that could have been decided instead of discovered. It is a working method used in this publication. It is not a standard, and nothing here establishes it as one.

The seven points

Intent. What is actually being asked for, in one sentence, including what is out of scope.

Inform. What context the work needs, chosen rather than dumped.

Interpret. The plan and the assumptions, stated back before anything runs.

Initiate. Execution inside a boundary that was agreed first.

Inspect. A human decision point: is this what we agreed, and may it proceed?

Intervene. Implementation stays inside the boundary, and a deviation returns to the previous point rather than continuing.

Iterate. Check what actually happened against what was declared, and keep the result.

The order matters more than the labels. Three of these happen before anything is built, one is a decision a person makes, and the last one is the only place you find out whether the work did what it said.

The five-minute version

The full list is a description. This is the part that gets used:

1. Write the intent in one sentence, including one thing that is out of scope.
2. Attach only the context the task needs.
3. Ask for the plan and the assumptions before execution.
4. Run it inside an explicit boundary, then check the result against that boundary rather than against the summary.
5. Turn one correction into something reusable: a test, a constraint, an example.

That takes a few minutes on a real task. Step three is the one worth not skipping, because leaving it out moves the disagreement from before the work to after it.

One implementation

The GoATee repository documents an I-7 operating model, grouping its seven stages into agreeing on the change, building within an approved boundary, and proving delivery. The mapping and the stage names live in its documentation; the code implements the corresponding mechanisms rather than being organised around seven named stages. In that implementation an approved agreement and an approved build budget are both required before the baseline commit is locked. The verification step gates on a comparison of the changed files against the approved budget, and stops before running any acceptance command when deviations are found. Criteria that need a person to look at them stay marked as needing review rather than passing quietly.

GoATee demonstrates one implementation of I-7. It does not establish I-7 as a standard, universal method, or empirically validated framework. One codebase shows that these points can be made explicit in software. It says nothing about whether the method helps anyone else, and there is no measurement here that would support that claim.

What this changes

Take the next task you are about to hand to an agent and spend two minutes on the first three points: what it is, what context it gets, and what the plan is. If the plan comes back different from what you meant, you have found the disagreement at the cheapest moment there is.

Where a person's approval is the whole point of a step, whether they can actually judge what they are approving is a separate design problem, and a gate nobody can evaluate is decoration.