Artificial Intelligence #
At Natera, a leader in cell-free DNA (cfDNA) testing, keeping lab instruments up and running is critical, because equipment downtime disrupts sample processing. Natera’s lab engineering team, led by Ariel Jirau worked with AWS to build SWARM (Systematic Workflow Analytics and Resolutions Manager), an agentic AI system for lab operations.
This post walks through how the Natera team built an agentic AI system for lab operations using Amazon Bedrock AgentCore that captures and deploys institutional knowledge at scale. It describes the full architecture, from knowledge base construction to automated system deployment and evaluation, so you can apply the same patterns to your own operational workflows.
SWARM delivers about 130x faster first response time and 96.2 percent automated coverage across support tickets, giving engineers immediate access to institutional knowledge the moment a ticket arrives.
The challenge: Knowledge continuity #
Natera’s lab operations rely on a wide range of precision instruments spanning multiple equipment families, each with its own failure modes, vendor documentation, and resolution patterns. The service engineering team responsible for maintaining this infrastructure is organized around deep individual expertise rather than standardized playbooks. When a senior technician who had spent years diagnosing a particular instrument family departed, the institutional knowledge they carried was effectively lost. No system existed to capture, organize, or deploy that expertise at scale.
With over 65 tickets per day across three Jira queues and an average first response time of 17.4 hours, instrument downtime delayed lab samples and patient reporting. Hiring more engineers couldn’t keep pace. SWARM had to respond in minutes, deliver accurate diagnostics across a wide range of equipment types, and improve continuously through a structured evaluation loop.
Why Natera chose Amazon Bedrock AgentCore #
The Natera team chose to build SWARM on Amazon Bedrock AgentCore, a fully managed, extensible service by AWS designed to build, deploy, connect, secure, and operate AI agents at scale. Three core requirements drove the decision:
- Autonomous processing of high-volume support tickets without human intervention.
- Deep integration with existing operational tools such as Jira and Confluence.
- Built-in security and observability (encryption, AWS Identity and Access Management (IAM) integration, and distributed tracing) without requiring the team to build and maintain custom infrastructure.
“We needed a managed runtime that would let us focus engineering effort on diagnostic accuracy rather than infrastructure plumbing—AgentCore gave us that, along with built-in identity management and the flexibility to swap models without rewriting agent logic,” Jirau said.
AgentCore provides native integration with services including Amazon DynamoDB, a fully managed NoSQL database service, Amazon Simple Queue Service (Amazon SQS), and AWS X-Ray, a capability of Amazon CloudWatch.
How SWARM works: Two agents, one skill library #
SWARM uses two complementary runtimes sharing a single skill library. The swarm-agent autonomously generates structured diagnostic reports before an engineer opens a ticket, while engineers use swarm-hive to interact in real time, upload images, and explore alternative troubleshooting paths.
“The system does not replace engineers—it gives them access to the full depth of institutional knowledge the moment a ticket arrives,” Jirau said.
Four layers connect the architecture:
- The event layer routes Jira tickets through Amazon EventBridge and Amazon SQS.
- The agent layer hosts swarm-agent, swarm-hive, and the skill library, and delivers diagnostic reports back to engineers.
- The context layer draws on vendor manuals, historical tickets, and operational data.
- The observability and delivery layer captures traces, logs, and metrics.
Security architecture #
The Natera team’s first architectural decision was where to run the agents. The team required a managed runtime that would handle container orchestration, scaling, and security without requiring them to maintain custom infrastructure. They chose AgentCore runtime, a capability of Amazon Bedrock AgentCore, because it hosts both swarm-agent and swarm-hive in a secure, managed environment with built-in identity management and monitoring, avoiding the need to build and operate a custom agent execution layer. You can adopt this pattern regardless of the framework you choose.
The team chose a keyless deployment model because SWARM runs in a clinical environment where credentials exposure is unacceptable. OpenID Connect (OIDC) and AWS Security Token Service (AWS STS) generate temporary credentials scoped per deployment, with no long-lived keys in the pipeline. AWS Identity and Access Management (IAM) enforces least privilege at the component level. Amazon Virtual Private Cloud (Amazon VPC) with private subnets and VPC endpoints keeps traffic off the public internet. AWS Secrets Manager rotates the few credentials that exist on an automatic 30-day cycle.
GitLab CI runners authenticate to AWS by presenting an OIDC token to an IAM identity provider configured in the account. AWS STS exchanges the token for short-lived credentials scoped to the deployment role (no long-lived access keys are stored in the pipeline). For setup details, see the IAM OIDC provider documentation.
The following example illustrates the pattern: an IAM OIDC trust policy for GitLab CI follows this structure:
These infrastructure-level security controls work in concert with SWARM’s data governance policies. Together they form the full compliance posture required for operating an AI system in a regulated clinical environment.
Compliance and data governance #
SWARM runs on HIPAA-eligible AWS services under a Business Associate Agreement (BAA), reflecting Natera’s obligations as a clinical laboratory operator. Every agent invocation is audit-logged (a searchable record that satisfies data access traceability requirements). No patient-identifiable information touches the vector index or the language model. Tickets contain only equipment and workflow metadata. Teams building under HIPAA or similar regulatory frameworks should confirm BAA coverage and data separation requirements before designing the knowledge base pipeline.
Knowledge base and document pipeline construction #
Early prototypes using general-purpose retrieval without equipment-specific metadata produced inconsistent results, so the Natera team built a custom document processing pipeline tailored to technical equipment documentation. Amazon Titan Text Embeddings generates vector representations for semantic search, and Amazon Bedrock Knowledge Bases provides fully managed Retrieval Augmented Generation (RAG), converting documents into embeddings stored in batches of 100, a size chosen to balance indexing throughput against API rate limits. For heavily structured source documents with tables and diagrams, investing in a custom parsing pipeline rather than relying on default chunking compounds accuracy gains across every diagnosis.
Amazon Bedrock services, including Amazon Titan Text Embeddings, and Amazon Bedrock AgentCore are available in multiple AWS Regions. For the latest information, see Amazon Bedrock supported Regions and Amazon Bedrock AgentCore supported Regions.
The Natera team uses the tiktoken tokenizer with the cl100k_base encoding to measure chunk boundaries. The following example illustrates the pattern, the chunking configuration follows a standard structure:
For more on batch ingestion patterns, see the Amazon Bedrock Knowledge Bases documentation. “Diagnostic accuracy is a data quality problem first,” Jirau said. “Adding missing vendor manuals for the lowest-scoring instrument family lifted accuracy from 71% to 75% with no model changes.”
This shaped the Natera team’s improvement approach: when accuracy plateaus, the team checks data coverage before model tuning, because gaps in vendor documentation are the most common cause of missed diagnoses. The pipeline reprocesses new or updated documents and refreshes the vector index without disrupting active operations.
Skill library architecture #
The Natera team faced a key architectural choice: embed logic directly in agent prompts, or build a separate, versioned skill library. Natera chose the library approach because it makes SWARM auditable and improvable.
“When a diagnosis is wrong, we need to point to a specific skill rather than debug the whole system — that’s why we built a versioned skill library from the start,” Jirau said.
The library contains 33 skills: 24 instrument-specific skills covering the full range of equipment families Natera supports, plus 9 cross-cutting workflow skills that apply broadly across ticket types. Each skill has a defined interface, is independently testable, and is evaluated against the same standards as the overall system, treated as production software, not embedded prompt logic.
The skill architecture follows a clear split: Python handles deterministic tasks such as parsing Jira fields or formatting HTML reports, while large language model (LLM) skills handle language reasoning such as interpreting symptoms, matching vendor documentation, and generating diagnostic narratives. For teams building a multi-skill agent, this split between deterministic Python skills and LLM-powered reasoning skills is one of the highest-impact decisions to make.
Agent runtime deployment #
Natera split diagnostic work into two distinct runtimes because autonomous background analysis and interactive engineering collaboration have fundamentally different latency and context requirements. The swarm-agent is built for throughput. It selects skills based on equipment type and symptoms, queries the knowledge base, and produces a structured HTML report with a lead cause hypothesis, ranked troubleshooting steps, and a confidence label. The report is delivered to Amazon Simple Storage Service (Amazon S3) and linked to the Jira ticket within minutes. Swarm-hive is designed for depth: engineers can engage in interactive follow-up, upload images, and explore alternative paths, with AgentCore memory, a capability of Amazon Bedrock AgentCore, retaining per-engineer conversational context across sessions.
Because swarm-hive accepts free-form engineer input, prompts are routed through Amazon Bedrock Guardrails for content filtering.
Event-driven Jira integration #
SWARM integrates with Jira through Amazon EventBridge Scheduler and a polling AWS Lambda function, a serverless compute service that runs code in response to events, avoiding webhook configuration. Verified tickets enter an Amazon SQS queue for reliable delivery. DynamoDB handles deduplication using the ticket ID as a partition key with time-to-live (TTL) based expiry, and stores per-run metadata such as status, cost, and token usage to feed the evaluation loop. This EventBridge-to-SQS pattern decouples the agent runtime from the ticketing system’s availability.
The following example illustrates the pattern. The deduplication table uses a minimal schema with TTL-based expiry:
Observability design #
Agentic systems with many interacting components are difficult to debug without per-invocation traces, so the Natera team built observability into SWARM before the first production deployment. If you’re running agents in production, per-invocation tracing is non-negotiable: without it, debugging a bad diagnosis means guessing which skill misbehaved.
In a clinical lab environment, where instrument downtime directly impacts patient reporting, the ability to trace, alert on, and audit every agent action isn’t a “nice to have”. It’s a regulatory and operational requirement.
SWARM’s observability stack uses Amazon CloudWatch to capture searchable logs for every run, providing a clear record of operational health. AWS X-Ray traces each run from ticket intake to diagnostic report, recording time and cost per t