What the Guardrails Caught: Two Days of Agent Work on a Health-Data Project

AI agents are quick, and quick is not the same as safe. The question that matters on a sensitive project is what stops an agent from making a bad call and having it go unnoticed. This is how we ran agents on a pre-launch health-data product, the review gates that caught real mistakes, and the one place the process still stopped us.

The project

A product we are building that lets people give and withdraw consent for apps to read their health data, and keeps a record of every access. It is pre-launch, so we are not naming it yet. It is a demanding setting for agents: the law is unsettled in places, a wrong design choice is expensive to undo, and a model should never decide a legal question.

Over 22 and 23 October 2026, fourteen pull requests were merged. All of it was documents, specifications, a plan and automated checks. There is no product code yet, so this says nothing about how fast agents write software. It is about keeping them accountable.

The rules

• One item at a time. A board holds the queue. Each run claims one item, works it, and stops.
• Agents advise, people decide. Questions that are really decisions (architecture, naming, what to put to a lawyer) are written up with options and left for the owner. No agent decides them.
• A second, specialised review before merge. Anything touching consent, access or audit goes past a compliance-minded reviewer. Anything touching CI or permissions goes past a security reviewer.
• Checks run from the trusted side. The CI check runs the version of the script from the base branch, so a pull request cannot weaken its own check.

What the reviews caught

• Missing risk rows. The first draft of the privacy impact assessment outline left out some risks and legal regimes. The compliance pass found them.
• Safeguards dropped in a split. A large task was split into five smaller ones, and the split quietly lost three safeguards: deny by default when a check fails, honouring a withdrawal immediately, and keeping the audit record minimal. The reviewer caught it, and they went back in as explicit acceptance criteria before the work was filed.
• A check that could be bypassed. Our first CI script ran from the pull request, so a pull request could edit the script that was meant to check it. The security review flagged it. The fix was to run the script from the base branch, and in the same revision it now scans every tracked file instead of a list of file types.
• A decision that contradicted itself. When the owner decided to log both consent and every read, the first edit updated one document and left three others saying something different. The compliance reviewer found the conflicts, and they were fixed in the same pull request.

What went wrong anyway

The tooling's safety classifier refused to let the agent merge its own pull request: there was no written permission for it and no CI to rely on. We did not look for a way around it. We found the cause, added the CI check and an explicit standing rule, and the next merges went through.

What we took from it

The agents were fast and the reviewers caught real mistakes, but none of it would have counted without the structure around it: written gates, a second reviewer with a different brief, checks that cannot be edited by the thing they check, and a person who makes every call that is genuinely theirs. That structure is what we help teams build.