Beyond RPA: Loop Engineering in Healthcare

On 17 July 2026, IBM published an explainer on loop engineering. Three days later, Linear introduced Loops, recurring agent workflows triggered by a schedule or an event. A term that had lived mostly among people building with AI agents had acquired a public name within days. I found the timing almost comic because I had spent that same week living with it across more than 300 agent sessions.

Before looking beyond RPA, it deserves proper credit. Some of healthcare's most useful productivity workflows came from robots doing work that no person should have to repeat all day: checking eligibility, moving data between old systems, updating claims, reconciling records, preparing routine reports, and keeping queues moving after office hours. RPA turned fragmented software into workable processes. In many organisations, it bought time back for staff without demanding the replacement of every legacy platform.

That foundation matters. Going beyond RPA means building on its strengths. AI agents working in loops can interpret a goal, choose an action, inspect what happened, revise the plan, and report progress, success, or failure in language a person can understand. RPA remains valuable for precise, stable execution. Loop engineering gives that execution a wider operating system, one able to handle context, exceptions, evidence, and accountability across an entire healthcare outcome.

RPA Earned Its Place. Loops Expand Its Reach.

RPA earned its place by following a defined path with discipline. Open this application. Read this field. Copy that value. Click this button. Save the result. The path may contain branches and error handling, but a designer has usually anticipated them in advance. This makes RPA fast, consistent, and auditable when the environment stays stable. Its boundary appears when a screen changes, an input arrives in an unexpected form, or the process requires judgement that nobody converted into a rule.

An AI agent operates with a goal and a set of tools. It can read an unstructured referral, understand that a required document is missing, decide which system to inspect, and prepare a response. The agent brings interpretation and choice into the workflow. A loop gives that agent continuity. It can return after ten minutes, check whether the missing document arrived, compare the new state with the intended outcome, and decide whether to continue, retry, escalate, or stop.

This distinction matters because a single agent response is still an answer. A loop is an operating process. It has a trigger, memory, permissions, evidence requirements, a stopping condition, and someone accountable for the outcome. The engineering work moves beyond asking the model a clever question. It defines what the agent can see, which actions it may take, how it knows whether those actions worked, what it should report, and where human authority enters.

A Healthcare Loop in Plain English

Consider a routine referral pathway. An RPA bot can open a queue, copy patient and referral data into another system, submit the record, and log that the transaction completed. A healthcare loop can start earlier and finish later. It can read the referral, identify missing administrative information, gather permitted data from approved sources, call the RPA bot for the repetitive entry work, verify that the destination accepted the record, monitor for a response, and alert the right person when progress stalls.

The loop has five movements. It begins with a trigger, such as a new referral or an unanswered request reaching a time limit. It orients itself by reading current state, history, and relevant policy. It acts through an API, an RPA workflow, a database query, or a message prepared for approval. It verifies the result against evidence from the destination system. It then reports or escalates, preserving what happened, what remains open, and who now owns the decision.

That reporting layer deserves more attention. RPA platforms already provide logs, dashboards, retries, and success or failure states. Agent loops add meaning around those states. A traditional dashboard might report that job 482 failed at step 17. A well-designed loop can explain that a referral remains incomplete because consent is absent, that two approved sources were checked, that no patient data was changed, and that a named coordinator needs to review the case before 4 pm. One gives an execution status. The other prepares an accountable next action.

The Next Layer Builds on RPA

A 2025 comparative study of RPA and computer-using AI agents tested data entry, monitoring, and document extraction. RPA was faster and more reliable in stable, repetitive environments. The AI agent took less development effort and adapted more easily to changing interfaces, but the researchers judged the tested agent implementation unready for production. That finding is a useful correction to the idea that every old automation should now be replaced by an agent.

The major automation vendors are building around the same conclusion. Microsoft's 2026 Power Automate plan combines agents that handle complex scenarios and adapt to change with desktop flows for precise, step-by-step execution. UiPath describes the relationship as a partnership: agents interpret variable situations, while deterministic workflows carry out actions that demand consistency. That architecture says something important about the market. Even vendors whose businesses grew around RPA are placing reasoning and orchestration above individual desktop automations, while keeping robots available as governed tools beneath the agent.

In healthcare, this hybrid design makes sense. Let the agent understand an unstructured message, classify the exception, and decide which approved tool is appropriate. Let RPA perform the exact legacy-system sequence where no API exists. Let an API handle structured exchange when one does exist. Let a human approve the clinical, privacy, financial, or external decision carrying real consequence. The loop coordinates these parts and keeps their evidence connected over time. This division of labour lets each component operate within the conditions where its behaviour is easiest to predict, test, and audit.

What My Week Taught Me About Designing the Loop

Reviewing hundreds of sessions showed me how quickly agent activity can become mistaken for progress. Some loops produced tested work, surfaced weak assumptions, and stopped safely when their environment changed. Others generated many pages while the underlying organisational outcome remained still. Session volume measures activity. A healthcare loop needs an outcome outside the AI system: a referral completed, an exception resolved, a risk surfaced, a waiting time reduced, or a human decision made with better evidence.

Repetition exposed every weak definition. If success meant “message sent,” the loop could celebrate while the message remained undelivered. If success meant “record updated,” it could miss that the wrong person had authority to approve the change. The better loops required evidence from the receiving system. They recorded which source had been checked, what result came back, and which uncertainty remained. Their memory prevented the next run from rediscovering the same facts and making the same mistake.

Independent criticism also changed the quality of the work. In one anonymised example, an agent produced a technically convincing plan. A separate critic reviewed it against security, privacy, and release requirements and found several reasons to stop. The next version closed most gaps, while approval remained withheld until the final conditions were met. Fluency had made the first answer feel complete. The loop required evidence before accepting that feeling as fact.

How to Build a Healthcare Loop Safely

Start with the outcome and work backwards. What real-world state should change? What fresh evidence will prove that change occurred? Which systems may the agent read, and which may it alter? What can happen automatically at low risk? Which action needs named human approval? What should the loop do when evidence conflicts, a source is unavailable, or the cost of another attempt exceeds its likely value? Write those answers before choosing model or automation platform, because architecture should follow clinical and operational risk. A team unable to answer these questions still has an experiment awaiting its operating design.

Every report should make five things easy to see: current state, evidence, exceptions, next action, and owner. “Running” is weak progress information. “Three of four records verified, one blocked by a missing consent form, no external message sent, review assigned to the service coordinator” is useful. The report should also distinguish a technical failure from an outcome failure. A workflow may execute perfectly while the patient, clinician, or organisation receives no benefit.

Risk should determine the depth of the loop. A low-risk administrative task may need one execution check and a short audit record. A workflow touching patient data needs identity, least privilege, source controls, detailed logs, and a clear route for exceptions. A loop influencing clinical decisions needs stronger evidence, independent review, and human judgement at the point where a recommendation becomes care. More autonomy increases the importance of governance because each cycle can carry an early mistake further.

Stopping Belongs Inside the Design

On 16 July, researchers published Proof-or-Stop, an evidence-gated approach to agent loops. In its fault-injection study, a naive loop amplified hidden failures 31 times across 1,800 cases. The gated version did so twice. The stronger controls added cost on clean, easy tasks, which is exactly why every workflow needs proportionate governance. High-risk loops should demand proof. Simple, stable work can continue using simpler automation.

The most trustworthy loop I observed that week chose to stop when its instructions and working environment changed during execution. It preserved the evidence already gathered, avoided producing a misleading result, and reported the reason it could no longer proceed safely. That behaviour looked less impressive than a completed package. It carried more value. Healthcare has enough systems that turn missing evidence into administrative confidence. Agentic automation should resist that habit.

Loop engineering expands the leadership question. RPA taught us to identify tasks a robot could repeat safely. We can now ask which outcomes a governed system can pursue, observe, explain, and hand back to a person at the right moment. RPA becomes the trusted execution layer wherever exact repetition earns confidence. The loop connects that precision to adaptive reasoning, evidence, and human authority. Leaders now carry a harder job: governing a changing process long after the first automation begins to run.

The Sentence Worth Holding Onto

Healthcare's next productivity leap will build on RPA's precision, then connect it to loops that explain what happened, prove what worked, admit what failed, and know when a person must decide.

Dr Ramy Azzam is a physician and digital health leader with 13 years of experience working across health technology, AI governance, and organisational systems.