How Natera designed an agentic AI system for lab ops with Amazon Bedrock AgentCore

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. Figure 1: Architecture of Natera’s SWARM on Amazon Bedrock AgentCore 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: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/gitlab.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "gitlab.com:sub": "project_path:YOUR_PROJECT:ref_type:branch:ref:main" } } } ] } 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: # Document chunking configuration chunk_si