the labors — clinical summaries
Agents for clinical summaries.
This is the pipeline that carries the governance argument. Patient records live in Postgres and scan images live in object storage, and the report that comes back depends entirely on who asked for it. Two people issue the same prompt; one report contains fewer patients; the log shows exactly which decisions produced the difference.
Permission is not a filter applied afterwards
Scope is enforced at the proxy on every call, in the terms of the connector being called - a SQL row filter for the patient records, a key prefix for the scan images. The task body never sees data the requester was not granted, so there is no later stage where something could leak through.
The difference between two people's reports is therefore structural. It is not a rule someone remembered to write into a prompt, and no instruction given to a model can widen it.
What the pipeline touches
- Patient records in Postgres, read under the row filter attached to the requester's grant.
- Scan images in object storage, read under a key prefix and rendered into the finished report as Files.
Every denial is an event
A scope decision that excludes something is written to the run log the same way a successful read is. That is what makes the trail useful under scrutiny: you can show not only what a report contained, but what it was prevented from containing and why.
How the report gets built
An agent task composes a structured report specification from the permitted data, and that output is validated against its registered schema before anything downstream sees it. A deterministic render task then builds the page from the template and component library.
The agent's discretion is over content. The appearance is code polished once, which is why reports about entirely different subjects still come back looking like they belong to the same institution.
Put agents on your backend.
A 30-minute call. We map one workflow and show you the audit log by the end of it.