When an aerospace engineer needs to swap out a hard-to-find component for a qualified alternative, the hard part is rarely finding a candidate part. It is building the paper trail: cross-referencing vendor datasheets, interface control documents (ICDs) and qualification records, then writing a justification that a reviewer can check line by line. Miss a detail and a flight-critical substitution can fail. AWS has published a detailed walkthrough of a reference system built with Amazon Nova Multimodal Embeddings and Amazon Bedrock AgentCore that automates the evidence-gathering stage of this process, without letting an AI model make the final call.

What is new

The post describes a multi-agent engineering assistant built on three AWS components: Amazon Bedrock AgentCore (a platform for hosting and orchestrating agents), Amazon Nova Multimodal Embeddings (a model that turns text, images and documents into a shared vector space for search), and the open-source Strands Agents SDK for building the agents themselves. It follows an earlier AWS post that showed Nova Multimodal Embeddings retrieving answers buried in engineering diagrams and charts; this one wraps that retrieval capability inside a working multi-agent pipeline that goes from a question to a drafted assessment document.

The system is built around one rule: the assistant assembles evidence, and the engineer decides. A planner model routes incoming questions to up to three specialist agents, each with its own narrow toolset. A deterministic Python scoring engine, not a language model, produces every pass or fail verdict on whether a candidate part fits in place of a reference part. The system can draft formal review documents, but according to the post it never recommends or approves a substitution itself.

How it works

For readers unfamiliar with the building blocks: an embedding model converts data, whether text, an image or a chart, into a list of numbers (a vector) positioned so that similar things end up near each other in that numerical space. This lets a search system compare a text query against an image, or two images against each other, using a simple distance calculation. An agent, in this context, is a language model wired up with a system prompt and a defined set of tools (functions it can call), so it can take multi-step actions rather than just answer a single question. A multi-agent system splits work across several such agents, often coordinated by a separate planner or router.

In the AWS architecture, a planner built on Claude Haiku 5.5 reads an incoming query and produces a routing plan in a few seconds, since classifying a query does not need a large reasoning model. The plan sends work to one or more of three specialists, all running on Claude Sonnet 5.5: a Catalog specialist that searches the parts knowledge base and filters by specification; an Evaluation specialist that runs deterministic spec comparisons and visual similarity checks; and a Knowledge specialist that answers questions from datasheets and ICDs, checks live end-of-life status on the web, and retrieves charts or diagrams. When more than one specialist contributes to an answer, a supervisor model (Claude Opus 5.5) synthesizes their outputs; if only one specialist ran, the system skips that synthesis step entirely, which the post says saves about eight seconds of latency with no gain in quality.

Nova Multimodal Embeddings does two jobs in the pipeline. First, it embeds datasheets, ICDs and performance charts into one shared vector space alongside plain text, so an engineer can type a query like "torque curve for the 0.06 Nms wheel" or upload a chart image and get back the matching diagram with its source. Second, when comparing two candidate parts, it produces a cosine similarity score between their product photos; in the example corpus, two wheels from the same product family scored around 0.84 similarity, while wheels from different classes scored around 0.40. Claude then explains what is driving the visual difference, for instance noting a mounting pattern or housing size mismatch. That visual score supports, but does not replace, the deterministic spec comparison that decides the actual fit verdict.

The deterministic scoring itself runs as ordinary Python code against a hand-written schema of critical specifications and tolerance rules per part category, such as requiring an exact voltage match or allowing mass to be within 20 percent of the reference part. Because the same inputs always produce the same result, the output can go into a formal review package. Every evaluation also writes an audit trail entry aligned with AS9100 aerospace quality standard sections 8.4 and 8.5.6.

For formal documents, the system uses a fixed sequence rather than dynamic routing. When an engineer requests an Integration Impact Assessment comparing a reference and candidate part, the Knowledge specialist runs first, then Evaluation, then the supervisor synthesizes a six-section document covering interface, mechanical, electrical, thermal, qualification and supply chain impact. The narrative text comes from the language models, but the summary statistics are computed directly from the deterministic comparison code, so the numbers in the document are exact.

Why it matters

For practitioners, the interesting part is not any single model but the division of labor. The post deliberately routes different tasks to different model sizes and to code where possible: a small model handles classification, a mid-size model runs tools, a large model only writes final synthesis when multiple specialists' outputs need combining, and anything that must be reproducible for a safety review is plain code rather than a language model call. This is a practical pattern for any agentic system where cost, latency and auditability all matter.

The post also reports quality figures from AWS's own evaluation tooling, AgentCore Evaluations, which scores agent behavior using LLM-as-judge techniques against the OpenTelemetry traces the agents already emit. Using a curated set of 36 test queries across six categories, a snapshot run reported a Goal Success Rate of 0.892, Correctness of 0.968, Helpfulness of 0.956, Faithfulness of 0.981, Response Relevance of 0.968, Tool Selection Accuracy of 0.861 and Tool Parameter Accuracy of 0.980.

  • Architecture: planner (Claude Haiku 5.5) routes to Catalog, Evaluation and Knowledge specialists (Claude Sonnet 5.5); supervisor (Claude Opus 5.5) synthesizes multi-specialist answers
  • Nova Multimodal Embeddings handles both multimodal document retrieval and photo-to-photo visual similarity scoring (1,024-dimensional vectors)
  • Spec-fit verdicts come from deterministic Python code against a tolerance-rule schema, not from a language model
  • Image-as-query (uploading a chart or photo) uses a native Amazon S3 Vectors index directly, since the managed knowledge base API does not accept image input
  • Cropping datasheet charts before indexing raised chart-matching accuracy from 3 of 7 parts correct to 7 of 7 in AWS's testing
  • Tool Selection Accuracy rose from 0.809 to 0.861 after consolidating knowledge bases and fixing a silent permissions fallback
  • Nova Multimodal Embeddings is available in AWS GovCloud (US), relevant for ITAR and FedRAMP-regulated workloads

Limits and open questions

Several caveats are worth noting. The reported evaluation numbers come from a synthetic dataset of seven fictional reaction wheels, not from a live aerospace deployment, and AWS explicitly frames them as a baseline rather than a guarantee, noting that scores will shift with real traffic. The lower Goal Success Rate of 0.892 is partly an artifact of the test design: the query set includes prompts that deliberately ask the agent to approve a substitution, and when the agent correctly refuses, the evaluator still scores that as an unmet goal, since it measures whether the stated goal was achieved rather than whether refusal was the right outcome.

The post also flags an operational risk worth remembering for anyone building similar systems: the image-as-query retrieval path silently falls back to text search on certain permission errors, meaning a missing access right would not raise a visible error but would instead cause the model to misidentify parts with apparent confidence. AWS says it added explicit logging for this fallback after encountering the problem during development. More broadly, the human-in-the-loop safety rule (requiring a prior evaluation before documents are drafted, and logging every substitution decision) is currently enforced through the application's own logic rather than through a dedicated authorization engine, something the post describes as a planned next step rather than a finished safeguard.

How to try it

AWS has published the full sample code as five Jupyter notebooks in a GitHub repository, each runnable independently with its own sample parts data. Trying it requires an AWS account with Bedrock access in the US East (N. Virginia) Region, model access to Nova Multimodal Embeddings and the three Claude model tiers used, a managed knowledge base built over a parts corpus, an S3 Vectors index for part photos and chart crops, and an AgentCore Gateway configured with a web search connector. The post notes that adapting the pattern to a different part category only requires replacing the parts data, editing the tolerance-rule schema for the new category's critical specifications, and pointing the knowledge base at the new corpus; the agents and scoring code carry over unchanged. For production deployment, the agent is packaged as an ARM64 container and hosted on AgentCore runtime, with a reference Dockerfile provided in one of the notebooks.

Sources