AWS just published the first detailed look at AgentCore, their multi-agent orchestration layer inside Amazon Bedrock. The use case is aerospace component substitution: an engineer needs to evaluate whether part B can replace part A in a certified aircraft system. Traditionally this takes days of manual cross-referencing across PDFs, CAD drawings, spec sheets, and regulatory documents. AWS compressed it to minutes by coordinating specialized agents that gather evidence, validate compliance, and surface recommendations while keeping the human engineer as the final decision-maker.

This is not a demo. The architecture reveals production patterns for state flow between agents, human-in-the-loop approval gates, multimodal evidence retrieval, and failure handling in managed cloud infrastructure.

The Orchestration Problem

Multi-agent systems fail when orchestration becomes a bottleneck. A central coordinator that serializes every agent call creates latency and single points of failure. AWS designed AgentCore to avoid this by treating orchestration as a declarative graph of agent capabilities rather than a procedural script.

Each agent in the substitution workflow has a narrow responsibility:

  • Specification Agent: Retrieves technical specs from multimodal knowledge bases (text + images from PDFs, CAD metadata).
  • Compliance Agent: Checks regulatory constraints (FAA airworthiness directives, OEM bulletins).
  • Compatibility Agent: Evaluates dimensional fit, material properties, and performance envelopes.
  • Risk Agent: Surfaces failure modes, maintenance history, and field service reports.

AgentCore routes context between these agents without forcing them through a single queue. State flows as structured evidence objects, not raw LLM outputs.

State Flow and Context Passing

The key primitive is the evidence bundle. When the Specification Agent retrieves a datasheet, it does not return unstructured text. It returns a typed object with:

  • Source document ID and page reference
  • Extracted parameters (dimensions, tolerances, material codes)
  • Confidence scores for each extraction
  • Multimodal embeddings for cross-modal retrieval

The Compliance Agent receives this bundle and queries its own knowledge base using both text and image embeddings. If the part drawing shows a mounting pattern, the embedding captures spatial geometry that text alone would miss. Amazon Nova Multimodal Embeddings handle this by encoding text and images into a shared vector space, so a query like "mounting hole pattern for bracket assembly" retrieves both written specs and CAD screenshots.

State does not accumulate in a monolithic context window. Each agent maintains its own working memory and publishes findings to a shared evidence store. The orchestrator tracks dependencies (Compatibility Agent waits for Specification Agent results) but does not serialize execution.

Human-in-the-Loop Approval Gates

The Strands Agents SDK exposes a human_approval_required flag that pauses execution and surfaces a decision point. In the aerospace workflow, this triggers after all agents have contributed evidence but before the final substitution recommendation is generated.

The approval gate is not a simple yes/no prompt. It presents:

  • Structured evidence from each agent
  • Confidence intervals for critical parameters
  • Highlighted discrepancies (e.g., material spec mismatch)
  • Regulatory citations that require manual review

The engineer can approve, reject, or request additional evidence. If they request more data, the orchestrator reruns specific agents with refined queries. This is async by design. The workflow persists state to DynamoDB and resumes when the engineer returns, even if that takes hours.

Multimodal Evidence Retrieval

The knowledge base is not a flat vector store. AWS uses Amazon Bedrock Knowledge Bases with multimodal embeddings to index:

  • PDF technical manuals (text + embedded diagrams)
  • CAD drawings exported as images with metadata
  • Maintenance logs (structured tables + free-text notes)
  • Regulatory documents (text + compliance matrices)

When the Compatibility Agent needs to verify a dimensional constraint, it queries with both the part number (text) and a reference image of the mounting interface (image). The retrieval system returns documents where either modality matches, ranked by combined similarity.

This avoids the failure mode where an agent retrieves a spec sheet but misses the critical diagram on the next page. The multimodal embedding treats the diagram as first-class evidence, not an afterthought.

Failure Modes and Recovery

AWS does not hide failure. The orchestrator tracks agent execution status and surfaces errors to the human operator. Common failure modes:

Failure Type Recovery Strategy Impact
Agent timeout Retry with exponential backoff, escalate to human if 3 failures Delays workflow but preserves partial evidence
Retrieval miss Surface "no evidence found" to human, allow manual document upload Prevents false negatives from incomplete knowledge base
Conflicting evidence Flag discrepancy, require human adjudication Stops workflow until resolved
Tool call error Log error, continue with degraded evidence set Partial results still useful for human review

The system does not retry silently. Each failure is logged with context (which agent, which tool, which query) and surfaced in the approval gate UI. The engineer sees what worked and what did not.

Deployment Shape

The architecture runs entirely on managed AWS services:

  • Amazon Bedrock AgentCore: Orchestration layer, agent definitions, tool routing
  • Amazon Bedrock Knowledge Bases: Multimodal vector store with OpenSearch Serverless backend
  • Amazon Nova: Multimodal embeddings and LLM inference
  • AWS Lambda: Custom tool implementations (e.g., CAD file parser)
  • Amazon DynamoDB: Workflow state persistence
  • Amazon S3: Document storage (PDFs, CAD files, images)

There is no Kubernetes cluster, no custom orchestrator, no hand-rolled state machine. The Strands Agents SDK abstracts the plumbing into declarative agent definitions and tool schemas.

Agent Definition Example

The Specification Agent is defined as a JSON schema that Bedrock interprets:

{ "agentName": "SpecificationAgent", "instruction": "Retrieve technical specifications for aerospace components from multimodal knowledge bases. Extract dimensions, materials, and performance parameters.", "tools": [ { "name": "query_knowledge_base", "description": "Search technical documentation using text and image queries", "parameters": { "query_text": "string", "query_image": "optional base64 image", "filter": "optional metadata filter" } }, { "name": "extract_parameters", "description": "Parse structured data from retrieved documents", "parameters": { "document_id": "string", "parameter_names": "array of strings" } } ], "knowledgeBases": [ { "id": "kb-aerospace-specs", "retrievalConfig": { "vectorSearchConfiguration": { "numberOfResults": 10, "overrideSearchType": "HYBRID" } } } ] }

The orchestrator uses this schema to route tool calls and manage retrieval. The agent does not implement retry logic or error handling. That lives in the platform.

Versioning and Rollback

AWS handles agent versioning through Bedrock's built-in version control. Each agent definition has a version number. When you update an agent's instruction or tool schema, Bedrock creates a new version and keeps the old one.

Workflows reference agent versions explicitly. If a workflow is in progress when you deploy a new agent version, it continues using the old version until completion. New workflows pick up the new version.

This prevents mid-flight failures when you change agent logic. The trade-off is that you cannot hot-patch a running workflow. If you discover a bug in an agent, you must wait for in-progress workflows to complete or manually abort them.

Trade-Offs

What you gain:

  • No orchestrator code to write or maintain
  • Built-in state persistence and async execution
  • Multimodal retrieval without custom embedding pipelines
  • Human-in-the-loop primitives that handle async latency
  • Managed scaling and failure recovery

What you give up:

  • Lock-in to AWS Bedrock and its pricing model
  • Limited control over orchestration logic (no custom DAG execution)
  • Opaque retry and timeout behavior (you configure thresholds but do not control the retry loop)
  • Multimodal embeddings are black-box (you cannot inspect or debug the vector space)

Technical Verdict

Use AgentCore when:

  • You need multi-agent coordination on AWS infrastructure without building an orchestrator
  • Your workflow requires human approval gates with async decision latency
  • You have multimodal evidence (PDFs with diagrams, CAD files, images) that agents must retrieve and reason over
  • You want managed state persistence and do not want to run your own database for workflow tracking

Avoid AgentCore when:

  • You need fine-grained control over orchestration logic (custom retry policies, dynamic DAG construction)
  • Your agents run on-prem or in a different cloud (AgentCore is AWS-only)
  • You cannot tolerate vendor lock-in to Bedrock's pricing and API surface
  • Your workflow requires real-time latency (sub-second agent coordination). AgentCore optimizes for correctness and auditability, not speed.

The aerospace substitution use case is a good fit because correctness matters more than speed, human oversight is mandatory, and the evidence is inherently multimodal. If your domain has similar constraints, AgentCore provides production-grade plumbing without custom orchestration code.

Source Links