Natera 借助 Amazon Bedrock AgentCore 实现智能预约调度

预约采血不应成为已经在应对治疗的肿瘤患者的额外负担。Natera 的服务由 Amazon Bedrock AgentCore 提供支持，可安排采血师上门服务，帮助 Natera 提供更便利的体验。

Natera 是一家专注于无细胞 DNA 检测的全球诊断公司。该公司希望通过更优的方案替代人工预约电话，从而改善患者体验。借助 Amazon Bedrock AgentCore，他们构建了一款自动化语音 Agent，使患者能够通过对话预约，同时维持医疗行业所要求的准确性与合规标准。

本文分享 Natera 基于 Bedrock AgentCore 构建语音预约 Agent 背后的架构模式和设计决策。你将了解 Natera 与 AWS 如何设计一款实时语音 Agent，通过三项核心架构原则连接电话系统、基础模型与后端服务：双 WebSocket 桥接模式、事件驱动的延迟掩蔽技术，以及用于会话中身份验证的渐进式信任模型。本文说明每项设计选择的理由，还展示该架构如何在 500 次端到端通话模拟验证中实现 100% 的工具调用准确率，感知延迟低于 7 秒，且每次完成通话的成本低于 0.01 美元。本文呈现了一套系统设计，说明各项 AWS 服务如何连接，以及 Natera 为何为其实现选择特定集成方案。

我们将介绍 Natera 如何从 Amazon Elastic Container Service (Amazon ECS) 迁移至 Amazon Bedrock AgentCore runtime，包括团队在此过程中如何解决 WebSocket 生命周期与会话状态方面的挑战。

挑战：大规模预约调度的复杂性

Natera 现有的移动采血服务可帮助患者在家中而非前往诊所预约抽血。预约系统为这一工作流提供支持。

患者致电后，需要完成身份验证，并提供三个首选预约日期以及服务地点。之后，由人工预约团队与采血师和供应商协调，确认其中一个建议时段。

该工作流要求通过个人身份标识信息和短消息服务（SMS）验证码完成患者认证；要求与多个第三方供应商系统集成以获取预约可用时间窗口；还要求为复杂场景提供平稳的回退选项。现有系统采用第三方人工智能（AI）提供商处理语音交互与编排，通过 Twilio 提供电话连接，并运行在 Amazon ECS 容器中。尽管系统能够正常运行，团队仍发现了提升准确性、可扩展性和对话参与度的机会。

对于使用 Epic 或 Cerner、且采用标准预约工作流的组织，Amazon Connect Health 提供预构建的患者参与 Agent，可开箱即用地处理身份验证和预约调度。Natera 的使用场景需要定制化的供应商协调能力以及更灵活的电话系统支持，超出了当前预构建解决方案的覆盖范围，因此 AgentCore 成为合适的架构基础。

为什么选择 Amazon Bedrock AgentCore

Natera 选择在 Amazon Bedrock AgentCore 上重建其预约 Agent。该服务可使用任意框架或模型，大规模构建、连接和优化 Agent。他们在评估该服务如何解决核心运营挑战后作出这一选择。团队需要借助自主 AI Agent 大规模满足客户请求，同时不必承担容器基础设施管理和扩缩容配置的负担。AgentCore 的全托管架构减轻了这些运营开销。

同样重要的是，在处理延迟期间维持较高的客户参与度。团队可通过 Amazon Bedrock 中的快速基础模型生成具备上下文感知能力的中间回复，从而保持自然对话。内置记忆管理系统会存储患者此前的活动，使 Agent 能够提供个性化、主动式支持。

Natera 采用 AgentCore 的另一个原因是其内置可观测性。Agent 每次处理请求时，AgentCore 都会捕获每个步骤中发生情况的详细追踪记录。团队可以查看调用了哪些工具、各步骤耗时多久，以及模型作出了何种决策。他们能够端到端追踪单个会话，精确定位延迟发生的位置，无论是在模型推理、工具执行还是记忆检索环节。对于准确性和性能都不容妥协的医疗环境，这种可见性使团队能够快速识别并修复问题，而无需猜测。

解决方案概览

本节介绍 Natera 语音预约 Agent 的端到端架构。该设计遵循三项核心原则，使其能够适配其他实时语音 AI 使用场景：

1. 双 WebSocket 桥接模式通过在电话流媒体与模型推理之间设置编排层，将两者分离。这意味着系统会维持一条到电话服务提供商的 WebSocket 连接，以及另一条到基础模型的 WebSocket 连接，并由编排器管理两者之间的数据流。这样的分离使团队能够独立替换任一侧，例如，在无需重新设计完整系统的前提下，以 Amazon Connect Health 替换 Twilio，或以 Amazon Nova 替换 OpenAI。
2. 事件驱动的延迟掩蔽将感知延迟视为一项一等设计关注点，而不是试图单纯为原始速度优化每个独立组件。当 Agent 需要调用工具，例如查询预约可用性时，该架构会并行生成具备上下文的填充回复，因此患者听到的是自然的确认语，而不是沉默。即使后端操作需要数秒才能完成，这种方法仍可让对话保持流畅。
3. 渐进式信任模型会随着对话推进，逐步提升身份验证和记忆访问的级别。系统不要求患者在进行任何操作之前预先验证身份，而是从低信任度交互开始，并在患者完成认证后逐渐授予其访问更敏感信息的权限。与先设关卡再继续、容易显得事务化的体验相比，这种方式可形成自然的对话流程。

该架构的取舍在于编排复杂度增加。管理两条并发 WebSocket 连接、并行填充内容生成和渐进式记忆会话，需要谨慎进行状态管理。对于更简单的使用场景，例如单轮问答或纯文本 Agent，不采用桥接模式的直接集成可降低开销。

下图展示整体系统架构。该图还说明 Natera 如何将计算层从自主管理的容器迁移到全托管无服务器环境，在保留前述设计原则的同时减轻基础设施运营负担。

图 1：运行在 Amazon Bedrock AgentCore 上的 Natera 语音预约 Agent 架构

从 Amazon ECS 迁移至 AgentCore runtime 的方法

Natera 将其工作负载从 Amazon ECS 迁移至 Bedrock AgentCore runtime。这是一个全托管无服务器环境，可在隔离的微型虚拟机中托管 AI Agent，并提供专用的 CPU、内存和文件系统资源。

为开始迁移，团队首先将语音编排逻辑与容器专用基础设施代码解耦，例如健康检查端点、扩缩容策略和部署清单。完成这一分离后，他们重构了 Agent 的入口点，使其符合 AgentCore runtime 的调用接口，以 AgentCore handler 模式替换 HTTP 服务器初始化。最后一步是将会话状态从容器本地存储迁移到 Bedrock AgentCore memory，后者无需管理单独的状态存储，即可提供持久的跨会话存储能力。

团队在迁移过程中遇到两项主要挑战。第一项是让长生命周期 WebSocket 连接适配 AgentCore runtime 的执行模型。不同于持续运行的 Amazon ECS 任务，AgentCore 微型虚拟机的作用域限定于调用期间。团队通过在 Agent 的运行时上下文中实现连接池来解决这一问题，使 WebSocket 会话能在单次通话期间持续存在，同时由 AgentCore 管理底层计算生命周期。会话状态连续性则带来了另一项挑战。在 Amazon ECS 上，对话状态位于容器本地内存中，并会在重启时丢失。迁移至 AgentCore memory 要求将状态模型重新设计为外部化模式，并按 actor ID 设置键，这最终提升了可靠性，但需要重构所有状态读写路径。

此举消除了管理容器扩缩容、健康检查和部署流水线的运营开销。

请求流程详解

以下章节说明请求流程：从患者拨入电话，到收到预约确认。

通话发起与语音流传输

当患者拨打预约热线时，Twilio 会与运行在 AgentCore runtime 上的 Agent 建立双向 WebSocket 连接。同时，Agent 会与实时语音处理 API 建立第二条 WebSocket 连接，由此形成实时音频桥接。

在入站路径上，Twilio 将原始通话媒体流，也就是患者语音，发送至语音处理服务进行意图识别。在出站路径上，语音处理服务生成音频回复，并通过 Agent 将其流式传回 Twilio，向患者电话传送合成语音。

运行在 AgentCore runtime 上的 Agent 充当两个 WebSocket 通道之间的编排层。它会拦截来自语音处理服务的工具调用请求，执行业务逻辑，并将结果注入回对话上下文。

上下文感知的填充内容生成（延迟掩蔽）

当 Agent 处理工具调用时（步骤 3-5），并行填充循环会启动以维持对话流畅性。该技术的工作方式如下：

Agent 监控语音处理服务 WebSocket 流中的工具调用事件。当工具调用开始时，填充循环会启动一个计时器，该计时器根据特定工具的预期耗时进行校准。例如，身份验证 API 的平均耗时为 2.5 秒，预约 API 的平均耗时为 4 秒。

这些校准数值来自团队在可观测性阶段执行的结构化测量流程。首先，他们使用 AgentCore runtime 的内置追踪导出功能，并在两周具有代表性的通话流量期间，将各工具的延迟事件路由至 Amazon CloudWatch Logs。其次，他们查询这些日志，为每个工具调用建立延迟分布，并提取 P50（中位数）响应时间作为基线。第三，他们从每个工具的 P50 中减去一秒，以设定填充内容触发点，为 Claude Haiku 填充请求预留完成和注入的时间，使其能够在多数来电者察觉到沉默前完成。

结果是形成一张按工具划分的查询表，例如身份验证的触发点为 1.5 秒、预约调度的触发点为 3.0 秒，填充循环会在新工具调用开始时查询该表。采用这一模式的团队可使用支持百分位数的日志分析工具，针对自身工具延迟分布重复相同三个步骤，重新推导自己的查询表。

在校准后的时间间隔（通常是工具调用开始后 1.5 秒），Agent 会通过 Amazon Bedrock 发送请求，以生成具备上下文的回复。提示词遵循以下模板结构：

你是一名预约助手。系统当前正在执行 [TOOL_NAME]。患者最后说的是：“[LAST_UTTERANCE]” 当前工作流步骤：[STEP_NAME]。请恰好生成一句简短句子（少于 15 个词），并且：– 自然地确认短暂等待 – 不得承诺具体结果 – 与当前步骤的上下文相符

系统会生成一句填充语句，例如“让我调取您可选择的时间段”或“我正在向您当地的服务提供商查询可用性”。生成的填充内容会作为中间音频回复注入对话上下文。如果工具调用在填充内容触发间隔之前完成，则不会生成填充内容。这种事件驱动方法避免了为快速操作生成不必要的填充语，同时可掩蔽较慢操作的延迟。

患者身份验证与记忆迁移

Agent 通过分层验证流程认证患者，该流程使用 AgentCore memory 的会话管理能力。

流程从电话号码识别开始。Agent 使用 SHA-256 对来电者电话号码进行哈希处理，并在通过 AgentCore memory 的 会话管理 API 创建新会话时，将该哈希值用作 actor ID。这会创建一个未经认证的会话，Agent 可在其中存储早期对话上下文，例如问候语和初始意图，同时不会暴露敏感患者数据。

随着对话推进，Agent 会通过收集患者的个人身份标识信息完成完整身份验证。在 Natera 的身份服务验证成功后，Agent 使用经验证的患者 ID 作为 actor ID 创建新的已认证会话，从而建立对患者完整历史记录的访问权限。

在两个会话均建立后，Agent 会迁移对话历史。它从未经认证的会话中检索对话轮次，并

Booking a phlebotomy appointment shouldn’t be a hassle for oncology patients already managing treatment. Natera’s service, powered by Amazon Bedrock AgentCore, allows a phlebotomist to come to the patient, helping Natera deliver a more convenient experience.

Natera, a global diagnostics company specializing in cell-free DNA testing, wanted to transform their patient experience by replacing manual scheduling calls with something better. Using Amazon Bedrock AgentCore, they built an automated voice agent that allows patients to book appointments through conversation while maintaining the accuracy and compliance standards required in healthcare.

In this post, we share the architecture pattern and design decisions behind the Natera voice scheduling agent built on Bedrock AgentCore. You learn how Natera and AWS designed a real-time voice agent that bridges telephony, foundation models, and backend services using three core architectural principles: a dual-WebSocket bridge pattern, an event-driven latency-masking technique, and a progressive trust model for mid-conversation authentication. The post explains the rationale for each design choice. It also shows how the architecture delivers 100% tool-calling accuracy during validation across 500 end-to-end call simulations, with sub-7-second perceived latency at less than USD 0.01 per completed call. This post presents a system design showing how each AWS service connects and why Natera made specific integration choices for their implementation.

We walk you through how Natera migrated from Amazon Elastic Container Service (Amazon ECS) to Amazon Bedrock AgentCore runtime, including how the team addressed WebSocket lifecycle and session state challenges along the way.

The challenge: Scheduling complexity at scale

Natera’s current mobile phlebotomy service helps patients schedule blood draw appointments at their homes rather than visiting a clinic. The scheduling system supports this workflow.

Patients call, authenticate, and provide three preferred appointment dates along with their service location. A human scheduling team then coordinates with phlebotomists and vendors to confirm one of the proposed slots.

This workflow requires patient authentication using personal identifiers and Short Message Service (SMS) verification codes, integration with multiple third-party vendor systems for appointment availability windows, and graceful fallback options for complex scenarios. The existing system used a third-party artificial intelligence (AI) provider for voice interactions and orchestration, connected through Twilio for phone connectivity and running on Amazon ECS containers. While functional, the team identified opportunities to improve accuracy, scalability, and conversational engagement.

For organizations using Epic or Cerner with standard appointment booking workflows, Amazon Connect Health offers pre-built patient engagement agents that handle verification and scheduling out of the box. Natera’s use case required custom vendor coordination and telephony flexibility beyond what pre-built solutions support today, making AgentCore the right architectural foundation.

Why Amazon Bedrock AgentCore

Natera chose to rebuild their scheduling agent on Amazon Bedrock AgentCore, a service to build, connect, and optimize agents at scale with any framework or model. They chose it after evaluating how the service could address their core operational challenges. The team needed to fulfill customer requests with autonomous AI agents at scale, without the burden of managing container infrastructure or scaling configuration. The fully managed architecture of AgentCore alleviated that operational overhead.

Equally important was maintaining high customer engagement during processing delays, which they could achieve by generating context-aware intermediate responses using fast foundation models through Amazon Bedrock to keep conversations natural. The built-in memory management system stores previous patient activities so the agent can deliver personalized, proactive support.

Natera also adopted AgentCore for its built-in observability. Every time the agent processes a request, AgentCore captures a detailed trace of what happened at each step. Teams can see which tools were called, how long each step took, and what the model decided. They can track individual sessions end-to-end and pinpoint exactly where latency occurs, whether in model inference, tool execution, or memory retrieval. For a healthcare environment where accuracy and performance are non-negotiable, this level of visibility makes it possible to identify and fix issues quickly without guessing.

Solution overview

This section describes the end-to-end architecture of Natera’s voice scheduling agent. The design follows three core principles that make it adaptable to other real-time voice AI use cases:

1. The dual-WebSocket bridge pattern separates telephony streaming from model inference by placing an orchestration layer between them. This means the system maintains one WebSocket connection to the telephony provider and another to the foundation model, with the orchestrator managing the flow between them. This separation gives teams the flexibility to swap either side independently, for example, replacing Twilio with Amazon Connect Health or OpenAI with Amazon Nova without redesigning the full system.
2. Event-driven latency masking treats perceived latency as a first-class design concern rather than trying to optimize each individual component for raw speed. When the agent needs to call a tool such as checking appointment availability, the architecture generates contextual filler responses in parallel, so the patient hears a natural acknowledgment instead of silence. This approach keeps the conversation feeling fluid even when backend operations take several seconds to complete.
3. A progressive trust model escalates authentication and memory access incrementally as the conversation unfolds. Rather than requiring patients to verify their identity upfront before anything can happen, the system begins with a low-trust interaction and gradually grants access to more sensitive information as the patient is authenticated. This creates a natural conversation flow instead of a gate-then-proceed experience that feels transactional.

The decision point of this architecture is increased orchestration complexity. Managing two concurrent WebSocket connections, parallel filler generation, and progressive memory sessions requires careful state management. For simpler use cases (such as single-turn Q&A or text-only agents), direct integration without the bridge pattern would reduce overhead.

The following diagram illustrates the overall system architecture. It also shows how Natera transitioned the compute layer from self-managed containers to a fully managed serverless environment, preserving the preceding design principles while alleviating infrastructure operations.

Figure 1: Architecture of Natera’s voice scheduling agent on Amazon Bedrock AgentCore

Migration approach from Amazon ECS to AgentCore runtime

Natera migrated their workloads from Amazon ECS to Bedrock AgentCore runtime. This is a fully managed serverless environment that hosts AI agents in isolated microVMs with dedicated CPU, memory, and filesystem resources.

To begin the migration, the team decoupled the voice orchestration logic from container-specific infrastructure code like health check endpoints, scaling policies, and deployment manifests. With that separation in place, they refactored the agent’s entry point to conform to the invocation interface of AgentCore runtime, replacing HTTP server initialization with the AgentCore handler pattern. The last piece was migrating session state from container-local storage to Bedrock AgentCore memory, which provided durable cross-session persistence without managing a separate state store.

The team encountered two primary challenges during this migration. One was adapting long-lived WebSocket connections to the execution model of AgentCore runtime. Unlike Amazon ECS tasks that run indefinitely, AgentCore microVMs are scoped to the invocation. The team addressed this by implementing connection pooling within the agent’s runtime context, allowing WebSocket sessions to persist across the duration of a single call while AgentCore managed the underlying compute lifecycle. Session state continuity posed a separate challenge. On Amazon ECS, the conversation state lived in container-local memory and was lost on restarts. Moving to AgentCore memory required redesigning the state model to be externalized and keyed by actor ID, which ultimately improved reliability but required refactoring all state read/write paths.

This removed the operational overhead of managing container scaling, health checks, and deployment pipelines.

Request flow walkthrough

The following sections describe the request flow, from the moment a patient dials in to when they receive a confirmed appointment.

Call initiation and voice streaming

When a patient calls the scheduling line, Twilio establishes a bi-directional WebSocket connection to the agent running AgentCore runtime. Simultaneously, the agent opens a second WebSocket connection to a real-time voice processing API. This creates a real-time audio bridge.

On the inbound path, Twilio streams raw call media (patient speech) to a voice processing service for intent recognition. On the outbound path, the voice processing service generates audio responses and streams them back through the agent to Twilio, delivering synthesized speech to the patient’s phone.

The agent on AgentCore runtime acts as the orchestration layer between these two WebSocket channels. It intercepts tool-call requests from the voice processing service, executes business logic, and injects results back into the conversation context.

Context-aware filler generation (latency masking)

While the agent processes tool calls (Steps 3-5), a parallel filler loop activates to maintain conversational flow. The technique works as follows:

The agent monitors tool-call events from the voice processing service’s WebSocket stream. When a tool call begins, the filler loop starts with a timer calibrated to the expected duration of that specific tool (for example, authentication APIs average 2.5 seconds and scheduling APIs average 4 seconds).

These calibration values come from a structured measurement process the team ran during the observability phase. First, they used the built-in trace export of AgentCore runtime and routed per-tool latency events to Amazon CloudWatch Logs over a two-week window of representative call traffic. Second, they queried the logs to build a latency distribution for each tool call, extracting the P50 (median) response time as the baseline. Third, they subtracted one second from each tool’s P50 to set the filler trigger point, giving the Claude Haiku filler request time to complete and be injected before most callers would notice silence.

The result is a per-tool lookup table (for example, an authentication trigger at 1.5 s and scheduling trigger at 3.0 s) that the filler loop consults when a new tool call begins. Teams adopting this pattern can re-derive their own table by repeating the same three steps against their own tool latency distributions using a percentile-capable log analytics tool.

At the calibrated interval, typically 1.5 seconds into a tool call, the agent sends a request through Amazon Bedrock to produce contextual responses. The prompt follows this template structure:

You are a scheduling assistant. The system is currently executing [TOOL_NAME]. The patient last said: “[LAST_UTTERANCE]” Current workflow step: [STEP_NAME] Generate exactly one short sentence (under 15 words) that: – Acknowledges the brief wait naturally – Does NOT promise a specific outcome – Matches the context of the current step

The system generates a single filler sentence (for example, “Let me pull up your available time slots” or “I’m checking availability with your local provider”). The generated filler is injected as an intermediate audio response into the conversation context. If the tool call completes before the filler interval, the filler is suppressed. This event-driven approach avoids unnecessary fillers for fast operations while masking delays for slower ones.

Patient authentication and memory transfer

The agent authenticates the patient through a tiered verification process that uses the session management capabilities of AgentCore memory.

The process starts with phone number identification. The agent hashes the caller’s phone number using SHA-256 and uses the hash as the actor ID when creating a new session through the session management API of AgentCore memory. This creates an unauthenticated session where the agent stores early conversation context, such as the greeting and initial intent, without exposing sensitive patient data.

Once the conversation progresses, the agent performs full identity verification by collecting personal identifiers from the patient. Upon successful verification against Natera’s identity service, the agent creates a new authenticated session using the verified patient ID as the actor ID, establishing access to the patient’s full history.

With both sessions established, the agent migrates the conversation history. It retrieves the conversation turns from the unauthenticated session and injects them into the authenticated session through the session history APIs of AgentCore memory (see AgentCore memory documentation). This provides continuity without requiring the patient to repeat information. The unauthenticated session is then marked as merged and excluded from future retrievals.

This transition pattern supports progressive trust. Basic interactions such as answering general questions proceed with phone-number-level identification. But sensitive operations such as confirming appointments or accessing health records require full verification.

Personalized context retrieval

With complete authentication, the agent retrieves the patient’s historical context from two sources. From Bedrock AgentCore memory, the agent retrieves previous conversation history, appointment preferences, and activity data from prior interactions. AgentCore memory provides both short-term storage (current session conversation) and long-term storage (cross-session patient patterns). The underlying data persists in Amazon DynamoDB for durable, low latency read/write access at scale.

From the Amazon Managed Streaming for Apache Kafka (Amazon MSK) and AWS Lambda event pipeline, the agent receives patient activity events from other channels (activity on web portals, previous SMS, email, and call traffic). A Lambda function consumes events from Amazon MSK and writes relevant activity summaries to AgentCore memory. This gives the voice agent comprehensive context even for patients using AI for the first time.

Knowledge retrieval-augmented generation (RAG)

Patients frequently ask questions during the scheduling call about the blood draw process, what to expect, how to prepare, or insurance coverage. These questions often go beyond the agent’s predefined prompts.

The system uses Amazon Bedrock Knowledge Bases, the fully managed retrieval capability, to extend the agent’s knowledge in real time. Natera stores FAQ documents, procedure guides, and policy information in Amazon Simple Storage Service (Amazon S3), removing the need to maintain dedicated vector database infrastructure. Amazon Titan Text Embeddings V2 converts documents and queries into vector representations for semantic search. A custom hierarchical chunking strategy segments documents at multiple levels of detail (section, paragraph, sentence). This supports precise retrieval that matches the specificity of patient questions.

Based on internal testing with a dataset of 200 representative patient inquiries during the development phase, this configuration achieves over 90% response accuracy for general patient inquiries. This keeps the conversation flowing without requiring an agent to transfer to a human operator.

Appointment scheduling and confirmation

With the patient authenticated and their preferences loaded, the agent executes the core scheduling workflow. The agent first retrieves product type and order information to announce important product-specific reminders before proceeding. It then evaluates the available appointment time window based on the patient’s order information and collects three preferred appointment dates along with the patient’s service location. The agent interacts with other Natera services to submit the mobile phlebotomy appointment request and informs the patient of the appointment details. Finally, it stores the confirmed appointment in the patient’s memory profile for future reference.

For model availability by Region, refer to Supported models by AWS Region in Amazon Bedrock.

Compliance and security

The system implements Amazon Bedrock Guardrails to maintain conversational safety and output quality, and it runs as a HIPAA-eligible AWS service under a Business Associate Agreement (BAA). These configurations fall into three areas: data privacy, conversational safety, and output integrity.

Data privacy and access control are foundational to the system’s design. The system processes and stores protected health information (PHI) within HIPAA-eligible AWS services under a BAA. Guardrails provides output-level controls that block the agent from reading back sensitive identifiers such as SSNs, credit cards, or insurance IDs during voice interactions, helping prevent verbal disclosure even though the underlying infrastructure handles this data securely. Access to tools that process personal information is gated behind identity verification. Until a patient is authenticated, those tools are not exposed to the agent. Even after verification, tool access is scoped exclusively to the verified patient’s session. The agent has no technical means to look up another patient’s data or fetch personal information for an unverified caller.

The voice processing architecture operates under data processing agreements with encryption requirements. Natera is exploring fully managed AWS services to keep all audio processing within the BAA boundary. Organizations with stricter data residency requirements can adopt this path today.

Conversational safety guardrails define the boundaries of what the agent can and cannot do during patient interaction. The agent does not provide medical advice, diagnosis, or result interpretation beyond what verified tool calls return. When the system detects profanity, distress signals, emergency language, or certain flagged keywords, it escalates the conversation to a human agent. The system also prevents SMS communication until it has verified the patient’s communication preferences and received verbal consent.

Output quality and RAG integrity guardrails make sure the agent’s responses are accurate and grounded. Deterministic verdicts prevent repetition, detect out-of-context responses, and flag suspicious content before it reaches the patient. When the agent interacts with the knowledge base, hallucination detection and mitigation run before a RAG response is generated. Similarity scoring and relevancy evaluation further validate RAG responses before they are surfaced to the patient.

Results

After four months of iterative development and testing across 500 end-to-end call simulations, the solution demonstrated strong performance across accuracy and latency.

The orchestrator achieved 100% tool-calling accuracy during validation across all 500 test scenarios, correctly routing every request to the appropriate specialized agent. Parameter extraction was equally precise: every tool invocation received correctly structured parameters during simulation testing. These accuracy metrics were validated through the built-in trace analysis of AgentCore, which logs every agent loop iteration and compares invoked tools and parameters against expected outputs.

Perceived latency landed at a 6.8-second median, measured end-to-end from patient input to first meaningful response including voice processing. The Bedrock-only portion measured 6.2 seconds. These figures were calculated from session timestamps captured through the latency breakdown instrumentation of AgentCore across a representative sample of real patient interactions.

Per-call cost remained below USD 0.01 per completed call (measured as total cost for a full end-to-end patient interaction including model inference, tool execution, and memory operations, not per individual conversational turn).

The voice agent handles complete appointment booking flows from patient verification through confirmation, including identity verification, scheduling preferences, and confirmation details. Response accuracy exceeded 90%, assessed by comparing agent responses against a human-reviewed ground truth dataset of scheduling outcomes and scored on correctness of appointment details, eligibility verification, and patient-specific context retrieval.

What the team learned

Bringing this system to production surfaced the following challenges:

Latency perception matters more than raw speed. Early demos revealed 3-5 seconds of silence between user input and agent response, creating awkward pauses that risked patients abandoning AI for a human agent. The team discovered that the bottleneck wasn’t large language model (LLM) inference, but external service calls like APIs and authentication checks. The breakthrough came from observing that human agents take longer than AI to complete the same tasks but manage wait time naturally, saying things like “Let me check that for you.” Patients don’t perceive this as a delay. By generating contextual filler responses in parallel with tool execution, the team applied the same principle to the voice agent and alleviated dead air without needing to make backend calls faster.

Diverse input testing revealed blind spots early. Voice recognition handled common names well but misrecognized uncommon ethnic names, creating a challenge for patient authentication. The team built a name spelling helper tool that activates when confidence is low and asks patients to spell names letter by letter. This kind of edge case only surfaced through testing with representative patient populations, reinforcing the importance of building diverse test suites before production deployment.

Per-step observability exposed the real bottlenecks. The built-in trace analysis of Bedrock AgentCore captures every agent loop iteration, including tool-call latency, LLM inference time, and memory retrieval duration. This instrumentation revealed that 70% of perceived latency came from a single vendor API rather than the LLM. Without per-step tracing, the team would have optimized the wrong component. End-to-end metrics are insufficient for agentic systems. Each tool call needs independent instrumentation to surface the actual constraint.

Progressive authentication requires upfront design. The memory handoff pattern from hashed phone number to authenticated patient ID worked well but required careful planning from the start. Retrofitting progressive trust into an agent that assumes a single identity model is significantly harder. We recommend planning your actor ID strategy and memory handoff flow before writing agent logic. AgentCore memory supports this pattern natively, but you must design it explicitly rather than adding it after the fact.

Conclusion

Natera’s voice agent has completed validation testing and is now in production for inbound mobile phlebotomy scheduling, with expansion to omnichannel support for both inbound and outbound call handling underway. The mobile phlebotomy scheduling use case proved that AI-powered voice agents can deliver healthcare-grade accuracy while reducing operational cost and patient friction.

Early production data reinforces these results. Over a four-week reporting window, the system built on AgentCore handled 4,744 calls, a 5.5% increase over the prior system. It also reduced premature call endings: the short-call rate (calls under 30 seconds) dropped from 22% to 12%, indicating patients stay engaged longer rather than abandoning to reach a human agent. Survey captures also expanded significantly, with Net Promoter Score (NPS) response rates climbing 47% (from 1.09% to 1.60%), giving the team a much broader window into patient sentiment. Satisfaction scores remained broadly stable, with promoter and detractor shares essentially unchanged despite the larger sample. Verification completion improved slightly (66% compared to 64%), and average call duration for resolved interactions increased from 79 seconds to 101 seconds. This is consistent with the design goal of keeping patients in-flow longer rather than escalating early.

Looking ahead, Natera plans to extend this foundation across operations, customer success, and lab teams using Amazon Bedrock AgentCore as the backbone for multi-agent coordination. The goal is to give non-technical teams the ability to build and deploy AI agents through natural language, turning what once required engineering resources into something a team can create in minutes. As Natera scales these capabilities, services like AgentCore runtime, AgentCore memory, and the foundation model framework of Amazon Bedrock will continue to underpin their approach to making healthcare interactions simpler for patients and more efficient for the teams that serve them.

Next steps

If you’re building voice agents or conversational AI for healthcare, life sciences, or other regulated industries, here are ways to get started with the services covered in this post:

• Deploy your first agent on AgentCore runtime. If you’re currently running agent workloads on containers and want to alleviate infrastructure management, follow the AgentCore runtime getting started guide to deploy a serverless agent in under 30 minutes.
• Add session memory to an existing agent. If your agent loses context between interactions or requires users to repeat information, integrate the AgentCore memory session management APIs to persist conversation state across sessions without managing your own state store.
• Reduce perceived latency with event-driven filler generation. If your voice agent has noticeable pauses during tool calls, implement the filler generation pattern described in this post using the AgentCore streaming invocation mode to generate contextual responses in parallel with backend operations.
• Build a progressive authentication flow. If your application handles sensitive data and you want to avoid upfront authentication gates, use the AgentCore memory actor-based session model to escalate trust incrementally as users verify their identity mid-conversation.

---

About the authors

Cem Onan

Cem is a Software Architect at Natera, bringing four years of expertise in the development of omni-channel communication systems. Over the past year, he has been designing an AI-driven call center, where intelligent agents manage patient inquiries regarding test statuses, billing inquiries, and mobile phlebotomy. He is a specialist in serverless architecture and maintains a passion for traveling.

Tamara Gagliardi

Tamara is a Senior Solutions Architect at AWS with over 15 years of experience in the technology field, spanning across industries including financial services, retail and manufacturing. For the past several years, she has focused her expertise on the healthcare and life sciences sector, partnering closely with medical devices and bio-diagnostic customers to accelerate their cloud journeys. As a trusted technical advisor, Tamara helps organizations translate complex business challenges into scalable, secure technical solutions with a particular emphasis on generative AI, where she guides customers in identifying high-impact use cases and architecting intelligent workflows.

Veronica Rule

Veronica is a Senior Customer Solutions Manager at AWS with over 10 years of experience supporting healthcare and life science customers on their cloud journey. She specializes in guiding organizations through AI/ML adoption, agentic AI strategies, and cloud transformation initiatives. Veronica has been instrumental in helping Natera become a leading Bedrock and AgentCore customer, facilitating strategic partnerships between customer engineering teams and product leadership to accelerate innovation in patient care. She is passionate about bridging the gap between advanced AI capabilities and real-world health care and life sciences outcomes.