Natera Builds SWARM Agentic AI for Clinical Lab Operations on Bedrock AgentCore

Summary:Natera and AWS have deployed SWARM, an agentic AI system for clinical laboratory operations, on Amazon Bedrock AgentCore. Its architecture separates two execution modes: swarm-agent performs autonomous, high-throughput diagnosis for incoming Jira tickets, while swarm-hive supports engineers with interactive troubleshooting, image uploads, and persistent conversation context. The system combines a versioned library of 33 deterministic and LLM-powered skills, an equipment-aware RAG pipeline, even

---

Natera has deployed SWARM (Systematic Workflow Analytics and Resolutions Manager), an agentic AI system for laboratory operations, on Amazon Bedrock AgentCore. Rather than delegating instrument troubleshooting entirely to a model, SWARM combines 33 testable skills, equipment-specific RAG, human interaction, and per-invocation auditing in a dual-runtime architecture. During a 90-day production evaluation, it reduced average first-response time from 17.4 hours to roughly eight minutes, while 96.2% of tickets received an automated first response.

Two Runtimes for Throughput and Interaction

SWARM divides the same operational workload into two execution paths:

• swarm-agent handles background processing. It selects skills according to equipment type and symptoms, queries the knowledge base, and produces an HTML report containing a leading-cause hypothesis, ranked troubleshooting steps, and a confidence label. The report is written to S3 and linked to the Jira ticket.
• swarm-hive supports real-time collaboration with engineers. It accepts free-form input and images, explores alternative troubleshooting paths, and uses AgentCore Memory to retain per-engineer context across sessions.

This separation reflects two different workload profiles. The automated path needs high concurrency, low unit cost, and predictable structured output. The interactive path needs longer context, tool feedback, and human takeover. Combining both usually forces batch jobs to carry interactive state overhead or forces human sessions into rigid templates.

The tradeoff is maintenance: both runtimes share skill interfaces, permissions, and evaluation sets. In return, failures are easier to isolate and each workload can scale according to its own constraints.

Four-Layer Architecture and Event-Driven Integration

The architecture has four layers:

1. Event layer: Jira tickets enter SQS through EventBridge Scheduler and a polling Lambda function.
2. Agent layer: Runs swarm-agent, swarm-hive, and the shared skill library.
3. Context layer: Retrieves vendor manuals, historical tickets, and operational data.
4. Observability and delivery layer: Captures logs, traces, and metrics and writes diagnostic reports back to tickets.

Jira is not directly coupled to agent execution. EventBridge, SQS, and Lambda handle ingestion; DynamoDB deduplicates by ticket ID and stores status, cost, token usage, and other run metadata, with TTL-based expiry. This keeps ticket-system downtime from interrupting queued work. It also introduces complexity around duplicate delivery, state transitions, and dead-letter handling, none of which is quantified in the original article.

A Versioned Skill Library Constrains Model Behavior

Instead of embedding all troubleshooting logic in prompts, Natera created a library of 33 independently testable skills: 24 for specific instrument families and nine for cross-cutting workflows. Each skill exposes a defined interface and participates in the same regression criteria as the overall system.

Within each skill, deterministic work is separated from language reasoning:

• Python parses Jira fields, formats HTML, and performs structured transformations.
• The LLM interprets symptoms, matches documentation, proposes diagnostic hypotheses, and generates explanations.

This does not make code inherently superior to models. It places verifiable transformations in deterministic code and reserves semantic generalization for the model. Versioning also narrows error attribution: a bad answer can be traced to a specific skill instead of requiring the entire prompt to be rewritten. The cost is ongoing interface management, dependency tracking, and combinatorial testing.

Equipment-Aware RAG: Chunking Is Only the Starting Point

SWARM uses Amazon Titan Text Embeddings and Bedrock Knowledge Bases for retrieval. The sample configuration uses 1,000-token chunks, 150-token overlap, and batches of 100 documents for embedding calls to balance indexing throughput against API rate limits. Natera also uses the cl100k_base tokenizer to measure boundaries.

Diagnostic quality, however, depends more on document parsing than on default chunk sizes. Generic retrieval prototypes performed inconsistently because equipment identity and fault context were not preserved, so the team built a custom parser for manuals containing tables and diagrams. Missing documentation was also a direct bottleneck: adding the manuals for the weakest instrument family lifted accuracy from 71% to 75% without any model change.

RAG performance is therefore bounded first by corpus coverage and structural fidelity, not by model size or additional retrieval turns. The tradeoff is the long-term maintenance of parsers, ingestion pipelines, and device-specific regression tests. The published batch size and accuracy improvement should not be treated as universal optimal settings.

Security and Compliance Boundaries

Clinical deployment cannot depend on long-lived static credentials. SWARM uses GitLab CI OIDC and AWS STS to obtain short-lived credentials scoped to deployment roles. IAM enforces least privilege, VPC private subnets and VPC endpoints keep traffic off the public internet, and Secrets Manager rotates the few remaining credentials every 30 days.

The system runs on HIPAA-eligible AWS services, and every agent invocation is audit logged. According to the article, patient-identifiable information does not reach the vector index or language model; tickets contain only equipment and workflow metadata. This is more precise than a generic claim of anonymization, but production teams still need to verify that metadata cannot indirectly re-identify patients and that every model-service path is covered by the applicable Business Associate Agreement.

Observability and Continuous Evaluation

CloudWatch stores searchable logs for every run, while X-Ray traces the path from ticket intake to diagnostic report and records the time and cost of each tool call. SNS and Slack provide failure notifications. Without invocation-level tracing, diagnosing an incorrect result becomes guesswork; tracing is therefore both a clinical audit requirement and a cost-control mechanism.

The evaluation loop uses engineer-confirmed findings as labels. Each answer is graded Accurate, Partial, or Wrong and aggregated by instrument family. Among 269 tickets with engineer-verified outcomes:

• High Confidence: 154 cases and 74% accuracy;
• Moderate Confidence: 78 cases and 65% accuracy;
• Low Confidence: 37 cases and 65% accuracy.

High confidence provides a limited risk-ranking signal. However, the Low Confidence group contains only 37 cases, so the data cannot establish whether Moderate and Low should remain merged or diverge later. Self-reported confidence is also not a calibrated probability and should not be interpreted as a per-ticket guarantee.

How to Interpret the Metrics

The evaluation set contains 524 tickets, but only 269 had both a confidence label and a verifiable resolution; the rest had no confidence label or lacked a verified outcome at the time of analysis. The 96.2% figure measures whether SWARM generated a report before engineer review—not whether the diagnosis was correct.

The reduction in first-response time from 17.4 hours to approximately eight minutes, or about 130 times faster, primarily makes hidden expert knowledge available earlier to on-call engineers. It reduces waiting and repeated information gathering, but it does not mean the workflow is fully unattended. Reports still require validation, and high-risk equipment decisions should not be executed automatically.

Deployment Recommendations

For industrial maintenance, medical-laboratory, and field-service teams, the case provides four reusable engineering principles:

• Fix knowledge coverage before tuning models. Identifying missing documentation for each equipment family can outperform changing the model.
• Move deterministic work out of prompts. Use code for parsing, formatting, and validation; reserve models for semantic reasoning.
• Separate batch and interactive runtimes. Do not force one context model to serve fundamentally different latency and concurrency requirements.
• Build tracing and evaluation from day one. Record knowledge sources, skill selection, tokens, cost, and final engineer fixes to establish a credible regression loop.

Production deployments should additionally test queue backlogs, duplicate delivery, failure recovery, per-call cost, and concurrency isolation. Accuracy should be reported by equipment family with confidence intervals. Only by placing response speed, coverage, diagnostic accuracy, and human-escalation rate on the same operational dashboard can teams determine whether the agent improves equipment uptime rather than merely assigning problems to engineers sooner.

---

Source: AWS Machine Learning Blog (2026-11-12)

— END —

Tags: #Natera SWARM Follow #Amazon Bedrock AgentCore Follow #Agentic Operations Follow #RAG Follow #Clinical Laboratories Follow