One client change, executed end to end by five specialised agents under a permission manifest, with a deterministic gate and a human approval step. Everything below is what actually happened.
Run 2026-07-15T13:20:53+00:00 on claude-opus-4-8.
Release: BLOCKED
19 of 21 executed tests passed. 2 requirement(s) ship now: R3, R4.
The verdict is derived from executed evidence and the router. No agent was asked whether the release looked ready.
A fictional insurer sends a messy onboarding email about a mental-wellness benefit for its corporate book. The benefit is six sessions a year, psychologist coaching only, with dependants excluded and cashless settlement inside the panel. The email leaves two questions open and asks for monthly per-employee utilisation reporting into the client’s HR dashboard.
Objective as the discovery agent read it:
Launch the Mind@Work mental wellness benefit for Meridian Assurance's corporate book: six psychologist-coaching sessions per member per year, no out-of-pocket cost when using panel providers, with monthly utilisation reporting to corporate HR. Target go-live is the 1st of the month.
Questions it sent back rather than guessing:
Every agent declares up front what it may read, write and decide. The right-hand column is enforced in code: an agent that reaches outside its scope is refused by the gate, whatever its prompt says.
| Agent | Writes | May not decide |
|---|---|---|
| discovery | brief.json | whether a requirement ships; data-protection verdicts; configuration vs build |
| build | build.json | whether a mapping counts as configuration, workflow change or integration (the router decides); enabling partner_reporting_feed (an egress capability, outside build scope); data-protection verdicts |
| qa | qa_proposed.json | whether a test passed; only the executed run decides that |
| dpo | dpo.json | whether a data flow is permitted (the boundary rule decides, and the model cannot override it) |
| release | release.json | the ship / blocked verdict (the evidence gate decides) |
| Agent | Tokens in | Tokens out | Seconds | Stop |
|---|---|---|---|---|
| discovery | 2255 | 1461 | 17.8 | tool_use |
| build | 3667 | 580 | 7.3 | tool_use |
| dpo | 3121 | 620 | 15.4 | tool_use |
| qa | 3117 | 2090 | 26.2 | tool_use |
| release | 3276 | 638 | 10.0 | tool_use |
The build agent maps each requirement onto a capability in the platform catalogue. It does not get to say what that mapping means: the router reads the catalogue and decides, and a requirement with an open question and no named owner fails closed rather than shipping on an assumption.
| Req | Requirement | Disposition | Why |
|---|---|---|---|
| R1 | Limit each member to six covered psychologist-coaching sessions per member per year. | blocked: pending answer | unresolved ambiguity with no decision owner; the question goes back to the client |
| R2 | Cover psychologist coaching only; exclude psychiatry and any service involving a prescription. | workflow change | Service type: psychologist coaching (non-prescribing): Service type exists in the catalogue but is not separable from the general mental-wellness service in the booking flow. Splitting prescribing from non-prescribing at booking is a workflow change rather than a config flag. |
| R3 | Restrict eligibility to employees of Meridian's corporate clients; exclude dependants (even where dependants are covered for GP). | configuration | Dependant eligibility flag is a plan-design field |
| R4 | Ensure members pay nothing out of pocket when seeing a panel provider, and do not authorise out-of-panel visits (which the insurer handles as a normal claim). | configuration | Restrict cashless settlement to panel providers is a plan-design field |
| R5 | Produce a monthly per-employee utilisation report for the corporate client's HR wellbeing dashboard, showing member name, NRIC, and number of the six sessions used, delivered as a monthly file. | blocked: prohibited | PHI_TO_EMPLOYER: Consent basis absent for the purpose; employer visibility of an individual's mental-health utilisation is a foreseeable harm to the data subject. |
blocked PHI_TO_EMPLOYER R5
Produce a monthly per-employee utilisation report for the corporate client's HR wellbeing dashboard, showing member name, NRIC, and number of the six sessions used, delivered as a monthly file.
Fields: member_name, member_nric, sessions_used, mental_health_utilisation → employer_hr_dashboard
Why it is refused. Consent basis absent for the purpose; employer visibility of an individual's mental-health utilisation is a foreseeable harm to the data subject.
The alternative the run offers instead. Aggregated, de-identified monthly counts (enrolled, sessions delivered, distinct members engaged), with any cell below the suppression threshold withheld. No member names, no NRIC, no per-member session counts.
The review agent, in its own words: For the stated purpose of HR seeing uptake and justifying spend, deliver an aggregate-only monthly file: aggregate_count of distinct members who used at least one session and total sessions_used across the workforce (suppressing small cells, e.g. groups under 5, to prevent re-identification). Drop member_name, member_nric, and per-employee mental_health_utilisation entirely. If HR's separate goal of following up with non-engaged individuals is confirmed and consented, that outreach should be run by the platform/insurer on HR's behalf using member_id_pseudonymous rather than exporting identifiable mental-health data to the employer.
The refusal is a rule, not a judgement call the model made and could be argued out of. The same input is refused the same way every time.
The standing suite plus the cases the QA agent proposed, every one of them executed against the rules engine. The agent stated what it expected; it has no field in which to report a pass. Only the executed run decides that.
| Case | Inputs | Expected | Actual | |
|---|---|---|---|---|
| pass | member, first session, in panel golden | member, psychologist_coaching, used 0, in panel | covered_cashless | covered_cashless eligible |
| pass | member, mid-benefit, in panel golden | member, psychologist_coaching, used 3, in panel | covered_cashless | covered_cashless eligible |
| pass | member, last funded session (5 used, 6th booking) golden | member, psychologist_coaching, used 5, in panel | covered_cashless | covered_cashless eligible |
| pass | member, out of panel golden | member, psychologist_coaching, used 1, out of panel | denied | denied out_of_panel: cashless settlement is not authorised outside the panel |
| pass | dependant, in panel golden | dependant, psychologist_coaching, used 0, in panel | denied | denied dependant_excluded: this benefit covers employees only |
| pass | TRAP: cap boundary (6 used, 7th booking) trap | member, psychologist_coaching, used 6, in panel | denied | denied cap_exhausted: annual session cap reached |
| pass | TRAP: cap overshoot (state says 7 used) trap | member, psychologist_coaching, used 7, in panel | denied | denied cap_exhausted: annual session cap reached |
| pass | TRAP: psychiatry booked under a coaching benefit trap | member, psychiatry, used 0, in panel | denied | denied service_not_covered: prescribing services are out of scope for this benefit |
| pass | TRAP: unrecognised service type trap | member, physiotherapy, used 0, in panel | escalate | escalate unknown_service_type: 'physiotherapy' is not in the plan's covered list |
| pass | TRAP: dependant at the cap boundary trap | dependant, psychologist_coaching, used 6, in panel | denied | denied dependant_excluded: this benefit covers employees only |
| pass | Member, prescription_review, in panel, mid-benefit proposed | member, prescription_review, used 2, in panel | denied | denied service_not_covered: prescribing services are out of scope for this benefit |
| fail | Member, physiotherapy, in panel proposed | member, physiotherapy, used 0, in panel | denied | escalate unknown_service_type: 'physiotherapy' is not in the plan's covered list |
| pass | Member, psychiatry, in panel, at last funded coaching session proposed | member, psychiatry, used 5, in panel | denied | denied service_not_covered: prescribing services are out of scope for this benefit |
| pass | Member, psychologist_coaching, out of panel, first session proposed | member, psychologist_coaching, used 0, out of panel | denied | denied out_of_panel: cashless settlement is not authorised outside the panel |
| pass | Member, psychologist_coaching, out of panel, at cap proposed | member, psychologist_coaching, used 6, out of panel | denied | denied cap_exhausted: annual session cap reached |
| pass | Dependant, psychologist_coaching, out of panel, first session proposed | dependant, psychologist_coaching, used 0, out of panel | denied | denied dependant_excluded: this benefit covers employees only |
| pass | Dependant, psychologist_coaching, in panel, mid-benefit proposed | dependant, psychologist_coaching, used 3, in panel | denied | denied dependant_excluded: this benefit covers employees only |
| pass | Dependant, psychiatry, in panel proposed | dependant, psychiatry, used 0, in panel | denied | denied dependant_excluded: this benefit covers employees only |
| pass | Member, psychologist_coaching, in panel, 4 used (5th booking) proposed | member, psychologist_coaching, used 4, in panel | covered_cashless | covered_cashless eligible |
| fail | Member, psychologist_coaching, in panel, 6 used but open question unresolved (7th) proposed | member, psychologist_coaching, used 6, in panel | escalate | denied cap_exhausted: annual session cap reached |
| pass | Member, prescription_review, out of panel proposed | member, prescription_review, used 0, out of panel | denied | denied service_not_covered: prescribing services are out of scope for this benefit |
The 2 disagreements are the useful part.
Neither is a broken rule. In both, the QA agent expected something the engine does not do, and in both the gap is a policy question nobody has answered.
The seventh-session case is the one to look at. The client asked what happens at session seven and never answered it. The engine quietly denies. That is a decision nobody made, sitting in production code, and it took an executed test to surface it. It is why the release is blocked.
Hadi Al-Hazim at 2026-07-15T13:20:43+00:00
Approved:
Not approved: R5
Reviewed the executed evidence and the escalation before release. The blocked flow is not a bug to be worked around; it goes back to the client with an alternative.
A run should also leave the delivery system stronger. This is the rule the engagement earned, written so it fires on the next client before the same problem recurs.
New intake rule. If a requirement asks for individual-level health or mental-health utilisation (member name, NRIC, or per-person session counts) to be sent to an employer or any party other than the member and their clinician, flag it at intake and require written confirmation of the consent and legal basis before any build begins; absent that, scope it as an aggregate, de-identified feed with small-cell suppression from the start.
New regression case. phi_per_employee_mental_health_export_to_employer_blocked_without_consent
This engagement is blocked for now, with two of the five requirements ready to configure and ship: R3 (excluding dependants from eligibility) and R4 (cashless settlement restricted to panel providers) are both plan-design changes and are good to go. R2 (covering psychologist coaching only, excluding psychiatry and prescriptions) is achievable but needs a booking-flow change rather than a simple setting, because today the catalogue does not separate prescribing from non-prescribing mental-wellness services at the point of booking. R1 (the six-session annual cap) is held pending your answers on what happens at session seven and how mid-year joiners are treated, and we also need to know whether the limit is measured on a calendar year, policy year, or rolling twelve months. R5 (the monthly HR report) cannot be delivered as written: sending identifiable individual mental-health utilisation with name and NRIC to employer HR has no confirmed consent or legal basis and creates a real risk of harm to members — we can instead deliver an aggregate, de-identified monthly file (distinct members who used at least one session and total sessions, with small groups suppressed), and if HR needs to follow up with non-engaged members, we can run that outreach on their behalf without exporting identifiable data.