An agent is a caller, not a new layer.
An agent is not a privileged system with inside access. It uses the same platform a person does: the same services, the same actions, governed by the same permissions and the same accountability. There is no agent-only way to change the record and no agent-only exception to the rules.
An agent's authority is a strict subset of the authority of the human or service it acts for, and every exercise of that authority is recorded.The principle the agent surface is built to.
The same actions, the same rules. An agent does not receive a special catalogue of powers. It receives the published actions, each already bounded, documented and individually permitted, which is exactly what a safe tool should be. A general "do anything" capability is precisely what an agent never gets.
Described once, understood by everyone. Because every action is declared in the contract, the description a person reads, the one the clinical application is built from, and the one an agent is given are the same description. The clinical application is built from it today; handing agents that same description is the next step.
| What an agent can do | How | Status |
|---|---|---|
| Read the record and search it | The same way a clinician's screen does, limited by the agent's permissions and the patients it may see | implemented |
| Take a named action | Booking, tasks, referrals, medications, notes, with the platform's rules applied and the related changes made together | implemented |
| Ask what the record said at an earlier time | Every version of every record is kept | implemented |
| Follow a patient, task or appointment | Live updates as the record changes | implemented |
| Act for a person with less than their full authority | Bounded delegation: a subset of the person's permissions, patients and actions | direction |
| Receive its list of allowed actions automatically | Derived from the contract and filtered by what the agent is permitted to do | direction |
Four bounds on delegated authority.
An agent never holds standing authority over patient data. It acts on behalf of a person, a clinician in session, or a service, a scheduled integration, with authority that is a bounded subset of theirs. The design bounds it in four ways.
Scope. Which kinds of record it may read or write, never broader than the person it acts for.
Patients. Which patients, visits or care teams it may touch, enforced exactly as it is for a person.
Purpose. A declared purpose of use, treatment or operations for example, that travels with every call and lands in the trace.
Time. A validity window tied to the session or task, so a delegation cannot outlive the reason it was granted.
The rule to hold in mind: a delegation is an attenuation, never an amplification. The platform must be able to refuse an agent an action the person themselves could not take. The delegation model is designed and not yet built; what exists today is the requirement that every non-patient change names a responsible clinician, which is the hook delegation attaches to.
Memory that can be audited.
An agent's memory on this platform is the record, not the model. Because every version of every record is kept, an agent can ask what is true now and what was believed at an earlier time: when a result first arrived versus when it was acted on, how a problem list evolved. Every fact it reads carries where it came from, so a draft can cite the records it relied on and a reviewer can trace each claim back.
Grounding that comes from the record rather than from the model's parameters is reproducible: the same question at the same point in the record's history returns the same answer. It is also bounded: the agent reads through the same permitted surfaces as everything else, so its context is limited by policy and, as the audit work completes, recorded like any other read.
Proposals a person accepts.
The visit note is where people and agents meet. It is a collaborative document: several editors at once, changes merged as they happen, and suggestions as a first-class kind of content. That is the natural channel for an agent's proposal. The agent proposes a section or an item; the clinician accepts, edits or discards it; acceptance is the write, and it goes through the same named action and the same permission check as a clinician's own entry.
Structured records live inside the narrative too, so an agent proposing a diagnosis or a referral is proposing a record, not a paragraph. Dictation is the on-ramp: speech becomes a transcript, the transcript becomes assistance, assistance becomes a suggestion, and a person decides. The collaborative note with suggestions is built; the review step that lets an agent propose a named action without approving it is direction.
No trace, no action.
Every agent read, proposal and applied change is meant to land in the same trace as a person's, naming the agent, the person or service it acted for, the permission decision and the purpose. For agents there is more to record than for people: which model and version, what context it was given, and which records it relied on. The position is that an agent action must be at least as traceable as a human one, never less. An agent surface that cannot be traced is not a permitted surface.
An assistant helping with a visit.
Consider an assistant working alongside a clinician during a visit. Each step needs a supported interface and an explicit permission. The steps are in the order the work happens.
-
Read the relevant history
Problems, medications, prior results and the notes from the last two visits, limited to this patient and this clinician's authority.
Uses reading and searching the record, with its history. implemented
-
Contribute a draft to the note
An assessment section the clinician can accept, edit or discard, in the same document they are already writing in.
Uses the shared note and section capture. implemented
-
Prepare a referral for review
A cardiology referral created as a draft, with the reason and the note filled in, for the clinician to approve.
Uses the create-a-referral action, as a draft. implemented The review step that lets an agent propose without approving is direction.
-
Follow the result into the next task
When the referral is accepted or a result lands, the assistant sees it and moves the follow-up task along.
Uses live updates and the task actions. implemented
We are building toward that connected workflow. The interfaces for each step exist; complete agent workflows across them, with human review and attributable outcomes, remain to be demonstrated.