An agent’s check passed. The review is still yours.
Building a bounded permission and review flow with Primer React, an explicit state model, and inspectable evidence.
A green check is easy to overread. It can mean a process finished, a test passed, or a person approved a change. Those are different events.
I built Agent Review Desk to explore that distinction. It is an independent Primer React prototype with simulated repository activity. The task is deliberately small: inspect an agent’s work, decide whether it may read package metadata, and review the result.
A permission request needs a boundary
“Allow access” leaves too much to interpretation. In the prototype, the request states the destination, read-only access, and its lifetime: one check attempt. It also states what is excluded.
Denying access stops the check and preserves the patch. A timeout expires the permission. Retrying asks again. These details are part of the interaction model rather than text placed next to a generic confirmation button.
Completion does not imply review
The state model separates running, permission requested, denied, failed, canceled, waiting for review, and completed. A passed check produces the waiting-for-review state.
if (state.status !== 'waiting-review' || state.checks !== 'passed') {
return state;
}
return { ...state, status: 'completed' };
That guard makes the intended boundary explicit. It is tested separately from the visual interface. The complete model includes denial, expiry, and retry behavior.
Show evidence that can be inspected
The timeline contains actions and results. Selecting an event reveals what it means and what evidence is available. The patch remains in the workspace when a check fails.
This is an activity record, not a representation of a model’s private reasoning. The distinction matters: confidence in a narrative is weaker than the ability to inspect the relevant action or output.
What Primer’s MCP server helped with
I used the local Primer MCP server to retrieve component APIs, Button accessibility guidance, token guidance, and the Delegate pattern. The first broad token query returned no results. Its explanation of AND matching led me to narrow the search by group and intent.
The CSS lint tool returned an error summary without actionable details, so I did not count it as a pass. A local check validates the referenced variables against the installed primitives. I also checked the implementation against installed types and browser behavior. A tool response can guide a decision; it cannot establish that the resulting interface behaves correctly.
What still needs evaluation
A deterministic simulation makes edge cases easy to try. It does not prove that this design improves real pull-request reviews.
The next evaluation should ask developers to identify the change, explain the permission boundary, and recover from a failed check. The useful result will be where the interface confused them and what changed afterward.
Try the prototype, read the case study, or inspect the verification scope.