Real-time vs asynchronous AI agents in clinical operations: which mode fits each task?
A clinical operations agent either answers inside a live moment, while a caller waits, a chart is open or an order is being signed, or it works from a queue while nobody waits. The mode sets everything downstream: how the agent is triggered, how fast it must be, what happens when it fails and when a person reviews its work.
Should a clinical operations AI agent run in real time or asynchronously?
Quick answer
Real-time vs asynchronous AI agents is decided by who is waiting. If a caller, a clinician or a signing step waits for the answer, run in real time with a tight latency budget and a fallback to a person. If nobody waits, run from a queue with retries and review. Agnotic Technologies builds both modes.
| Criterion | Real-time | Asynchronous |
|---|---|---|
| Caller rescheduling | Fits: the caller waits; the trigger is the call; fallback is a transfer to staff | Only for follow-up, such as a confirmation text after the call |
| In-visit coding hint | Fits while the note is open; fallback is no hint | Fits as a pre-bill review after the visit is signed |
| Order-sign check | Fits: a CDS Hooks order-sign request; fallback is the order proceeds without a card | Too late once the order is signed |
| Inbox triage | Rarely needed | Fits: messages queue on arrival and staff review a sorted worklist |
| Prior authorization packet | Poor fit: assembly needs many lookups | Fits: triggered by the order; the packet waits in a staff queue for review |
| Chart abstraction for registries | Poor fit | Fits: a scheduled batch, with a reviewer sampling the output |
| Discharge follow-up calls | The call itself is live | Building the call list is a queue, triggered by the HL7 v2 ADT discharge event |
| Latency budget | Set by the team per task; CDS Hooks says services should respond on the order of 500 ms | Minutes to hours, set by the worklist's service level |
| When a person reviews | In the moment, by the user who sees the output | Later, in a worklist, before anything becomes final |
What they are
What is Real-time
A real-time agent runs inside a live interaction and returns before the interaction moves on. Its trigger is the interaction itself, such as a call turn, a chart opening or a CDS Hooks request, and when it fails it must get out of the way.
What is Asynchronous
An asynchronous agent picks up work from a queue, fed by an event such as a FHIR Subscription notification or an HL7 v2 ADT message, or by a schedule. It can take longer, use larger models and retry, and its output waits in a worklist for review.
Key differences
How fast does a real-time agent have to be?
Fast enough for the moment it serves, and the team sets that budget per task. For services called from a clinician's workflow, the CDS Hooks specification says services should respond quickly, on the order of 500 ms, and defines prefetch so the client can send the data the service needs with the request. A voice turn or chat reply has its own budget. Design the agent to fit inside the budget or return nothing.
What triggers each mode?
Real-time agents are triggered by the interaction: a call event, an app launch or a CDS Hooks request such as order-sign or patient-view. Asynchronous agents are triggered by events or schedules: an HL7 v2 ADT message on admission or discharge, a FHIR Subscription notification when a resource changes, or a nightly job. The FHIR Subscriptions R5 Backport guide brings topic-based subscriptions to FHIR R4 servers.
What should happen when the agent fails?
In real time, fail open to a person: transfer the call, show no card, let the order proceed, and log the miss. Asynchronously, retry with backoff, then move the job to a dead-letter queue that a person works. Never let a real-time agent keep retrying while a caller waits.
How do you know an asynchronous agent missed an event?
Count events. In the Subscriptions Backport guide, each notification carries an events-since-start count, so a subscriber that receives event 23 right after event 21 knows event 22 is missing and starts recovery. Apply the same idea to every queue: sequence numbers per source, an alert on any gap, and a replay path.
How does model choice change by mode?
Real-time tasks usually need a smaller or faster model, fewer tool calls and cached context, because the budget is short. Asynchronous tasks can use larger models, more tool calls and a second pass that checks the first, because nobody is waiting. Cost per task follows the same split, so measure it per task rather than assuming it.
When to use each
When to use Real-time agent
- A caller or patient is waiting on the line or in a chat.
- A clinician needs the output before leaving the current screen.
- The answer is worthless a minute later, as with an order-sign check.
- The task needs few lookups and a small, fast model.
When to use Asynchronous agent
- Nobody is waiting, and the output feeds a worklist.
- The task needs many lookups or long documents, such as packets and chart abstraction.
- Failures can be retried without anyone noticing.
- Work arrives in bursts, such as overnight results or discharge lists.
How do you design the queue behind an asynchronous agent?
1. Idempotency keys. Key each job on its source event, such as the sending system plus the HL7 v2 message control ID, or the Subscription event number, so a redelivered event never creates a second job.
2. Retries with backoff. Retry transient failures, such as a timeout from the EHR API, a fixed number of times with growing delays. Do not retry validation errors.
3. Dead-letter queue. Jobs that keep failing move to a queue that a person reviews, with the error and the input attached.
4. Ordering per patient. Process events for the same patient in order, so a discharge is never handled before the admission it closes.
5. Review worklist. Output lands as a draft or task with a due time, and nothing becomes final until a person accepts it.
6. One trace per job. Carry one trace ID from the trigger to the final write, so a reviewer can see why a job ran and what it touched.