What an internal PR-review agent actually needs
Atlas reviews pull requests every day at a bank. The permissions model, the audit trail, and the parts nobody asks for until they are missing.
Atlas is an internal agentic CLI for pull-request review and backlog work that I designed and built at Nationale-Nederlanden. It is in daily use by the team. The interesting part of that sentence is not the model — models are replaceable — but the requirements that only show up once an agent touches a regulated delivery process every day.
The permissions model
An agent in a bank starts with a trust problem, correctly. The answer is not a policy document; it is the permission surface:
- Read widely, write narrowly, by construction. The agent can read the repository and the review context. Everything that mutates state — posting a comment, changing a label, opening a ticket — is a separate, explicitly scoped capability, and the default is off.
- Scopes are attached to the task, not the agent. A review run that only needs read access cannot post, no matter what the model decides. Granting is a deployment decision, not a prompt away.
The audit trail
The second requirement is being able to answer, months later, what the agent did and why. Every run records its input, its tool calls, and its output as structured events. A review comment produced by an agent is attributable the same way a human comment is — which reviewer-approved process produced it, on what input, at what cost. If your agent framework cannot produce that log, you do not have an agent you can run in a regulated process; you have a demo.
The parts nobody asks for until they are missing
- Idempotency. Runs get retried. An agent that re-posts its review on every retry trains the team to ignore it.
- Cost visibility per run. The team will not adopt what they cannot price. Each run reports tokens and dollars, which turns "can we use this everywhere?" into arithmetic.
- A stop that works. A run that is going sideways needs a boundary — a budget, a step limit — that does not depend on the agent noticing its own confusion.
None of this is specific to review agents. It is the difference between an agent that impresses in a demo and one a team will let into their daily workflow.