Article · Original
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_size = 1000 # tokens chunk_overlap = 150 # tokens encoding = tiktoken.get_encoding("cl100k_base") batch_size = 100 # documents per embedding API call 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: dynamodb.create_table( TableName='swarm-deduplication', KeySchema=[ {'AttributeName': 'ticket_id', 'KeyType': 'HASH'} ], AttributeDefinitions=[ {'AttributeName': 'ticket_id', 'AttributeType': 'S'} ], TimeToLiveSpecification={ 'Enabled': True, 'AttributeName': 'ttl' } ) 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 tool call so the team can pinpoint the specific skill responsible when something is slow or expensive rather than guessing. Amazon Simple Notification Service delivers failure alerts by email, while a Slack tracker gives the entire team real-time visibility into agent activity. Continuous evaluation methodology SWARM uses a continuous evaluation loop rather than testing once at deployment, which is especially critical for systems handling changing documentation or evolving workflows. On every ticket processed, the agent provides a lead cause hypothesis, ranked troubleshooting steps, and a self-rated confidence label. Engineers record what they found and fixed, and an evaluator grades each response as Accurate, Partial, or Wrong, broken down by instrument family. Results are reviewed to identify where the agent is underperforming, the fix is applied (typically by updating the knowledge base), and the evaluation set is re-run to confirm improvement. SWARM’s self-rated confidence labels show a directional relationship with actual accuracy. Tickets labeled High confidence achieve 74 percent accuracy across 154 evaluated cases, while Moderate and Low confidence tickets both achieve 65 percent across 78 and 37 cases respectively. Note that Moderate and Low currently share the same accuracy rate. The Low confidence sample size of 37 cases is too small to draw statistically meaningful conclusions, and the Natera team expects the two tiers to diverge as the evaluation dataset expands. The separation between High and the remaining tiers gives engineers a useful signal for how much weight to place on each diagnosis at the point of reading a diagnostic report. SWARM performance The Natera team evaluated SWARM across 524 support tickets to establish a performance baseline. Of the 524 tickets in the evaluation set, 269 received a High, Moderate, or Low confidence label and had a corresponding engineer-verified resolution available for comparison. The remaining tickets were either labeled none or lacked a verified resolution at the time of analysis. Average first response time dropped from 17.4 hours to roughly 8 minutes (about 130x faster). These measurements were collected from Jira ticket metadata over a 90-day production evaluation period. Coverage matters just as much: 96.2 percent of tickets get an automated first response without an engineer having to initiate the diagnostic process. Coverage was measured as the percentage of incoming tickets that received a SWARM-generated diagnostic report before engineer review. Lessons from building agentic AI in production Several architectural decisions in SWARM translate directly to teams building similar systems. Treat chunk size and overlap as tunable parameters. The right values depend on how your source documents are structured. Build traceability into your skill library from the start. When a diagnosis is wrong, you want to point to a specific skill, not debug the whole system. If your workload mixes batch processing with interactive querying, separate them into distinct runtimes. Getting started Try these patterns yourself with the AgentCore samples repository, Building Agentic systems on AWS or the Getting Started with Amazon Bedrock AgentCore guide for deploying agents securely at scale. Healthcare and life sciences organizations facing similar challenges with institutional knowledge loss, high-volume operational workflows, or clinical compliance requirements will find that the architectural patterns Natera developed with SWARM provide a replicable, production-tested foundation for building agentic AI systems on AWS. About the authors Ariel Jirau Ariel is a Principal Software Engineer at Natera. He leads technical implementation and infrastructure decisions for enterprise readiness, overseeing the system architecture and production deployment of SWARM. Veronica Rule Veronica is a Senior Customer Solutions Manager at AWS with over 10 years of experience supporting healthcare and life science customers on their cloud journey. She specializes in guiding organizations through AI/ML adoption, agentic AI strategies, and cloud transformation initiatives. She is passionate about bridging the gap between advanced AI capabilities and real-world health care and life sciences outcomes. Tamara Gagliardi Tamara is a Senior Solutions Architect at AWS with over 15 years of experience in the technology field, spanning across industries including financial services, retail and manufacturing. For the past several years, she has focused her expertise on the healthcare and life sciences sector, partnering closely with medical devices and bio-diagnostic customers to accelerate their cloud journeys. As a trusted technical advisor, Tamara helps organizations translate complex business challenges into scalable, secure technical solutions with a particular emphasis on generative AI, where she guides customers in identifying high-impact use cases and architecting intelligent workflows.