Stewarded Loop Engineering: Moving Humans to the Right Part of AI Agent Loops

There is a lot of discussion right now about moving from prompting to loops.

Much of it frames the next step as greater agent autonomy: define the trigger, goal, tools, verification step, and stop condition, then let the agent run.

I understand the appeal. For stable, repetitive work, that is probably the right direction. If the task has a stable input, a stable process, and a clear output, there is no reason for a human to hover over every pass like an anxious project manager with a clipboard.

But that framing did not quite match what was happening in my own development workflow.

As models became better at implementation, especially with GPT-5.5, I found that my work was not disappearing from the loop. It was moving.

I was spending less time manually driving every step and more time clarifying intent, structuring context, writing implementation checklists, defining acceptance criteria, and reviewing what each pass revealed about the problem.

In other words, I was already working in loops.

They just were not autonomous ones.

For complex development work, the most valuable loop is often not fully autonomous. It is stewarded.

In a stewarded loop, agents implement and review work inside structured iterations, while a human continuously refines the problem statement, checklist, assumptions, constraints, and acceptance criteria between checkpoints.

The critic improves the answer.

The steward improves the question.

That is the distinction I want to name.

I call it Stewarded Loop Engineering.

Stewarded Loop Engineering is a human-guided AI development workflow where agents execute and review work, while a human steward maintains the evolving frame of intent: the problem statement, assumptions, implementation checklist, constraints, and acceptance criteria.

The goal is not to remove the human from the loop. It is to move the human to a better place in the loop.

I did not arrive at this by trying to design a framework

This came out of ordinary development work.

The better the models became at implementation, the more obvious it became that the scarce work was not always writing the code. It was making the task executable in the first place.

My workflow started to settle into a pattern.

I clarified the problem.

An agent helped me break it down.

I turned the breakdown into a checklist.

A development agent implemented against that checklist.

A reviewer agent critiqued the implementation against the same context.

Then I used the implementation and review to refine the checklist, assumptions, and acceptance criteria before the next pass.

That is a loop.

But the human is not outside it. The human is not merely approving or rejecting work either.

The human is stewarding the frame.

What the steward actually does

The word “steward” matters because this role is more specific than “human in the loop.”

A human in the loop may approve, reject, or intervene. That is useful, but it does not fully describe what happens in this workflow.

The steward owns the evolving intent.

That could be a tech lead, product engineer, staff engineer, founder, domain expert, product manager with technical fluency, or anyone else responsible for keeping the work aligned with the real problem.

The steward decides:

• whether the implementation matches the intended behaviour;
• whether the checklist was incomplete;
• whether an assumption failed;
• whether the problem needs reframing;
• whether a reviewer’s critique exposes a code defect or a deeper conceptual gap;
• whether the next loop should continue, stop, split, or be redesigned.

This is not micromanagement.

The steward should not be sitting inside every implementation detail. The point is not to manually drive the agent through every code change. The point is to intervene where judgement matters: intent, boundaries, trade-offs, assumptions, and the definition of done.

Agents are increasingly good at moving quickly.

Stewardship is about making sure they are moving in the right direction.

The payroll readiness example

I noticed this most clearly while working through an employee payroll readiness feature.

The requirement sounded simple:

Allow employee records to be imported or created with the minimum data required for an employee master record, while clearly flagging records that are incomplete for payroll processing.

That sentence hides a lot of complexity.

Employee master validity is not the same as employee payroll readiness. Employee payroll readiness is not the same as pay-run readiness. A missing field may be a blocking import issue in one context, but only a payroll readiness warning in another. The frontend may need to display missing information, but the backend should remain the source of truth. An imported employee may be allowed to exist while still being incomplete for payroll. A terminated employee may be complete as an employee master record, while still being excluded from a specific payroll run.

Those distinctions are not small implementation details.

They define the solution.

If I had simply asked an agent to “add payroll readiness checks,” it could easily have produced something plausible but wrong.

It might have made all employee-form required fields strict import blockers.

It might have duplicated payroll-readiness business rules in the frontend.

It might have solved only the missing fields observed in one import file instead of creating a reusable backend readiness policy.

It might have blurred the line between employee setup readiness and pay-run inclusion.

This is where the implementation checklist became critical.

The checklist defined the purpose of the work. It defined terminology. It separated employee master validity, employee payroll readiness, pay-run readiness, blocking import issues, and payroll readiness warnings. It made clear that employee creation and import should remain permissive enough for migration workflows, while still flagging records that were incomplete for payroll processing.

It also defined rules the agent did not get to reinterpret:

• do not make all employee-form required fields strict import blockers;
• keep the backend as the source of truth for employee payroll readiness;
• reuse the same readiness policy across imported rows, persisted employee records, APIs, and payroll preparation prechecks;
• do not duplicate payroll-readiness business rules in the frontend;
• return structured readiness issues so the UI can guide the user to the exact missing field or section.

The checklist removed ambiguity where ambiguity would have produced the wrong architecture.

The agent did not need to invent those decisions during implementation.

It did not need to decide whether payroll readiness belonged in the frontend. The checklist said it did not.

It did not need to decide whether readiness warnings should block import. The checklist said they should not.

And it did not need to guess whether cash payment should require bank details. The checklist described the payment-method-specific behaviour.

That is the point.

The checklist was not just a way of controlling the agent. It was a way of improving my own understanding of the domain.

Writing it forced me to separate concepts that were easy to blur. Reviewing the implementation forced me to test whether those separations actually held. The reviewer’s findings then gave me a way to refine the next pass.

The review was not just a quality gate. It became a learning mechanism.

The checklist as a contract of intent

In this workflow, the implementation checklist is not a casual task list.

It is a contract of intent.

Its job is to remove unnecessary assumptions and ambiguity before execution begins. It tells the development agent what must be done, what must not be assumed, which distinctions matter, which edge cases must be considered, and what acceptance criteria determine whether the work is complete.

It also gives the reviewer the same reference point.

The reviewer is not simply asking:

Is this code good?

It is asking:

Did this implementation satisfy the agreed problem statement, checklist, assumptions, nuances, and acceptance criteria?

That shared context matters. The implementation agent and reviewer are aligned around the same memory of how the problem was broken down. They share the same terminology, constraints, edge cases, and expected behaviour.

The prompt starts the work. The checklist governs it.

A simple checklist structure might look like this:

## Implementation Checklist

### Problem
What are we solving, and why?

### Key distinctions
Which concepts must not be blurred?

### Non-goals
What should the agent avoid solving?

### Assumptions
What are we treating as true, and what may need validation?

### Implementation rules
What architectural or behavioural constraints must hold?

### Required slices
Which backend, frontend, API, data, test, documentation, or migration areas must change?

### Edge cases
Which scenarios are easy to miss?

### Acceptance criteria
What must be true when the work is complete?

### Review instructions
What should the reviewer evaluate specifically?

The exact structure matters less than the discipline behind it.

The checklist should make intent explicit enough that the implementation agent is not forced to invent business rules while coding.

How to run a stewarded loop

A stewarded loop can be run as a practical operating model.

1. Write the problem statement

Start with the actual problem, not just the desired code change.

Bad:

Add payroll readiness checks.

Better:

Allow employee records to be imported or created with minimum employee-master data, while clearly flagging records that are incomplete for payroll processing without blocking migration workflows.

The second version gives the agent intent, not just activity.

2. Define non-goals and key distinctions

This is where many agentic workflows fail.

Agents are good at filling gaps. That is useful until the gap is a distinction you needed to preserve.

For the payroll example, the key distinctions were:

• employee master validity;
• employee payroll readiness;
• pay-run readiness;
• blocking import issue;
• payroll readiness warning.

Without those distinctions, the implementation could easily collapse separate concepts into one generic validation system.

3. Create the implementation checklist

Turn the problem into concrete slices, rules, and acceptance criteria.

This is the directive. There should be as little room for assumption as possible around the important parts of the work.

4. Give the same context to the implementation and review agents

The reviewer needs the same frame as the implementer.

If the implementation agent has the checklist but the reviewer does not, the review becomes generic. It may still find defects, but it is less likely to evaluate whether the implementation matched the original intent.

The reviewer should know the problem statement, key distinctions, constraints, edge cases, and acceptance criteria.

5. Ask the reviewer to classify findings

This is an important part of making the loop operational.

The reviewer should not simply return a list of issues. It should classify findings into categories such as:

• implementation defects;
• checklist gaps;
• assumption failures;
• acceptance criteria gaps;
• architectural concerns;
• test coverage gaps;
• unclear or conflicting requirements.

This classification changes the next step.

An implementation defect may go back to the development agent.

A checklist gap goes back to the steward.

An acceptance criteria gap may change the definition of done.

An assumption failure may require reframing the problem.

6. Hold the steward checkpoint

At the checkpoint, the human asks:

• Did the implementation follow the checklist?
• Did the reviewer find defects in the code?
• Did the reviewer expose gaps in the checklist?
• Were any assumptions wrong?
• Were any distinctions blurred?
• Are the acceptance criteria still sufficient?
• Should the next loop continue, stop, split, or reframe?

This is the moment that separates stewardship from approval.

The steward is not only deciding whether the work passes.

They are deciding what the next loop should understand better.

How this differs from generator and critic loops

Stewarded Loop Engineering includes generator and critic patterns, but it is not identical to them.

A generator and critic loop improves the artifact within the current frame. A stewarded loop improves the frame itself.

Generator/critic loop	Stewarded Loop Engineering
The generator produces an output	The implementation agent executes against a checklist
The critic reviews the output	The reviewer critiques against shared context and acceptance criteria
Feedback improves the artifact	Feedback improves the artifact and the task frame
The criteria are usually fixed during the loop	The criteria can be revised between checkpoints
The human may approve or reject	The human updates intent, assumptions, and definition of done

This is the core distinction:

A critic asks whether the implementation satisfies the current criteria. A steward asks whether the criteria were good enough.

That distinction matters because complex development work often teaches you something only after the first implementation exists.

Before implementation, the problem may feel clear in the abstract.

After implementation, the problem becomes visible.

You can see how the agent interpreted the checklist. You can see which parts were specific enough to execute correctly. You can see where the reviewer identified gaps. You can see where the acceptance criteria did not go far enough.

A failed implementation is not always a sign that the agent needs to try harder.

Sometimes it is a sign that the task needs to be understood better.

How this ties existing concepts together

Stewarded Loop Engineering is not a new primitive. It is a name for a coordination pattern that combines existing practices in a specific way.

Existing concept	What it contributes	What stewardship adds
Prompt engineering	Clear instructions	The prompt becomes part of a living frame
Context engineering	Relevant information	Context is updated after each loop
Loop engineering	Repeated agent execution	The human stewards intent at checkpoints
Generator/critic loops	Output review	Feedback also updates the checklist and criteria
Human-in-the-loop	Oversight and intervention	The human owns intent, not just approval
Spec-driven development	Specification as source of truth	The spec evolves through implementation feedback
Acceptance-driven development	Definition of done	Acceptance criteria improve as the loop reveals gaps

The value is not in pretending these ideas are unrelated.

The value is in connecting them into a practical development flow.

Failure modes

Stewarded Loop Engineering is useful, but it is not appropriate for every task.

Some work is too small to justify this much structure. If the change is simple, stable, and easy to verify, a normal prompt or short agent loop is enough.

The method also fails if the steward becomes too involved at the wrong level.

If the human reviews every small implementation decision, the loop collapses back into manual control. The steward should not micromanage the agent. They should intervene where intent, assumptions, trade-offs, or acceptance criteria need judgement.

Another failure mode is the bloated checklist.

A long checklist is not necessarily a clear checklist. Detail is useful only when it sharpens direction. If the checklist does not distinguish between core requirements, edge cases, non-goals, and acceptance criteria, it becomes noise.

Rubber-stamping is another risk.

If the human simply approves or rejects the reviewer’s findings, they are not stewarding the loop. Stewardship requires asking what the iteration revealed about the task definition itself.

There is also a risk that the implementation agent and reviewer share the same blind spots.

A reviewer with shared context is useful because it can evaluate whether the implementation matched the agreed intent. But sometimes a fresh reviewer is needed to challenge the frame from the outside.

Both types of review are useful.

One checks whether the work matched the intent.

The other challenges whether the intent was good enough.

Why this matters

AI-assisted development lowers the cost of implementation.

That changes where the bottleneck sits.

When code becomes cheaper to generate, the quality of the problem statement becomes more important. A vague request can produce a lot of code very quickly, but fast implementation of the wrong understanding is still waste.

The more capable agents become, the more dangerous ambiguous intent becomes.

This is why clarity, documentation, and stewardship become more valuable rather than less valuable. The agent can move quickly, but someone still has to decide what direction it should move in. Someone still has to notice when the definition of done is incomplete. Someone still has to distinguish between a bad implementation and a bad framing of the problem.

That feels like a better use of human judgement than manually driving every step.

The human should not be wasted babysitting every implementation step when their real leverage is maintaining the quality of intent.

That is the real shift.

As agents get better at producing code, the scarce human skill is no longer typing every implementation step. It is maintaining the quality of intent before the loop optimises toward the wrong thing.

The critic improves the answer.

The steward improves the question.