Sully.ai

The scribe is one agent among several. Sully sells a suite of AI employees for hospitals, covering reception, triage, nursing intake, coding, pharmacy, interpretation and clinical research alongside documentation, so a buyer evaluating the scribe is buying into a wider system. The agents are the product and the company has no non AI business.

There is one dependency: speech infrastructure is partly supplied through a partnership with Speechmatics announced in January 2026, so the transcription layer is not wholly first party even though the agent architecture above it is.

A wide autonomous surface, and little of it bounded in public. Agents independently answer inbound calls, schedule, perform intake and TRIAGE, process claims, and the scribe extends past documentation into identifying a diagnosis and suggesting a plan. No confidence threshold, escalation path, abstention behavior or human review requirement is published for any agent.

The consensus mechanism is a real verification design, agents critiquing one another and scoring proposals before acting, but it is AI checking AI: it reduces single model error without introducing a clinician, so it is not human oversight. The stated destination of a fully autonomous healthcare system makes the disclosure gap more consequential rather than less.

Publishes real technical work rather than adjectives, and some of it is unflattering to its own category. Sully documents a SuperAgent architecture of isolated composable agent packages and a consensus mechanism in which agents reach verifiable agreement through structured proposal and critique cycles with weighted scoring and reputation tracking.

More notably it published a benchmark across more than 12 models and multiple medical specialties reporting the leading model at 45 percent overall accuracy and recommending ensemble use, which is a vendor telling the market that frontier models are far from reliable on medical tasks. That is candor in a direction that costs it something. No accuracy figure, error rate or evaluation result is published for its own shipping agents, and the Doctor-LM personalization layer is named but not explained.

The shape of the chain is described and its members are not named. The company publishes a benchmark comparing more than a dozen models across medical specialties and recommends ensemble use, and it ships an architecture of isolated composable agent packages with a consensus mechanism among agents, so a reader can infer that several third party models are invoked and that no single one is authoritative. Inference is not enumeration. Nothing states which models are in the production ensemble, which providers supply them, what hosting arrangement runs them, or which parties appear on a sub processor list, and a personalization layer is named without being explained. The training boundary is the better half of the record: protected health information is not used for model training unless explicitly permitted, which is a permission gate rather than a use limitation, and a gate at least places the decision with the customer instead of leaving it to vendor interpretation. What is missing alongside it is any retention schedule, which matters more here than for a single purpose scribe because the platform spans inbound calls, intake, triage, documentation and claims, and recorded triage or intake calls are patient speech captured outside a clinical encounter entirely.

The vendor's trust center carries a knowledge base entry on exactly this question: which large language model providers are used for ambient processing, and whether they retain any data. If that entry names the providers and their retention terms, it settles most of the open questions about the model chain.

Adoption claims without denominators and no clinical evidence. Published figures include partnership with more than 100 healthcare organizations, adoption across platforms serving over 100,000 providers and seven figure annual recurring revenue within ten months of launch, none of which measures clinical or operational benefit. Pilot feedback is described in terms of enthusiastic reactions. No peer reviewed study, controlled evaluation, third party performance rating or named health system outcome data is published.

Training is the question the vendor's own material answers, and it is the most important half of how patient data is handled.

The vendor states that protected health information is not used for model training unless explicitly permitted. That is a permission gate rather than a carve out, and it is the stronger of the two formulations available: a flat commitment never to train is cleaner still, but a permission gate at least places the decision with the customer rather than leaving it to a use limitation the vendor interprets.

Audit logging is described as carrying retention policies, and access to data is governed by role based controls with provisioning and deprovisioning processes.

What is still missing is the retention period itself. No schedule for encounter audio or transcripts is stated, nor any deletion commitment with a time bound or any deidentification practice. There is no default period and no named destruction standard.

The gap is wider than for a single product because of what this platform holds. Its agents touch inbound calls, patient intake, triage, clinical documentation and claims. Each produces a different class of content, and recorded triage or intake calls are patient speech captured outside a clinical encounter. Retention is unlikely to be identical across them.

The vendor states it will sign a business associate agreement with covered entities or business associates before processing protected health information, and describes a data processing agreement whose security measures are aligned to the security rule.

The commitment is stated in the right shape. Before processing is the correct sequencing, since using a tool on protected health information without an executed agreement is itself a violation regardless of how secure the product is, and a vendor that says so has understood the obligation rather than treating the agreement as paperwork to follow adoption.

The surrounding commitments are the ones a counterparty actually needs: encryption in transit and at rest, role based access with provisioning and deprovisioning, audit logging with retention policies, breach notification commitments, and stated visibility into subprocessors. Subprocessor visibility is the item that determines whether the agreement means anything downstream.

One question remains, and it follows from the product's breadth. This is not a scribe but an agent suite whose components touch inbound calls, patient intake, triage, documentation and claims. Each of those creates or transmits protected health information in a different form and, in the case of claims, sends it onward to third parties. A single agreement may well cover all of it, but nothing published establishes the scope, or shows that terms signed for one agent anticipated the others.

Three certifications are named on the vendor's own trust center, each with its type or version: HITRUST, ISO/IEC 27001:2022 and SOC 2 Type 2. The help center adds that the SOC 2 Type II and ISO 27001 attestations cover the platform and the hosting environment.

The three examine different things. SOC 2 Type II tests whether controls operated effectively across a period, ISO 27001 certifies the management system by which risk is identified and controls are maintained, and HITRUST maps controls to healthcare specific requirements. Holding all three means the program has been examined on operation, governance and healthcare scope.

The portal is substantial, listing documents on penetration testing, the development lifecycle, AI governance, breach notification, backups and cyber insurance. The documents themselves sit behind an access request, and the vendor states that full reports are available to qualified prospects under a non disclosure agreement. That gate means none of the artifacts can be opened without asking. The site footer also links a separately hosted compliance page for health privacy, so a buyer may meet two trust surfaces.

No clearance is claimed. An architectural claim bears directly on the regulatory question.

Several described capabilities sit closer to regulated clinical decision support than to documentation: identifying a diagnosis, suggesting a care plan, and operating a triage agent. Where a product moves from recording what a clinician decided to proposing what the decision should be, the software as a medical device question becomes live, and documentation status does not carry across. Nothing published says how the vendor has assessed each capability, and the scribe's position does not cover the suite.

The architectural claim is the vendor's stated approach to reliability. It describes a consensus mechanism in which multiple expert models review a case and agree on the most reliable clinical output, rather than relying on a single model's response. That is a considered design, and it explains how the system reaches an answer.

It also sharpens the regulatory question rather than settling it. The reasoning that keeps decision support outside device regulation depends on a professional being able to review the basis of a recommendation independently. A consensus across several models is harder to review than a single chain, because what the clinician sees is an agreed output rather than the disagreement that preceded it. Nothing says what is surfaced when the models do not agree, whether a confidence or dissent signal reaches the clinician, or what the interface shows for a low agreement case.

The triage agent remains the sharpest item, since urgency determinations are made in exchanges where no clinician is present.

Governance documentation exists and is not public. The vendor's trust center lists an AI Governance document and an AI Software Use Guidance document among its controls, both behind the portal's access request, so the material has been written and cannot be evaluated before asking.

Nothing that can be read describes a named process, an evaluation method or subgroup results. No fairness statement, subgroup analysis or accent and dialect disclosure is published, and that matters more here than for a scribe alone, because the product line includes agents that triage patients and propose diagnoses.

The commercial framing matters here. The market is described as the roughly $800 billion spent annually on United States medical staff salaries, and the destination as a fully autonomous healthcare system, which is a labor substitution thesis rather than an augmentation one and carries different obligations. Against that, the vendor's published 45 percent benchmark result cuts directly against its own marketing trajectory.

Real published technical work exists, and the way it is distributed produces an odd result. The company published a benchmark across more than a dozen models and several medical specialties, reporting the leading model at 45 percent overall accuracy and recommending ensemble use. That is a vendor telling the market that frontier models are far from reliable on medical tasks, which is candor in a direction that costs it something. The oddity is what that leaves.

The company has published a rigorous and alarming number about the models underneath this class of product, and no accuracy figure, error rate or evaluation result for its own shipping agents. So the only measurement available is the discouraging one, and the reassuring one does not exist. Nothing shows whether the ensemble and consensus design closes the gap the benchmark describes, which is the single question the benchmark raises.

The architecture is documented in detail, with isolated composable agent packages and a consensus mechanism in which agents reach agreement through structured proposal and critique with weighted scoring, and a permission gate governs training so the decision on whether protected health information is used sits with the customer. Those are mechanisms a customer can use. No warranty, indemnity or remediation commitment is published.

Named integrations are published first party. The vendor's integrations page lists Epic, Cerner, Allscripts, athenahealth and NextGen among its record systems, and describes secure bidirectional flow of health information with encryption, audit trails and role based access.

The depth behind the names is not documented. Nothing published shows which systems support writing notes back as against reading data, what mechanism each connection uses, whether any appears in a record system's own marketplace, or evidence of a connection running in production. Bidirectional is stated as a property of the platform rather than shown for a named system, and connects instantly is a claim rather than an architecture.

No hosting region or residency commitment appears in the vendor's own material, and no subprocessor list is published, though the vendor states subprocessor visibility is available through its trust portal and that its attestations cover the hosting environment.

Subprocessor visibility as a stated commitment is better than silence and is not the same as disclosure. A portal that needs an access request cannot be compared in advance, and the chain is the thing that determines whether the agreement and the training commitment survive downstream. A named speech partnership makes that concrete rather than theoretical: at least one external party processes audio, so the question is what else does.

A third party comparison published by a direct competitor describes a self hosted deployment option for organizations with data residency requirements. If that exists it resolves residency outright, since the customer holds the environment; the vendor's own material does not mention it. An agent suite that reaches inbound calls and claims is unlikely to be fully deployable inside a customer boundary, and nothing says which components could run self hosted.

Also unresolved: which model providers process the encounter, and whether the multi model consensus approach the vendor describes means more than one external service sees the same clinical content.

The figures of $79 and $99 per provider per month come from comparison pages published by competitors, not by Sully itself, and the vendor's own help center contradicts the tiered structure they described.

The vendor states that pricing is customized to clinic size, the number of agents, call or usage volume and the workflows being automated, and that exact pricing is discussed after a demo or pilot conversation. No price, tier or rate card is published. What the site does show before any contact is what drives the cost.

The more important commercial point is what is being priced. Sully sells agents as role substitutes across reception, triage, documentation, coding and interpretation, so a per provider comparison against a documentation tool understates the intended scope.

Broad across the encounter rather than deep in one setting: coverage spans before, during and after the visit, from reception and intake through documentation to coding and follow up, across a claimed 50 or more medical and surgical specialties with multilingual support through a dedicated interpreter agent. Targeted at hospitals, health systems and larger clinics. The specialty count is asserted without enumeration, and no setting specific validation is published.