Before a second agent, make one loop legible.

1. Name the result you want to see.

Start with a change for the user, rather than a list of tools. For example: find a project by name without scrolling through the whole list. That goal lets you judge the value even if the agent proposes a different implementation.

Then record the boundaries: what is included, what is outside the task, and which existing data or actions must be preserved. A short paragraph is often enough for a small change.

2. Give the agent a task with an ending.

A task should end in something you can inspect on its own. For project search, that could mean one field that filters existing names. Creating projects, changing their order and controlling agents are separate tasks.

You do not need to prescribe every line of code. Define the expected behavior and constraints, then leave implementation details to the agent within its authority.

3. Keep one readable queue.

Start with simple states: ready, in progress, in review and accepted. Give each task a short name, an expected result and a link to its context. A text file or the tracker your team already uses can be enough.

Separate the current task from ideas for later. If search work reveals a need for a new sort order, put that idea in the queue. Expand the current task only after explicitly revising its boundaries.

When an agent is blocked, record the specific question: what prevents progress, which options it checked and what decision it needs from a person. An explicit waiting state is more useful than repeated attempts without new information.

4. Review the change, rather than the activity.

Ask what changed, where you can inspect it and how it was checked. For an interface, view the working screen. For behavior, run the relevant scenario. For code, review a clear change set and checks proportionate to the risk.

An agent reporting completion is a cue to begin acceptance. Compare the result with the written checks, try adjacent actions and record remaining limitations. Iteration counts and long logs do not replace that review.

Distinguish saved code, a locally verified result, a published change and work you have accepted. These are different states; make the transition between them visible.

5. Agree where your decision is needed.

Before work begins, agree which actions the agent can take independently. Publishing, spending, handling credentials, deleting data and changing the working environment need clear authority boundaries. Account for permission you have already explicitly given.

If the next step exceeds that authority, the agent needs a concrete question with a reviewable decision. For example: publish the verified change to a named staging environment. Agreement to one task does not automatically expand access to everything else.

While waiting, preserve the result and context. Identify how to stop work safely and what can continue independently of the answer. Stopping behavior and retry limits depend on your tools; verify them before a long run.

6. Add parallel work where the boundaries are clear.

Give a second agent an independent responsibility, such as reviewing a completed change or working in a separate area. If two agents need to edit the same files, establish ownership and a handoff before they start.

Try one small pass from task to acceptance. Can you quickly answer what is happening, what has been checked, where a person is needed and what comes next? If so, you have a basis for another stream of work.

This is a starting point you can adapt to your own process. It does not require a particular tracker, editor or model. Add complexity when it helps you do and review the work.

Explore the Vabes product →