Natera runs genetic testing labs that generate thousands of support tickets. Their SWARM system (Support Workflow Automation and Response Management) now handles 96.2% of those tickets automatically, responding 130x faster than the human baseline. The interesting part is not the speed claim. It’s the plumbing: how they encoded institutional knowledge, drew tool boundaries, orchestrated multi-agent coordination, and evaluated the system before production.
This is a rare look at production agent infrastructure in a regulated healthcare environment. The architecture choices expose real trade-offs between retrieval-augmented generation (RAG), hard-coded rules, and agent autonomy.
Architecture Overview
SWARM sits on Amazon Bedrock AgentCore, which provides the orchestration layer. The system has three main components:
- Knowledge base: Institutional SOPs, lab protocols, and historical ticket resolutions stored as vector embeddings
- Tool layer: API integrations for lab information systems (LIMS), inventory databases, and ticketing platforms
- Orchestration: AgentCore routes requests, manages state, and coordinates tool calls
The flow starts when a ticket arrives. AgentCore parses the request, retrieves relevant context from the knowledge base, selects tools, and generates a response. If the confidence score falls below a threshold, the ticket escalates to a human operator.
Knowledge Base Construction
Natera’s knowledge base is not a dump of documentation. They structured it around decision trees:
- Symptom-to-action mappings: “If instrument X shows error Y, run diagnostic Z”
- Escalation criteria: When to page a senior tech versus when to auto-resolve
- Compliance boundaries: Which actions require human approval under CLIA regulations
The knowledge base uses Amazon Bedrock’s built-in RAG pipeline. Documents are chunked, embedded with Titan Embeddings, and stored in OpenSearch Serverless. At query time, the system retrieves the top-k chunks and passes them as context to the LLM.
The self-healing claim refers to a feedback loop: when a human operator overrides an agent decision, that correction gets logged. Periodically, engineers review overrides and update the knowledge base. This is not automatic schema drift handling. It’s a manual review process with tooling to surface patterns.
Tool Boundaries and Orchestration
AgentCore’s orchestration layer decides which tools to invoke based on the LLM’s function-calling output. Natera defined tools for:
- LIMS queries: Retrieve sample status, instrument logs, and test results
- Inventory checks: Verify reagent availability and expiration dates
- Ticket updates: Post responses, change status, and assign owners
Each tool has a schema that defines inputs, outputs, and error modes. The LLM generates a tool call, AgentCore validates the schema, executes the call, and feeds the result back to the LLM for the next step.
Multi-Agent Coordination
Some tickets require multiple agents. For example, a reagent shortage might trigger:
- An inventory agent to check stock levels
- A procurement agent to generate a purchase order
- A scheduling agent to delay affected tests
AgentCore does not have built-in multi-agent orchestration. Natera implemented a coordinator pattern: a parent agent receives the ticket, spawns child agents for subtasks, and aggregates their outputs. The parent agent maintains a shared state object that child agents read and write.
This introduces a failure mode: if two child agents try to update the same field simultaneously, the last write wins. Natera mitigates this with optimistic locking. Each state update includes a version number. If the version has changed since the agent read it, the update fails and the agent retries.
Evaluation Framework
Natera evaluated SWARM before production using three metrics:
| Metric | Definition | Target | Actual |
|---|---|---|---|
| Automated coverage | Percentage of tickets resolved without human intervention | 90% | 96.2% |
| Resolution accuracy | Percentage of automated resolutions judged correct by human reviewers | 95% | 94.8% |
| Time to first response | Median time from ticket creation to first agent response | < 5 min | 2.3 min |
Automated coverage is not the same as correct resolution. A ticket counts as automated if the agent posts a response and closes the ticket. Accuracy is measured separately by sampling closed tickets and having domain experts review them.
The 130x speedup compares the agent’s median response time (2.3 minutes) to the human baseline (5 hours). This is not an apples-to-apples comparison. Humans were handling tickets in batches during business hours. Agents respond immediately, 24/7. The real win is not speed. It’s availability.
Evaluation Data
Natera built a test set of 500 historical tickets with known resolutions. They ran SWARM against this set and compared outputs to the human-generated resolutions. Discrepancies were reviewed by a panel of lab operators.
The evaluation revealed two failure modes:
- Ambiguous requests: Tickets with vague descriptions (e.g., “instrument acting weird”) led to incorrect tool calls
- Edge cases: Rare scenarios not covered in the knowledge base caused the agent to hallucinate procedures
Natera addressed ambiguous requests by adding a clarification step. If the agent’s confidence score is below 0.7, it asks the requester for more details. Edge cases are harder. The system escalates them to humans and logs them for knowledge base updates.
Deployment Shape
SWARM runs on AWS Lambda for the orchestration layer and Amazon ECS for long-running tool integrations. The architecture looks like this:
# Simplified orchestration flow
def handle_ticket(ticket_id):
ticket = fetch_ticket(ticket_id)
# Retrieve relevant context
context = knowledge_base.query(
query=ticket.description,
top_k=5
)
# Generate initial response
response = agent.invoke(
prompt=build_prompt(ticket, context),
tools=get_available_tools()
)
# Execute tool calls
if response.tool_calls:
results = []
for call in response.tool_calls:
result = execute_tool(call)
results.append(result)
# Generate final response with tool results
final_response = agent.invoke(
prompt=build_prompt(ticket, context, results),
tools=[]
)
# Post response or escalate
if final_response.confidence > THRESHOLD:
post_response(ticket_id, final_response.text)
else:
escalate_to_human(ticket_id, final_response.text)Lambda handles the orchestration because most tickets resolve in under 30 seconds. ECS runs tool integrations that need persistent connections to lab systems. The split keeps costs low (Lambda scales to zero) while maintaining reliable connections to legacy systems.
Observability
Natera logs every agent invocation, tool call, and escalation. They use Amazon CloudWatch for metrics and AWS X-Ray for distributed tracing. Key metrics:
- Invocation latency: Time from ticket arrival to first agent response
- Tool call success rate: Percentage of tool calls that complete without errors
- Escalation rate: Percentage of tickets that require human intervention
X-Ray traces show the full execution path: which tools were called, how long each step took, and where failures occurred. This is critical for debugging. When an agent makes a bad decision, engineers can replay the trace and see exactly what context and tool results led to that decision.
Security Boundaries
Healthcare data has strict access controls. Natera implemented three security layers:
- IAM roles: Each agent runs with least-privilege permissions. The inventory agent can read stock levels but cannot modify them.
- Data encryption: All data in transit and at rest is encrypted. The knowledge base uses AWS KMS for key management.
- Audit logs: Every agent action is logged with a timestamp, user context, and justification. These logs are immutable and retained for seven years to meet CLIA requirements.
The knowledge base does not store PHI (protected health information). It contains procedures and decision trees, not patient data. Tool calls that retrieve patient data use temporary credentials with short expiration times.
Failure Modes
The system has three main failure modes:
1. Knowledge Base Staleness
When lab procedures change, the knowledge base lags. Natera mitigates this with a weekly review process. Engineers compare recent escalations to the knowledge base and identify gaps. Updates are tested in a staging environment before production.
2. Tool Integration Failures
Lab systems are not always available. SWARM handles this with retries and fallbacks. If a tool call fails, the agent retries up to three times with exponential backoff. If all retries fail, the ticket escalates to a human with a note about the failed tool call.
3. Hallucinated Procedures
LLMs sometimes generate plausible-sounding but incorrect procedures. Natera addresses this with a validation step. Before executing a procedure, the agent checks it against a whitelist of approved actions. If the procedure is not on the whitelist, the ticket escalates.
Cost and Scale
Natera processes about 10,000 tickets per month. At current volumes, SWARM costs approximately $0.15 per ticket (inference, storage, and compute). The human baseline was $12 per ticket (labor cost). The 80x cost reduction is the real ROI, not the 130x speed claim.
The system scales horizontally. Lambda handles orchestration bursts, and the knowledge base is backed by OpenSearch Serverless, which auto-scales based on query load. Natera has not hit scaling limits yet, but they expect to add rate limiting if ticket volume grows 10x.
Technical Verdict
Use SWARM’s architecture when:
- You have well-documented institutional knowledge that can be encoded as decision trees
- Your domain has clear tool boundaries and APIs for common actions
- You need 24/7 availability and can tolerate a 5% error rate
- You have a feedback loop to capture and review agent mistakes
Avoid this approach when:
- Your procedures change frequently and you cannot maintain the knowledge base
- Your domain requires creative problem-solving that cannot be encoded as rules
- You cannot tolerate any errors (e.g., life-critical decisions)
- You lack the infrastructure to monitor and debug agent behavior
The 96.2% automation rate is impressive, but the 3.8% escalation rate is the real story. Those escalations are not failures. They are the system recognizing its limits. That boundary awareness is what makes this production-ready.