Natera, a company specializing in cell-free DNA (cfDNA) testing, relies on the continuous availability of its laboratory instruments because equipment outages interrupt sample processing. The company's lab engineering team, led by Ariel Jirau, partnered with AWS to create SWARM (Systematic Workflow Analytics and Resolutions Manager), an agentic AI system for laboratory operations built on Amazon Bedrock AgentCore. The system produces a first response roughly 130x faster than before and reaches 96.2 percent automated coverage across support tickets, putting institutional knowledge in engineers' hands the moment a ticket arrives. This account covers the full architecture, from building the knowledge base through automated deployment and evaluation.
The knowledge continuity problem
Natera's lab operations depend on a wide range of precision instruments spread across multiple equipment families, each with its own failure modes, vendor documentation, and resolution patterns. The service engineering team maintaining this infrastructure was organized around deep individual expertise rather than standardized playbooks. When a senior technician who had spent years diagnosing a particular instrument family departed, the knowledge they carried was effectively lost, and no system existed to capture, organize, or deploy that expertise at scale.
The operation handles more than 65 tickets per day across three Jira queues, with an average first response time of 17.4 hours, and instrument downtime delayed lab samples and patient reporting. Hiring additional engineers could not keep pace. SWARM needed to respond within minutes, produce accurate diagnostics across a wide variety of equipment types, and keep improving through a structured evaluation loop.
Why Amazon Bedrock AgentCore
The team chose to build SWARM on Amazon Bedrock AgentCore, a fully managed, extensible AWS service 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 the team having 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 Amazon DynamoDB, a fully managed NoSQL database service, Amazon Simple Queue Service (Amazon SQS), and AWS X-Ray, a capability of Amazon CloudWatch.
Two agents, one shared skill library
SWARM pairs two complementary runtimes that share a single skill library. The swarm-agent component 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
Deciding where the agents would run was the team's first architectural choice. They needed a managed runtime able to handle container orchestration, scaling, and security without custom infrastructure to maintain, and selected AgentCore runtime, a capability of Amazon Bedrock AgentCore. It hosts both swarm-agent and swarm-hive in a secure, managed environment with built-in identity management and monitoring, removing the need to build and operate a custom agent execution layer. The pattern can be adopted regardless of the framework chosen.
Because SWARM operates in a clinical environment where credential exposure is unacceptable, the team adopted a keyless deployment model. OpenID Connect (OIDC) and AWS Security Token Service (AWS STS) generate temporary credentials scoped per deployment, with no long-lived keys in the pipeline. 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, while AWS Secrets Manager automatically rotates the few credentials that exist on a 30-day cycle.
GitLab CI runners authenticate to AWS by presenting an OIDC token to an IAM identity provider configured in the account, and AWS STS exchanges the token for short-lived credentials scoped to the deployment role, so no long-lived access keys are stored in the pipeline. The 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 controls work together with SWARM's data governance policies, forming the full compliance posture required to operate 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, creating a searchable record that satisfies data access traceability requirements. No patient-identifiable information reaches 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
Early prototypes using general-purpose retrieval without equipment-specific metadata produced inconsistent results, so the 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). Documents are converted into embeddings in batches of 100, a size chosen to balance indexing throughput against API rate limits. For heavily structured source documents containing tables and diagrams, the team found that 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.
The team uses the tiktoken tokenizer with the cl100k_base encoding to measure chunk boundaries:
# 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
"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 team's improvement approach: when accuracy plateaus, they check 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 team faced a key architectural choice between embedding logic directly in agent prompts and building a separate, versioned skill library, and 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. 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 containing 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 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 team built observability into SWARM before the first production deployment. In a clinical lab environment, where instrument downtime directly impacts patient reporting, the ability to trace, alert on, and audit every agent action is a regulatory and operational requirement rather than an optional feature.
The observability stack uses Amazon CloudWatch to capture searchable logs for every run. 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. 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 a knowledge base update — 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. The Low confidence sample size of 37 cases is too small to draw statistically meaningful conclusions, and the team expects the two tiers to diverge as the evaluation dataset expands. The separation between High and the remaining tiers still gives engineers a useful signal for how much weight to place on each diagnosis when reading a diagnostic report.
Performance
The team evaluated SWARM across 524 support tickets to establish a baseline. Of those, 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, measured 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, 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 the source documents are structured.
- Build traceability into the skill library from the start, so a wrong diagnosis can be traced to a specific skill rather than requiring a debug of the whole system.
- If a workload mixes batch processing with interactive querying, separate them into distinct runtimes.
Getting started
The team points builders to the AgentCore samples repository, Building Agentic Systems on AWS, and the Getting Started with Amazon Bedrock AgentCore guide for deploying agents securely at scale. Healthcare and life sciences organizations facing institutional knowledge loss, high-volume operational workflows, or clinical compliance requirements will find that SWARM's architectural patterns provide a replicable, production-tested foundation for building agentic AI systems on AWS.