Magical

The agents are the product. Each one reads screens, decides what to do and acts across the EHR, payer portals and other applications on its own virtual machine, completing prior authorizations, referrals, eligibility checks, records requests, revenue integrity reviews and payment posting the way a staff member would. Separate AI judge models check the work, and specialized agents coordinate through a multi agent framework.

Magical's older one click browser automations still exist as a starting point, and the platform lets organizations build their own agents from their procedures. Both serve the agents, which Magical prices and positions as an AI workforce rather than software that assists staff.

Agents run autonomously with checks around them. AI judge models place guardrails on each run, every step is recorded with the action taken and the agent's reasoning, runs are repeatable so they can resume safely, and a person can intervene when needed. Customers set permissions on who can run an automation and which data sources an agent may use.

The missing part is the threshold. Nothing says when a run stops and goes to a person, what happens to a prior authorization the agent is unsure about, or how a wrong submission is caught before it reaches a payer. Magical markets the agents as making decisions just like a human and working while staff sleep.

The architecture is sketched: large language models drive agents that operate browser and desktop applications on virtual machines, a multi agent framework coordinates specialized agents, AI judges check their work, and a data graph links data points across hundreds of systems. Custom agents are trained on a customer's own procedures and systems.

No model provider, model family or version is named, and nothing explains how the judges are built or updated. Step logs record the agent's reasoning for each action, which helps an operations team audit a run, but not what produced that reasoning or when the underlying models changed.

Large language models power the agents and the judges, and no model provider is named. Magical names Amazon Web Services as its host and WorkOS for sign in, and reviews third party vendors before onboarding and on a set cadence, without a subprocessor list. The one term stated for the model layer is that Magical's use of language models prevents training on prior runs.

Agents see whatever is on screen in the EHR and payer portals they operate, so patient data passes to the model layer on every run. Without a named model provider, an organization cannot see which outside companies receive that data or confirm the no training term against their own contracts.

Accuracy is quoted for each prebuilt agent, without a method or denominator: 92 percent for prior authorization, 94 percent for referrals, 91 percent for benefits verification, 97 percent for records requests, 93 percent for revenue integrity and 99 percent for payment posting, with coverage above 90 percent within six weeks on average. The prior authorization pitch adds up to 50 percent fewer denials, and a customer quote credits Magical with ten hours a week saved on lab portal forms.

Outside signals are about satisfaction, not accuracy: a KLAS emerging company report in 2026 gave Magical an A+ for likelihood to recommend, and Quality Correctional Care describes replacing its RPA vendor in under a month. How accuracy is measured, on which tasks and against what reference, is not explained.

Magical commits that its use of language models prevents any training on prior runs, and each workflow run happens in its own assigned virtual environment. Data is encrypted in transit and at rest, workspaces are logically separated, and permissions limit which data sources an agent may reach.

The retention terms given cover backups, point in time restore for 14 days and daily backups kept 31 days in a separate region, not the screenshots, page content and patient data an agent handles during a run or the step logs kept afterward. Safety engineering is described through AI judges that place guardrails around each run and through daily automated testing, without saying what a judge does when it flags a step.

HIPAA compliance is claimed in plain terms: Magical says its platform meets the full requirements of HIPAA and that patients' protected health information stays protected throughout every interaction. No business associate position, agreement or tier is described alongside that claim, and nothing says which subcontractors handle patient data.

The agents read and write patient records across EHRs and payer portals, so the agreement that governs that access matters more than for a passive tool. Magical's privacy policy and terms are general documents, and nothing ties them to how the agents handle patient data.

SOC 2 Type II is named on Magical's trust page with a link to request a copy of the report, so the attestation exists and is available on request rather than open to download. The report date and scope are not shown. Annual penetration tests by outside firms come with the SOC 2 program, alongside vulnerability scanning on a set cadence.

Encryption in transit with TLS 1.2 and at rest with 256 bit AES, single sign on through SAML 2.0 with required multifactor authentication, passwordless sign in through WorkOS, immutable audit logs, granular permissions and a responsible disclosure program are described. No HITRUST or ISO 27001 certification is claimed.

No device claim is made, and none fits: the agents do administrative work in revenue cycle and patient access, submitting authorizations, checking eligibility, processing referrals and records requests, and posting payments.

Prior authorization agents gather clinical documentation for payers, but they assemble and submit what the provider's record already holds rather than making a clinical judgment, and the payer agents work on the plan's administrative processes. The rules that govern this work are payer requirements and the federal prior authorization rules, not device regulation, so the positioning as operations software matches what the agents do.

Testing is described as daily automated testing plus AI judges that check each run, and accuracy is quoted per agent. That is quality control language without an evaluation a buyer can read: no test design, error categories or results over time are shared.

For administrative agents, uneven performance shows up less across patient groups than across payers, portals, procedure types and document quality. No breakdown of that kind is offered, so an organization cannot tell which of its payers or workflows will see the most errors, or whether accuracy holds for complex authorizations as well as routine ones.

Every step an agent takes is recorded with its reasoning in immutable logs, and runs can be repeated and resumed, so an operations team can reconstruct what happened when a submission goes wrong. A person can intervene during a run.

No guarantee, service credit or remediation commitment covers an agent's output, such as a denied authorization or a misposted payment, despite the accuracy figures quoted for each agent. Under the managed service option Magical runs the agents itself, and nothing says whether it takes on more responsibility for results in that arrangement.

Two routes reach the record. Agents work through the screens of existing applications, moving between the EHR and any payer portal as a person would, and since September 2026 Magical also connects through SMART on FHIR. It says its apps are published in Epic's Showroom, Oracle Health's partner marketplace, eClinicalWorks' developer portal, Meditech's Greenfield Workspace, NextGen and the athenahealth marketplace, for sandbox and production, with Veradigm and Netsmart pending, so agents can read appointment, note and coding data and write results back.

No customer is tied to a particular EHR connection, and the listings are the company's account rather than production volumes. Screen based work still covers the payer portals and clearinghouses, which depends on the layout of each one, so a change to a portal can break a workflow until the agent is retrained.

Agents run in Magical's hosted environment on Amazon Web Services, each workflow run on its own assigned virtual machine, with workspaces logically separated and requests authorized by scoped, signed tokens. Customers can run the platform themselves or have Magical operate the agents as a managed service, and simple one click automations run locally in the browser.

Backups are stored in a separate geographic region, but no primary region or country for patient data is named. Whether agents and their logs stay in the United States, which matters for an operations workforce described as built in the United States and Canada, is not stated.

No price, plan or unit of charge is published; the pricing link returns to the home page and every route leads to sales. How Magical sells is still clear: prebuilt agents deployed individually or combined into suites, a platform for building custom agents trained on a customer's procedures, or the same agents run by Magical as a managed service.

Deployment times are given per agent, from six weeks for benefits verification to twelve for referrals, which helps a buyer plan. Whether agents are priced per task, per workflow, per agent or as a share of savings is not stated.

Healthcare operations on both sides of the claim are the market, with pages for providers, orthopedics, behavioral health, health systems and payers. The prebuilt agents target patient access and revenue cycle tasks common to all of them, and payers are offered automation of their own administrative work.

One customer story is named, Quality Correctional Care, a correctional healthcare provider, and KLAS's report rests on interviews with customers it does not name. No orthopedic group, behavioral health practice, health system or payer is named as running a specific agent, so the specialty pages stand on the pitch rather than on a named deployment.