An agent assembling a prior-authorization packet for a pain-management clinic needs more than the ability to read documents and write a convincing summary. It needs to know when evidence is incomplete, whether someone approved the packet, and whether a previous submission already succeeded.
That last question matters when a connection times out. The remote system may have accepted the packet even though the agent never received a response. Retrying can create a duplicate submission. Refusing to retry can leave the task unfinished. Neither problem is solved by changing the writing prompt.
This is an illustrative administrative workflow, not a reported patient case. Requirements vary by payer and service. Approval boundaries must come from the clinic’s authorized workflow. The ten components below are responsibilities to design, not necessarily ten separate services.
1. A trigger with an identity
A new request or relevant change starts the workflow. Give it a stable identifier and record what changed. If the scheduling integration delivers the same event twice, recognize the same work rather than launch two independent submissions.
Keep the workflow identity separate from the individual attempt. A failed network call may justify another attempt; it does not necessarily justify another business action.
2. A router that understands the state
A new request, a request for additional information, and a rescheduled appointment should not all take the “create new packet” path. The router chooses a named workflow based on authoritative state.
If the payer requests an additional document, route the work to supplementing the existing request. Otherwise the agent may start over, lose the previous reference, and leave staff reconciling two versions.
3. Policy enforced outside the prompt
The policy layer determines what this run may read, prepare, and send. Permission to assemble a draft does not automatically include permission to submit it or communicate externally.
Enforce this at the tool call. If submission requires approval tied to the current packet version, the agent cannot bypass it by saying approval “appears unnecessary.” Return a structured policy decision with a reason.
4. Context with provenance and gaps
The context builder assembles the request, encounter, source documents, and current requirements. A reference to an outside imaging report is not the report. An inaccessible attachment is not evidence of an absent finding. A document from another encounter is not made relevant by a similar title.
Return source identifiers, retrieval timestamps, and completeness states alongside the text. If a required source is missing, the useful output is a precise request for that evidence, not a polished substitute.
5. A runtime that can wait and recover
The workflow may pause for a document or staff review and resume hours later. Its state needs to survive a process restart. Track which version awaits approval, which calls completed, and which outcomes remain unknown.
After a submission timeout, persist an outcome_unknown state. Reconcile through the destination’s receipt or status mechanism where available. If the destination cannot establish the outcome safely, route the uncertainty to an operator.
6. Tools with explicit side effects
Separate read_request_status, prepare_packet, and submit_packet. Each needs validated inputs and structured results. Avoid a broad tool that silently combines reading, drafting, and sending.
Use a stable idempotency key for writes where the destination supports one. An internal “already started” flag alone cannot prove an external action happened exactly once. The tool still needs a reconciliation strategy for uncertain outcomes.
7. Evaluation before calling the packet ready
A fluent summary can contain the wrong encounter date or an unsupported statement. Check required fields and document associations deterministically where possible. Evaluate generated claims against the retrieved evidence.
A useful regression case is a referenced-but-unavailable report. The packet should fail its completeness check or explicitly identify the gap. A model judge rating the prose “clear and professional” tells you very little about that failure.
8. Approval tied to the exact artifact
Show the reviewer the proposed packet, source references, missing items, and intended destination. Bind approval to an exact version or digest, not a mutable folder named “latest.”
If the agent changes the packet after review, invalidate the earlier approval and re-evaluate. Otherwise a human can approve one thing while the system sends another. This also applies to a drafted patient message or an EHR update.
9. An audit trail that answers the question
When staff ask “Was this sent, and which version?”, the answer should not require reading every model token. Record the trigger, source references, policy decisions, artifact digest, evaluation, approver, submission attempt, receipt, and final state.
Keep sensitive source content in appropriately controlled systems. An audit trail is not a reason to copy entire charts into general-purpose logs. Access controls and retention rules remain necessary.
10. Outcomes that expose hidden rework
I would track incomplete packets, duplicate or uncertain submissions, time waiting for missing evidence, reviewer corrections, and manual reconciliation time. These are proposed measures, not reported Meros performance figures.
Separate system-caused defects from external decisions. A payer decision depends on more than the software. The engineering team can still establish whether its system sent the intended packet once, with the right evidence and authority.
Start with the failure you cannot afford to hide
You do not need ten microservices. You do need an answer for each responsibility. A small application with explicit states and narrow tools can be easier to operate than a large agent framework with ambiguous authority.
My first design review would walk through one uncomfortable path: the packet changes after approval, submission times out, and the workflow restarts. Can the platform establish what was approved, prevent an unapproved send, and recover without silently duplicating the action?
If not, the missing capability is in the platform around the model.
Workflow background: CMS distinguishes coverage discovery, request submission, and decision responses. These engineering examples do not state payer-specific coverage policy.
Written by Morteza Naraghi, co-founder and CTO of Meros AI and author of Agentic Software Delivery.