Review and correct an agent's proposal before it builds

A product owner asks for a customer export. The engineer's agent drafts a proposal that looks reasonable until the product owner checks which records it includes.

This is an illustrative example, not a customer result or a measured time-saving claim.

The input

A connected repository, an agent-drafted proposal in Pathmode, and the original request:

The agent proposes:

The proposal defines something implementable, but a successful implementation would leave records out of the account review.

The product owner opens the proposal and reads the attached request. If the request was not attached by the agent, they use Attach the request to add its source title and original wording.

Under What the agent understood, they inspect the export behavior. The consequential question is which records belong in the file. Button placement can wait until that decision is clear.

They choose Correct beside the export behavior and write:

If the review offers this behavior as a recommendation, Use this recommendation prepares the wording for review. Describe another behavior lets them supply a different answer. They review and submit the correction before handing it back to the engineer.

The correction asks the repository agent to revise the proposal. It does not authorize a build or silently change the repository file.

The engineer asks the agent to pick up the open correction and revise the repository intent. While it has not been applied, the product owner sees that the correction is waiting or has been seen by the repository agent.

If the agent cannot apply it, the reported reason needs attention. A refusal is not a completed correction; the engineer and product owner resolve it before continuing.

After the agent applies the correction, the product owner returns to the proposal. Pathmode marks the behavior as changed after their correction. They read the actual revised wording and check that it includes both parts of the decision: all matching pages, with the active filters preserved.

They also inspect the surrounding scope, constraints, edge cases, and verification. For this example, the verification should include a filtered customer list that spans multiple pages and a check that the export includes every matching record and excludes nonmatching records.

Once the whole proposal reflects the intended change, the product owner authorizes implementation using the action above the review. This requires signed-in workspace permission and applies to that proposal revision.

Agreeing with a recommendation, leaving a guest comment, and getting a passing readiness verdict are different from authorizing implementation.

The engineer's agent builds from the authorized repository intent and runs the checks. The product owner reviews an export from the multi-page filtered list against the agreed behavior.

If the code passes its tests but the export still contains only one page, the requested outcome has not been met. If the build exposes a new limitation, record it and revisit the affected decision before treating the feature as complete.

The output

The team has the original request, a visible correction to the agent's interpretation, a revised proposal authorized by the product owner, and a specific check for the implemented result.

To start this workflow, follow Your First Intent in Pathmode. If your request is still in a document, see Turn an existing brief into a proposal you can review.