From an objective to a reviewed project change

This guide uses an illustrative task: adding a search filter to an existing project. It explains how to structure the work; it is not a benchmark, a claim that a live provider completed this example, or a promise that every task can run unattended.

1. Define what success looks like

Start with observable behavior. “Improve search” leaves too much room for interpretation. A better objective is: “Let users filter the saved-items list by name, keep the filter when they reopen the view, and show an empty state when nothing matches.”

List acceptance criteria before assigning the work. For this example, include matching behavior, persistence, any needed API changes and the tests that prove the result. Specify which project and branch the room should use. This gives the supervisor and reviewer the same contract.

2. Assign a supervisor, workers and a reviewer

The supervisor turns the objective into bounded tasks with clear owners and dependencies. A worker implements an assigned task. A different reviewer inspects the proposed output and its evidence. Using a second model for review can provide another perspective, but independence alone does not guarantee correctness.

Keep instructions specific. A worker responsible for the filter UI needs to know the API shape and persistence behavior. A reviewer needs the acceptance criteria and actual patch, not only the worker’s summary. Human review remains useful for product intent and behavior that automated checks cannot establish.

3. Choose turn-based or parallel work

Turn-based execution is useful when each step depends on the last: define an API, implement the interface against it, then review the integrated result. Parallel execution is useful when tasks have independent inputs and separate outputs.

For the search-filter example, an accessibility review of the current list can run alongside implementation. Two workers independently rewriting the same list component usually creates extra reconciliation work. Set a concurrency limit and record dependencies rather than assuming that more simultaneous model calls means faster delivery.

4. Work in isolated snapshots

An isolated task snapshot separates a worker’s proposed edits from the selected project. The worker can inspect files, implement the task and run relevant checks in that snapshot. Its proposed changes become reviewable output instead of silently becoming the project’s accepted state.

Isolation here is about project changes and integration. It is not an operating-system sandbox. Commands and provider tools still run with their configured permissions, so review the project selection and tool approval policy before starting work.

5. Review behavior and evidence

The reviewer should read the actual changed files and compare them with the acceptance criteria. For a saved-items filter, check name matching, reopening behavior, empty results and any API or data changes. Ask whether the tests exercise the user-visible behavior rather than merely mirroring the implementation.

A green unit test does not establish every kind of success. Browser interaction can verify the UI; live provider or service behavior requires its own evidence. If a check was simulated or could not run, retain that limitation in the review. Request changes when the proposed patch or its proof is incomplete.

6. Integrate the reviewed changes

Approval and integration are distinct. The selected project may have changed while a worker was busy. Source checks and conflict handling help avoid overwriting later work. A conflict needs reconciliation; a worker’s “done” message cannot make it safe to apply automatically.

After integration, run the checks appropriate to the resulting project state. Record what passed and what remains unverified. This closes the loop between the original objective, the patch that actually landed and the behavior someone can now use.

Handle stalls without losing the thread

A stalled provider can mean expired sign-in, a usage limit, a slow tool or a defect in the integration. Start with the recorded activity and incident evidence. Avoid blindly replaying a command when its side effects are uncertain, and distinguish an agent failure from an explicit human pause.

Agent Nextus has incident diagnosis and repair routing, but the appropriate response depends on the cause. Reauthentication may need the owner; a quota is not repaired by changing application code. Keep unrelated work separate from recovery and require evidence before claiming the stalled task has resumed.

What to read next

See the FAQ for provider accounts, privacy and distribution status, or return to the Agent Nextus overview. If you found this guide under the name Agent Nexus, the name explanation identifies the official product and website.