Agent, Copilot or Automation: The Distinction That Decides Your Governance

An AI agent is software that is given an objective rather than an instruction, decides for itself which steps to take, uses tools and systems to take them, and reaches an outcome without a person approving each intermediate action. In a healthcare setting that usually means it reads from and writes to real systems: an EHR, a scheduling platform, a payer portal, a phone line.

Four properties have to be present before the word is doing any work:

1. Goal direction. It is told what outcome to reach, not which buttons to press. "Obtain authorisation for this procedure" rather than "submit form X to portal Y".
2. Action selection. It chooses among available steps, and different runs of the same task can legitimately take different paths.
3. Tool use. It can call systems, read state and change it. Software that only produces text is not an agent regardless of how it was built.
4. Completion without step by step approval. A human may set the objective and may review the result, but is not consulted between steps.

That last property is the one that changes everything downstream. It is the difference between a system whose errors are caught by a clinician before they have any effect, and a system whose errors reach a payer, a patient or the record.

The term is used loosely by vendors, and often for products that are copilots with a scheduler attached. That imprecision is not just marketing noise: it determines which controls your organisation is obliged to build, which is why the definitions below are worth arguing about.

Robotic process automation is software that repeats a fixed sequence of user interface or API actions. It has no model of the task. It clicks where it was told to click, in the order it was told, and it fails when the screen changes.

Healthcare has run on it for a decade, mostly invisibly, in revenue cycle: eligibility checks, claim status polling, posting remittances, moving data between systems that have no interface to each other. It is unglamorous, it is deterministic, and its failure mode is the most benign of the three. When an RPA script breaks, it stops. It does not improvise.

That determinism is a genuine feature and it is being discarded too quickly. If a task is high volume, fully specified and stable, RPA is cheaper to run, easier to audit and easier to validate than anything model based, and its output is reproducible. A queue of eligibility checks does not need judgement.

Its limits are equally clear. RPA cannot read an unstructured denial letter, cannot decide which of four clinical documents supports a medical necessity argument, and cannot handle the long tail of exceptions that consumes most of the staff time in revenue cycle work. That long tail is exactly where the newer approaches earn their keep, and it is also where the risk lives.

A copilot produces a proposal that a human accepts, edits or rejects before it has any effect. The model does the drafting; the human does the deciding; the human's decision is the only thing that reaches the world.

Most of what is deployed in healthcare today is a copilot, including the highest volume categories. An ambient documentation tool drafts a note and a clinician signs it. A coding assistant suggests codes and a coder accepts them. A draft reply in the clinical inbox is a draft until somebody sends it.

The copilot pattern is popular for a reason that is often mistaken for timidity. Human review is a real control. It bounds the failure mode: a bad draft costs review time rather than causing harm, which is why copilots have been able to scale in clinical settings faster than anything more autonomous.

But the control is only as good as the review, and this is the part organisations consistently overestimate. Reviewers who see mostly correct output stop reading closely. That degradation is predictable, it accelerates as quality improves, and it means a copilot's safety argument depends on an assumption about human behaviour that erodes over time. Any governance case that rests on "a clinician reviews it" needs a mechanism to check that the review is really happening, which in practice means measuring review time and auditing samples rather than trusting the attestation. We describe what that loop looks like in the clinician adoption playbook.

The distinctions that matter operationally, side by side.

Read the table by column and one thing stands out: the technology dimension and the risk dimension do not move together. An RPA bot writing directly into a chart can be riskier than a copilot drafting a letter. Sophistication is not the variable. Autonomy over consequential actions is.

Not at the model. Ask two questions instead, and they separate the categories more cleanly than any architectural description a vendor will give you.

Question one: what does this system do without asking? Not what it can do, what it will do unprompted. If the answer includes anything that reaches a patient, a payer, a chart or a schedule, you have an agent, whatever it is called.

Question two: what is the last human decision before the effect? Trace it precisely. In an ambient documentation deployment it is the signature, and that is a real gate. In an autonomous outbound calling deployment it is the decision to enable the campaign, which happened weeks ago and covered thousands of calls. That is a very different kind of gate, and it is the honest description of what you approved.

Two intermediate patterns cause most of the confusion. Supervised autonomy is an agent that acts freely within a bounded envelope and escalates outside it: it books appointments in open slots but routes anything requiring an override to a human. It is genuinely safer than unbounded autonomy, but the envelope is now a safety control and needs to be specified, tested and monitored like one. Batch approval is where a human approves a hundred actions in one click. It is autonomy with a signature attached, and treating it as human review is the most common way an agent gets governed as a copilot.

The useful mental model is not a three way classification but a spectrum of how far the human sits from the consequence. Categories are shorthand for positions on that spectrum, and the shorthand fails at exactly the points where vendors like to sit.

Because the controls that make a copilot safe do not exist in an agent deployment, and the controls an agent needs are ones most health systems have never built.

Three requirements on the agent column deserve emphasis because they are the ones organisations discover late.

The kill switch has to be tested. Every agent deployment should have a documented way to stop it inside minutes, exercised before go live, with a named person who can invoke it at three in the morning. Untested kill switches are a well established category of not working.

Accountability has to be assigned in advance. With a copilot, the person who signed the note is accountable and everyone understands that. With an agent, no individual approved the action, so accountability defaults to whoever is left holding it unless it was assigned. This belongs in the intake process described in our AI governance committee playbook.

The regulatory position may differ. A system that only drafts what was said sits differently from one that recommends or acts on clinical decisions, and where that crosses into FDA regulated device territory is a question to answer in writing before deployment, not after. Certification transparency obligations under HTI-1 and, for organisations with European exposure, the risk classification approach in the EU AI Act both key off what the system does rather than how it was built.

Vendor language has converged on "agent" because it prices better, so ask about behaviour rather than architecture. Six questions that sort the market quickly:

1. Name every action this system can take in our systems without a human approving that specific action.
2. Can it take an action we did not anticipate, and what bounds that?
3. When it is uncertain, what does it do? Escalate, guess, or stop?
4. Show me the action log for a single completed task, as we would receive it.
5. What is our kill switch, how fast is it, and who can invoke it?
6. Which actions are reversible, and what does the reversal process look like?

Question three separates products more sharply than any other. A system that stops and escalates on uncertainty is engineered for a clinical environment. One that proceeds on its best guess may be perfectly good at scheduling and completely unsuitable for anything touching clinical content.

Question four is the one vendors dislike, and the answer tells you whether the product was built to be governed. If the log is a marketing dashboard rather than an exportable record of inputs, actions and outcomes, you cannot audit the system and you should assume you never will be able to. That belongs on the checklist during vendor selection alongside the compliance screen in our pre demo HIPAA checklist.

Take prior authorisation, which spans all three cleanly.

The RPA version logs into the payer portal, checks status on submitted requests and updates a worklist. It handles the queue, not the case, and it saves real staff hours with essentially no clinical risk.

The copilot version reads the chart, assembles the clinical documentation and drafts the medical necessity narrative. A nurse or coordinator reviews it and submits. The human sees every submission, and the error mode is a weak argument caught before it goes anywhere.

The agent version takes the referral, determines whether authorisation is required, gathers the documentation, submits through the payer channel, tracks the response, and appeals a denial using the payer's own criteria, escalating only when it hits something it cannot resolve. Nobody reviews each submission. See prior authorization automation for how far that goes in practice, and the CMS prior authorization rule for the interoperability requirements that change what is possible.

The same gradient runs through the rest of operations. Scheduling moves from reminder scripts, to suggested slots, to an agent that calls patients and rebooks them. Intake moves from form routing, to summarising responses for a clinician, to an agent that conducts the intake conversation. In every case the third step is where the governance obligation changes shape, and in every case it is also where most of the labour saving actually sits. That trade is the real decision, and it is worth making deliberately rather than by accident of procurement.

A defensible sequencing rule: match autonomy to reversibility, not to ambition.

Deploy agents where the actions are cheap to undo and the consequences are administrative. A misdialled outbound scheduling call is a nuisance. Keep humans in the loop where errors reach the clinical record or a patient's understanding of their own care, because those are expensive to unwind and sometimes impossible. Keep RPA where the task is stable and specified, because determinism is worth more than flexibility when the task never varies.

Then be honest in your own documentation about which one you have deployed. The most common governance failure we see is not an organisation approving something reckless. It is an organisation approving an agent under the review model it wrote for a copilot, because the vendor described it in copilot language and nobody traced the last human decision before the effect. That failure is entirely preventable with the six questions above and a written answer on file.

If you want that classification done properly across a portfolio, with the tiering, the controls and the accountable owners written down, that is the substance of our AI governance and compliance work, and it usually begins with an AI readiness audit of what is already running.