8 Best HIPAA Compliant Voice AI Platforms for Healthcare 2026

Signing a BAA feels like compliance. It isn't. Here is what actually stands between your patients' PHI and a breach when a voice AI call starts moving.

Healthcare organizations signing a BAA with a HIPAA Compliant voice AI vendor often walk away feeling like the compliance work is done. The common assumption is that if a vendor offers a BAA, the compliance box is checked and the security review is essentially over. That instinct is understandable: the BAA is a legal instrument, it names the vendor, it assigns liability.

But the document does nothing to control where your PHI actually travels once a call starts. The real compliance question is technical, not contractual: which infrastructure nodes touch protected health information in transit, and are any of them shared with other tenants? That distinction matters more than most security teams realize until it's too late.

According to the HIPAA Journal, 2023 saw 725 large healthcare data breaches reported to the HHS Office for Civil Rights, affecting over 133 million individuals, the highest number of breached records ever recorded in a single year. BAAs existed across virtually all of those relationships. The paperwork didn't stop the exposure. Hacking and IT incidents accounted for nearly 80% of those breaches, meaning the failure point was technical infrastructure, not missing signatures. HIPAA's Security Rule defines four technical safeguard categories that apply to every system handling electronic PHI:

• Access controls
• Audit controls
• Integrity controls
• Transmission security

The critical word is "every."

A voice AI call touches multiple systems in sequence: audio ingestion, speech-to-text transcription, language model inference, text-to-speech synthesis, and call logging. Each node is a separate system under the Security Rule. Many organizations fail that requirement by auditing only the front-end platform while the STT layer routes audio through an undisclosed third-party pipeline with no verified encryption in transit. A BAA is a liability-allocation document. It does not encrypt a single byte of data, restrict a subprocessor from logging audio, or prevent PHI from traversing an undisclosed fourth-party pipeline.

Compliance leads routinely say they struggle to understand where field compliance responsibility begins and ends — specifically, whether a BAA with a form provider is sufficient or just one piece of a larger puzzle.

A BAA is a liability-allocation document. It does not encrypt a single byte of data, restrict a subprocessor from logging audio, or prevent PHI from traversing an undisclosed fourth-party pipeline.

725 Large healthcare breaches reported in 2023

Key takeaways#

• A signed BAA is a liability-allocation document: it assigns blame after a breach, not controls that prevent one.
• The real PHI exposure in voice AI stacks lives in every third-party API hop data touches in transit: STT providers, LLM endpoints, TTS services, and EHR connectors each add a subprocessor the original BAA was never written to govern.
• Hacking and IT incidents were the entry point in 79.7% of large healthcare breaches reported to HHS in 2023 — a documented infrastructure failure, not a theoretical risk category.
• Not every voice AI workflow carries the same compliance weight: a scheduling reminder and a prior-authorization call that captures diagnosis codes and NPI identifiers are not the same PHI exposure event and shouldn't be evaluated the same way.
• EHR integration is a second data path: the moment a voice AI platform reaches Epic or Cerner to pull eligibility data, PHI is in motion again across infrastructure the original BAA was never scoped to cover.
• The only way to eliminate third-party API risk at the infrastructure level is to keep PHI inside your own environment; Bland.ai's self-hosted architecture does exactly that, provisioning its own GPUs with compressed, tuned models and a full voice stack co-located on its own infrastructure so PHI never leaves.

Data Security and PHI Protection — Where Voice AI Stacks Actually Leak#

The common assumption among enterprise buyers in regulated industries is that if a vendor offers a BAA, the compliance box is checked and the security review is essentially over. Pull back the curtain on any "HIPAA-compliant" voice AI stack, however, and you will find the same uncomfortable truth: the compliance story stops at the contract layer while the data keeps moving. A signed BAA tells you who absorbs liability after a breach.

It says nothing about whether PHI is encrypted in transit through a shared inference cluster, logged with tamper-proof timestamps, or even visible to the vendor's own security team in real time. This cost is compounded by a structural barrier that early-stage healthcare builders know well: BAA agreements with major voice AI providers routinely carry minimum monthly or annual commitments that can be prohibitively high, placing formal compliance financially out of reach for any team that is not yet at enterprise scale. Bland.ai's Enterprise plan addresses this directly. BAA coverage is available on dedicated infrastructure, with compliance documentation provided under NDA and a forward-deployed engineering team that scopes, builds, and ships the first production agent within 30 days.

The Five-Stage PHI Attack Surface#

Every handoff from audio ingestion to call storage is a potential breach point. A typical cloud voice AI call touches five discrete infrastructure nodes, each handoff a potential exposure point:

• Audio ingestion
• Speech-to-text transcription
• LLM inference
• Text-to-speech synthesis
• Call storage

The audio stream carrying a patient's date of birth and diagnosis code does not pause at each boundary to verify that the receiving system is covered under the same BAA the buyer signed with the primary vendor. Across the market, business associates and third-party vendors account for a significant and growing share of healthcare data breaches, confirming that downstream infrastructure hops are where real PHI exposure concentrates, not at the primary platform layer. The practical answer is to eliminate dependence on third parties for data privacy and control entirely, which is why Bland.ai's Enterprise tier runs on dedicated infrastructure with on-premises or VPC deployment available, so every one of those five nodes stays inside the boundary your security team has already reviewed, rather than traversing shared multi-tenant systems owned by a chain of sub-processors.

Post-Hoc Redaction Arrives Too Late#

PHI enters third-party inference APIs before the transcript is ever cleaned. A common deployment pattern sends raw audio to a speech-to-text API, passes the unredacted transcript directly to an LLM for intent extraction, and only applies a redaction filter to the stored output. The problem is that the highest-risk moment, the live inference call, has already happened. A patient's insurance ID, social security number, or diagnosis code has already traversed an external API endpoint before the redaction pipeline ever fires.

The BAA covers the storage layer, but the inference layer was never in scope. Developers building clinical voice AI pipelines face a related friction point here: sourcing clean, high-fidelity speech data that covers complex medical terminology without risking PHI exposure is genuinely difficult, forcing a choice between inadequate open datasets and handling real patient data under insufficient controls. Bland.ai's architecture removes that dilemma at the inference layer. Real-time transcription (speech-to-text) and LLM inference are both included in the per-minute rate on every plan, with no external token charges passed through to third-party APIs, meaning the inference step does not leave the platform's controlled environment to reach an outside provider.

Audit Trail Opacity#

HIPAA voice AI platforms must log every PHI touchpoint. Audit trail completeness is not a post-breach concern; it is a pre-breach control. HIPAA's audit controls standard requires covered entities and their business associates to implement hardware, software, and procedural mechanisms that record and examine activity in systems containing PHI.

Key takeaway: Breach discovery lag, the gap between initial exposure and detection, is one of the most consequential variables in total harm, both to patients and to the organizations liable for their data.

A voice AI platform that cannot surface a timestamped, tamper-evident log of every PHI touchpoint across the call lifecycle cannot satisfy that standard, and cannot give a compliance officer the evidence needed to demonstrate control. Bland.ai's Enterprise plan includes alarm and monitoring capabilities, a dedicated orchestration server, and structured data capture from every call, connecting voice interactions directly into back-end systems such as work order platforms, TMS, and CRMs so that calls translate into logged, actionable data with zero manual entry. That is not incidental to the audit trail problem; it is the mechanism by which every PHI-bearing interaction becomes a traceable, reviewable record rather than an ephemeral audio event that disappears after the call ends.

8 Best HIPAA Compliant Voice AI Platforms for Healthcare — Evaluated on Infrastructure, Not Just Paperwork#

Hacking and IT incidents accounted for 79.7% of all large healthcare breaches reported to HHS in 2023, according to the HIPAA Journal's healthcare data breach statistics. That figure is not a hypothetical risk category; it is the documented cost of infrastructure gaps that legal agreements alone cannot close. A signed BAA creates accountability after a breach occurs.

It does not seal the data path that made the breach possible in the first place. That distinction matters enormously when you are evaluating voice AI platforms for healthcare deployment. Most enterprise buyers spend weeks in BAA negotiations, get the signature, and then discover post-deployment that their voice stack is routing PHI through three to five external APIs they never fully audited.

Speech-to-text from one vendor. LLM inference from another. Text-to-speech from a third.

Each hop is a separate subprocessor, a separate logging policy, and a separate retention window. The BAA does not follow the audio. The audio just travels.

The infrastructure-first evaluation rubric applied across all eight profiles below asks one question before anything else: does PHI leave the buyer's environment at any point during a call? That single architectural fact determines actual exposure more reliably than any compliance checkbox on a vendor's security page.

How to Read This Comparison#

79.7% Of large healthcare breaches from hacking/IT incidents

Each profile below covers deployment model, BAA availability, and the one structural trade-off that matters most to a healthcare security team. The list is ordered by how completely each platform closes the PHI data-path risk, not by feature count or price.

PHI Data-Path Checklist for Selecting a HIPAA Compliant Voice AI Platform#

Evaluation Question

Why It Matters#

1#

• Does PHI leave your environment at any point during a call?
  • Determines actual subprocessor exposure, not just contractual scope

2#

• Is the deployment single-tenant or multi-tenant?
  • Shared inference clusters create co-mingled PHI risk

3#

• Can the vendor provide a full subprocessor list pre-NDA?
  • Undisclosed fourth-party pipelines are a primary breach vector

4#

• Is encryption verifiable (TLS) on every leg, audio, STT, LLM, TTS?
  • 45 CFR § 164.312(e) requires transmission security on every system touching ePHI

5#

• Does the platform produce immutable, timestamped audit logs per § 164.312(b)?
  • BAAs don't generate logs; the infrastructure must

6#

• Is the BAA available without an enterprise-only contract gate?
  • Determines whether smaller deployments can access compliance coverage

7#

• What is the platform's EHR integration encryption posture on the write-back leg?
  • Post-call API calls carry PHI and require their own security controls

8#

• Has the vendor completed a SOC 2 Type II audit and can they share the report?
  • Third-party attestation is the minimum verifiable proof of security controls

1. Bland.ai — Best HIPAA Compliant Voice AI for High-Stakes Enterprise Calls#

Bland.ai runs its entire voice stack — speech recognition, language model inference, and speech synthesis — on its own dedicated GPU infrastructure, which means there are no third-party API hops for PHI to traverse during a call. Bland's enterprise architecture documentation confirms a single-tenant, dedicated GPU deployment model with no shared inference layer, a structural distinction that reduces subprocessor scope to zero external API hops for PHI in transit. For enterprise healthcare buyers, this is the architectural difference that changes the security review: the BAA is available on the Enterprise tier, but more importantly, the question of which subprocessors touch PHI has a one-word answer: none.

The trade-off is that this level of infrastructure control is scoped to Enterprise contracts with custom pricing, so smaller teams or early-stage deployments that need a self-service path will need to evaluate whether the compliance architecture justifies the procurement process. For regulated organizations running claim intake, prior authorization calls, or patient outreach at volume, it is the platform on this list where infrastructure architecture and compliance posture most directly align, because PHI never exits dedicated infrastructure during a call, a structural property verifiable in the deployment architecture rather than inferred from contract language.

2. Deepgram — Best HIPAA Compliant Speech-to-Text Engine for Voice Pipelines#

Deepgram offers a HIPAA-eligible BAA for its speech-to-text API, but it is a component, not a complete voice AI platform. Healthcare teams building a custom pipeline can use Deepgram as the STT layer with a BAA in place, but they still own the compliance burden for every other node: the LLM, the TTS engine, the telephony layer, and the call logging infrastructure. That is the critical limitation for buyers who want a single compliance perimeter. Deepgram is the right pick when your team has the engineering capacity to assemble and audit a full stack, and when STT accuracy at low latency is the primary technical requirement. It is not the right pick if you want the compliance story to be simple.

3. Suki AI — Best HIPAA Compliant Voice AI for Ambient Clinical Documentation
#

Suki AI is purpose-built for ambient clinical documentation, capturing physician-patient conversations and structuring them into EHR-compatible notes in real time. Its HIPAA compliance posture is strong within that specific workflow, and it has meaningful clinical adoption. The structural limitation for enterprise buyers evaluating it against a broader voice AI use case is scope: Suki is not a programmable phone agent platform.

It does not handle outbound calling, claim intake, or patient outreach automation. If your compliance requirement is ambient documentation for clinical staff, Suki belongs on the shortlist. If you need to automate inbound or outbound patient calls at scale, the platform was not designed for that workflow.

4. Rasa — Best HIPAA Compliant Voice AI for On-Premises Conversational Deployment#

Rasa's open-source framework supports fully on-premises deployment, which means a healthcare organization can run the entire conversational AI stack inside its own environment without any data leaving to a third-party cloud. That data-sovereignty posture is genuinely strong for regulated buyers with strict network boundary requirements. The real trade-off is operational: running Rasa in production requires meaningful DevOps investment.

Healthcare IT teams consistently report that the self-hosting burden — model management, infrastructure maintenance, and custom integration work — adds up faster than initial estimates suggest. Rasa is the right architecture for organizations with a dedicated ML engineering team and a hard requirement to keep every inference call on-premises. Healthcare IT practitioners and Rasa community documentation consistently note that production deployments typically require substantial setup and integration time; it is not the right fit if you need a production-ready deployment in weeks rather than months.

5. Hamming AI — Best HIPAA Compliant Voice AI Testing and QA Platform#

Hamming AI occupies a distinct category: it is a testing and quality assurance platform for voice AI pipelines, not a patient-facing call automation tool. For healthcare organizations that have already deployed a voice AI stack and need to validate it against compliance scenarios, edge cases, and failure modes before go-live, Hamming fills a real gap. The HIPAA compliance posture depends on how test data is handled, specifically whether synthetic or real PHI is used in test calls, and buyers should verify the data handling policy before use. The limitation is that Hamming does not replace a production voice AI platform; it sits alongside one. Its value materializes most clearly in regulated environments where gray-team and red-team testing is a deployment requirement.

6. Coval — Best HIPAA Compliant Voice AI for Multi-Vendor Pipeline Architecture#

Coval is designed to work across multi-vendor voice AI architectures, providing evaluation and observability tooling for pipelines that combine separate STT, LLM, and TTS components. For healthcare teams that have already committed to a multi-vendor stack and need compliance visibility across the full data path, Coval adds a useful audit layer. The structural limitation is the same one that applies to any multi-vendor architecture: the compliance perimeter is only as strong as the weakest subprocessor in the chain, and Coval's observability tooling does not eliminate the underlying PHI exposure risk at each API hop. It makes the risk more visible. That is valuable, but it is not the same as eliminating it.

7. Prosper AI — Best HIPAA Compliant Voice AI for Healthcare Revenue Cycle Automation#

Prosper AI focuses on revenue cycle workflows, including eligibility verification, claim status calls, and prior authorization follow-up, which are among the highest-PHI-density call types in healthcare operations. The platform's compliance posture is oriented toward these specific workflows, and buyers evaluating it should verify the deployment model and subprocessor list before assuming the BAA covers the full data path. The practical trade-off is specialization: Prosper AI's depth in revenue cycle workflows is its strength, but organizations that need a general-purpose voice AI platform for patient outreach, scheduling, and intake alongside RCM automation may find the scope limiting.

8. Smallest.ai — Best HIPAA Compliant Voice AI for Lightweight On-Premises Enterprise Deployment#

Smallest.ai positions itself around lightweight, low-latency voice AI that can be deployed on-premises or in a private cloud, which gives it a credible data-sovereignty story for healthcare buyers with strict network boundary requirements. The trade-off relative to more established platforms is ecosystem maturity: integration depth with major EHR systems, enterprise support infrastructure, and documented compliance audit trails are areas where buyers should ask detailed questions before committing. Smallest.ai is worth evaluating when the primary requirement is a deployable, self-contained voice stack with minimal external dependencies, and when the team has the technical capacity to handle integration work independently.

Healthcare Use Cases and Workflows — What HIPAA Compliant Voice AI Actually Automates#

Not every healthcare voice AI workflow carries the same compliance weight, and treating them as equivalent is where well-intentioned deployments quietly become liability events. A scheduling reminder that confirms a patient's name and callback number sits at a fundamentally different point on the PHI exposure spectrum than a prior authorization call that captures diagnosis codes, NPI identifiers, and payer IDs inside a single conversation.

The PHI Exposure Spectrum — Claim Intake vs. Appointment Reminders#

The critical difference is not volume; it is density. An appointment reminder touches only a handful of PHI elements. A claim intake call can surface many PHI elements within a single session, each one passing through the speech-to-text layer, the inference layer, and the synthesis layer before the call ends. Under 45 CFR § 164.312(b), every system that touches PHI requires immutable, timestamped audit logs. A BAA does not produce those logs. Only a platform that enforces redaction and logging at the workflow level, inside a controlled infrastructure boundary, can.

Five Workflows Where Voice AI Outperforms Human Agents, and Where PHI Risk Peaks#

The five workflows where AI phone agents consistently outperform human agents are:

• Appointment scheduling
• Insurance eligibility verification
• Prior authorization status
• Claim intake and status updates
• Post-discharge follow-up

PHI risk peaks at claim intake and prior auth, where diagnosis codes and payer IDs concentrate in a single session. Post-discharge follow-up carries moderate PHI exposure but high volume, and industry data shows automated outreach improves patient contact rates significantly compared to manual callback attempts.

Graceful Escalation — Passing Call Context Without Passing Unredacted PHI#

When escalation to a human agent is necessary, the transfer must carry enough context for the agent to continue the conversation without asking the patient to repeat sensitive information. The compliance risk here is subtle: a full transcript passed in plain text to an agent desktop is itself a PHI exposure event if that desktop is not inside the covered environment. Structured context summaries, with PHI fields tokenized before transfer, satisfy both the operational need and the access control requirement.

EHR and System Integrations — Why HIPAA Compliant Voice AI Must Connect Without Exposing Data#

The assumption that EHR integration is just a technical plumbing task handled by the vendor's implementation team is exactly where compliance exposure quietly compounds. The moment a voice AI platform reaches out to Epic, Cerner, or Athenahealth to confirm an appointment or pull eligibility data, PHI is in motion again across a second data path that the original BAA was never written to govern. Healthcare teams we work with consistently find that this reality lands harder than expected: getting a BAA signed feels like the finish line, but actually retrieving and storing data in an EHR is an entirely different compliance challenge, one that touches authentication architecture, data residency, and every integration hop in between.

When voice AI doesn't connect cleanly to the scheduling or EHR system, the result isn't a streamlined workflow; it's yet another disconnected inbox that adds cleanup burden to already-stretched staff.

The Post-Call PHI Surface — Why EHR Write-Back Is a Second Attack Vector#

Most teams think about PHI risk during the call. The write-back is where the second exposure window opens. A voice agent that confirms an appointment and pushes that confirmation to Epic in real time is executing an outbound API call carrying patient identifiers, appointment details, and potentially diagnosis-adjacent context.

If that API call routes through a cloud intermediary without its own BAA, the covered entity owns the breach, not the voice vendor. The 2024 Change Healthcare incident demonstrated precisely this pattern: attackers targeted third-party integration layers, not the core EHR, as broader industry trends around third-party API risk in healthcare have made clear. This is not a hypothetical edge case.

The same integration surface that makes AI calling operationally valuable — the ability to push call outcomes, appointment confirmations, and intake data directly into existing CRM and contact center workflows without manual entry — is the surface that demands the most rigorous compliance scrutiny. Bland's integrations platform connects AI call data into existing workflows, including CRM systems and Amazon Connect, so that teams already on those platforms can add AI voice without migrating infrastructure. But the compliance question that must precede any integration decision is whether every hop in that data path is covered by an appropriate agreement and encrypted end-to-end.

Encryption on Both Legs — In-Transit Protection Beyond the Audio#

HL7 FHIR R4 security specifications require TLS encryption on every API call that carries PHI, including the outbound call from a voice platform to an EHR endpoint. Both legs require verifiable, end-to-end TLS. If the voice platform routes the EHR API call through a shared middleware layer, encryption continuity depends on that middleware's configuration, which the buyer typically cannot inspect without going under NDA first. For organizations on Amazon Connect, for instance, the question is not only whether the AI voice layer is encrypted but whether the handoff between Bland's Amazon Connect integration and any downstream EHR API call preserves that encryption chain without passing through an uncovered intermediary.

Authentication Depth That Reaches Every Integration Endpoint#

Authentication gaps at the integration layer are a primary vector for lateral PHI exposure, a pattern most teams in regulated environments report encountering well after initial deployment. Token-based access controls must be enforced at every API hop in the chain, not just at the perimeter. Specifically:

• JWT signatures scoped to the minimum necessary data
• Role-based permissions enforced at every API hop
• On-premises or VPC deployment to keep inference inside the compliance boundary
• Data residency controls governing where PHI is stored and processed

Bland's Enterprise tier includes JWT signature support, BAA availability, on-premises and VPC deployment options, and data residency controls — the infrastructure layer that regulated organizations require before any EHR integration can be considered compliant. Compliance documentation is available under NDA, and a forward-deployed engineering team scopes, builds, and goes live with the first agent within an accelerated deployment framework, which means the authentication architecture is configured with your specific integration endpoints in view from day one, not retrofitted after deployment. For health systems that need to scale outbound appointment reminders, inbound intake, or eligibility calls without proportionally growing headcount, that deployment structure matters as much as the per-minute rate.

The operational promise of voice AI, handling high call volumes around the clock without adding full-time staff, only holds if the integration layer doesn't create a compliance liability that requires a separate remediation workstream to manage. Getting both right, simultaneously, is the actual implementation challenge.

Next steps#

If your security team is blocked on voice AI approvals because you cannot verify where PHI travels across the STT, LLM, and TTS chain, the path forward starts with eliminating the subprocessor question entirely through a self-hosted, single-tenant stack. Start with our voice AI.

The breach record shows that hacking and IT incidents drove 79.7% of large healthcare breaches in 2023, meaning infrastructure gaps, not missing signatures, are where PHI exposure actually concentrates. That means a BAA signed at the contract layer does nothing to seal the data path during a live call. At the same time, HIPAA's audit controls standard under 45 CFR 164.312(b) requires immutable, timestamped logs from every system that touches PHI, and a BAA cannot produce those logs, only the infrastructure can. Together, these two facts point to one evaluation criterion: choose a platform where PHI never exits dedicated infrastructure during a call, making the subprocessor list verifiably short and the audit trail structurally enforceable.

Start with Bland.ai's voice AI platform, where STT, LLM inference, and TTS run on dedicated infrastructure with no external API hops for PHI in transit. From there, the compliance review shifts from chasing subprocessor disclosures to confirming an architecture that closes the data-path risk by design.

Frequently Asked Questions#

If a vendor gives me a signed BAA, is that enough to make my voice AI deployment HIPAA compliant?#

No, a BAA is a liability-allocation document, not a technical control. It does not encrypt a single byte of data, restrict a subprocessor from logging audio, or prevent PHI from traversing an undisclosed fourth-party pipeline. Hacking and IT incidents accounted for nearly 80% of the 725 large healthcare breaches reported in 2023, meaning the failure point was technical infrastructure, not missing signatures.

How does PHI leak through a voice AI stack even when every contract looks clean?#

A typical cloud voice AI call passes through up to five discrete nodes — audio ingestion, speech-to-text transcription, LLM inference, text-to-speech synthesis, and call storage — and each handoff is a potential exposure point. A common deployment pattern sends raw audio to a speech-to-text API and passes the unredacted transcript directly to an LLM before any redaction filter fires, meaning a patient's insurance ID or diagnosis code has already traversed an external API endpoint before the storage layer, which is often the only layer the BAA actually covers, ever comes into play.

What should I actually be verifying when I do due diligence on a voice AI vendor's HIPAA posture?#

The key technical question is whether PHI leaves your environment at any point during a call, because that single architectural fact determines actual exposure more reliably than any compliance checkbox on a vendor's security page. You should audit every node in the stack — STT, LLM inference, TTS, telephony, and call logging — and confirm which subprocessors touch PHI in transit, whether encryption is verified at each hop, and whether the platform can produce a timestamped, tamper-evident log of every PHI touchpoint across the call lifecycle as required under HIPAA's audit controls standard (§ 164.312(b)).

Why does it matter which infrastructure layer the HIPAA BAA actually covers?#

Because business associates and third-party vendors account for a significant and growing share of healthcare data breaches, confirming that downstream infrastructure hops are where real PHI exposure concentrates, not at the primary platform layer. A BAA signed with a primary vendor does not automatically extend to every subprocessor that vendor uses for STT, LLM inference, or TTS, and each of those hops carries a separate logging policy and a separate retention window.

Is there a voice AI platform where PHI never leaves dedicated infrastructure during a call?#

Bland.ai's Enterprise tier runs its entire voice stack — speech recognition, LLM inference, and speech synthesis — on dedicated GPU infrastructure with no third-party API hops, so the question of which subprocessors touch PHI has a one-word answer: none. A BAA is available on the Enterprise plan, on-premises or VPC deployment is supported, and a forward-deployed engineering team scopes and ships the first production agent within 30 days.