待翻譯：Natera’s intelligent appointment scheduling with Amazon Bedrock AgentCore

AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。

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: 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. 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. 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 singl [truncated for AI cost control]