Platform AI agents vs custom healthcare agents: where should each agent run?
Many health systems already license platforms that now ship AI agents: the EHR, the CRM and the contact center cloud. Each platform's agent works best on data and actions inside that platform. The decision is per job: where its data lives, where the result must be written, and whether one platform holds both.
Should a healthcare AI agent run inside a platform or in a custom layer?
Quick answer
Platform AI agents vs custom healthcare agents is decided job by job. When the data and the write-back for a job live in one licensed platform, its native agent is usually the shortest path. When a job spans the EHR, CRM and phone system, a custom layer reaches all three. Agnotic Technologies builds those custom layers and platform extensions.
| Criterion | Platform-native agent | Custom agent |
|---|---|---|
| Appointment rescheduling call | A contact center agent handles the call; it finishes the job only if an integration writes the new slot to the EHR schedule | Handles the call, reads open slots from the EHR scheduling API, books and confirms in one flow |
| Care gap outreach | A CRM agent runs the campaign once gap data has synced in from the EHR or a quality system | Reads gaps from the EHR or registry, picks the channel and logs the outreach back to the CRM |
| Patient message triage | An EHR agent sees the portal inbox and chart context in place | Needed when messages also arrive by SMS, CRM or phone and must be triaged as one queue |
| Prior authorization packet | An EHR agent sees the order and notes; submission depends on the payer connections the platform offers | Assembles notes, orders and payer rules across EHR and payer APIs and returns the packet for staff review |
| Referral intake | Works when referrals arrive inside the same EHR network | Needed for faxes, outside EHRs and email, which land outside any one platform |
| Benefits question on a call | A contact center agent answers if eligibility data is reachable from the call flow | Calls eligibility services (X12 270/271 or payer APIs) and the CRM record in one turn |
What they are
What is Platform-native agent
A platform-native agent is the AI agent feature inside software the organization already licenses: the EHR vendor's agents, CRM agents such as Salesforce Agentforce on Health Cloud, or contact center agents such as Amazon Connect Health. It sees that platform's data and acts through that platform's workflows.
What is Custom agent
A custom cross-system agent runs in a layer the organization controls. It calls the EHR's FHIR APIs, the CRM's APIs, telephony and payer services as tools, so one agent can finish a job that crosses platforms, with its own logging, evaluation and model choice.
Key differences
What can a platform-native agent not see?
Data that never enters its platform. An EHR agent does not see the CRM's campaign history unless it is synced in; a contact center agent does not see chart context unless the call flow calls the EHR; neither sees faxes waiting in an intake queue. Each gap can be closed with an integration, and at that point you are building part of a custom layer anyway.
Is the platform's AI feature inside your BAA?
Check the feature, not just the vendor. Under 45 CFR 164.502(e), PHI reaches a business associate only after the covered entity obtains written assurance that the business associate will safeguard it, so confirm that the contract and the vendor's eligible-service list both cover the AI feature in use. AWS's HIPAA Eligible Services Reference, for example, lists the services that may handle ePHI and notes exclusions for some features; it lists Amazon Connect Health with a note that a Healthcare and Life Sciences Addendum applies. Read each platform's equivalent list before PHI reaches its AI feature.
How do you extend a platform agent instead of replacing it?
Through the platform's APIs. Epic's developer site, Epic on FHIR, documents its FHIR API specifications alongside CDS Hooks, FHIR Bulk Data and HL7 v2 interfaces, which is how outside software reads and writes data in Epic workflows. CRM and contact center platforms expose their own extension points for custom actions. A custom tool exposed this way lets the platform's agent finish a step it could not reach alone.
Does decision support regulation change the choice?
It can. When an EHR shows a predictive decision support intervention, the ONC (ASTP) criterion 45 CFR 170.315(b)(11) requires the certified technology to support source attributes for it, such as the developer and funding source. If a custom agent's output is shown inside the EHR as decision support, agree early who documents those attributes.
When to use each
When to use Platform-native agent
- The job's data and its write-back both live in one platform, such as a portal inbox in the EHR.
- The platform's AI feature is covered by your BAA and listed as HIPAA eligible.
- You want the vendor to own model updates and the user interface.
- The workflow is standard for that platform and needs little custom logic.
When to use Custom cross-system agent
- The job reads from one platform and must write to another.
- Inputs arrive outside every platform, such as faxes, outside referrals or SMS.
- You need one evaluation and audit trail across every channel.
- Sites run different EHRs and the agent must behave the same at each.
What does a hybrid platform and custom agent design look like?
1. Keep the front end in the platform. Patients call the contact center, staff work in the EHR or CRM, and the platform's agent handles the conversation.
2. Put cross-system tools behind it. Custom services do the steps the platform cannot reach, such as reading EHR slots, checking eligibility or filing a faxed referral, and expose them through the platform's extension APIs.
3. Give each tool a narrow identity. Every tool call uses its own scoped credentials and writes an audit entry naming the job and the user it served.
4. Evaluate the whole job. Score outcomes end to end, from the patient's request to the record that was written, not platform by platform.
5. Plan the exit per layer. If a platform's agent is replaced, the custom tools and their logs stay, and a different front end can call them.