Building Intelligent AWS Architectures with Amazon Nova: A Multi-Agent Approach

Cloud architecture is one of the most consequential technical decisions a team makes. Get it right and you have a scalable, cost-efficient foundation. Get it wrong and you are refactoring infrastructure while simultaneously trying to ship a product.

The problem is that good architectural decisions require experience that most teams simply do not have. Junior engineers default to familiar patterns. Founders without technical backgrounds rely on whoever is in the room. Early-stage startups cannot afford a dedicated cloud architect. The result is a consistent pattern: teams spend weeks researching AWS services, produce an architecture that works at launch, and discover its limitations only after it becomes expensive to change.

We built the Multi-Agent Architecture Builder to change that. Describe your project in plain language, or simply speak it aloud, and the system researches AWS best practices, designs a production-grade architecture, generates diagrams, and produces a cost estimate. The whole process takes two to five minutes.

This is not a tool for expert architects to go slightly faster. It is a tool for everyone who has been locked out of expert-quality architecture design entirely.

Startup founders who need to validate an architecture for investor conversations, without the time or budget to hire a consultant.

Small engineering teams building their first cloud-native product, who need guidance on which services to use and why.

Junior engineers learning AWS, who benefit from seeing a complete, reasoned architecture for a realistic project alongside a clear explanation of each service choice.

Cloud consultants who want to automate the initial design phase and redirect their time toward optimisation and edge cases, where their expertise genuinely creates value.

Enterprise teams who need consistent architectural patterns across multiple projects without starting each one from scratch.

The common thread: people who know what they want to build, but need expert-quality guidance on how to build it on AWS.

Rather than asking a single LLM to design everything in one pass, which produces plausible-looking but unreliable output, we decompose cloud architecture design into 8 specialised agents, each responsible for exactly one task.

The benefit of this structure is that each agent has a narrow, well-defined success criterion. A single LLM asked to "design a production architecture" has no natural stopping point and no clear measure of correctness. An agent asked to "generate four research questions about this project description" either produces four questions or it does not. That specificity is what makes the outputs reliable.

One of the most important decisions in this system is which Nova model handles each task. We use all three tiers deliberately.

nova-micro-v1 handles routing and classification. Is the task simple? Is this a new architecture request? A small change? Or a large redesign? And nova-micro is fast, cheap, and accurate for categorical decisions. Using nova-pro for this would be like hiring a senior engineer to sort emails.

nova-2-lite-v1 handles research question generation and structured output validation. It reasons about technical constraints quickly and evaluates whether outputs meet quality thresholds. Fast enough to keep the research loop responsive; capable enough to catch errors before they propagate.

nova-pro-v1 is reserved for the work that demands its full capability: architecture design, technical analysis, and cost estimation. These are the outputs that directly shape the final deliverable. This is where the compute budget is worth spending.

This tiered approach reduces costs by approximately 60% compared to using nova-pro across all nodes, while maintaining output quality in the places that actually matter.

Every LLM output is validated against a Pydantic schema before it passes to the next agent. If the output is malformed or missing required fields, the system retries automatically.

The Research Analyst, Solution Architect, and Cost Estimator nodes use Nova Lite-powered reviewers as an additional critic layer, enforcing structured output format and coherence before anything moves downstream. This catches hallucinations that pass schema validation but fail semantic review.

Result: Consistent, reliable outputs. Nothing hallucinated reaches the user.

Rather than running a fixed number of research iterations, the Guardian node makes threshold-based decisions:

The system does exactly as much research as each specific project needs. A simple single-service architecture completes in one iteration. A complex multi-region design runs the full three. No manual tuning needed.

When a user requests a modification after the initial design, the Router classifies its scope and routes accordingly.

Minor changes ("add CloudWatch monitoring") route directly to the Blueprint Generator - no research loop, no redesign. Medium changes ("add WebSocket support") route to the Solution Architect. Major changes ("redesign for multi-region failover") route all the way back to the Cloud Architect, triggering a fresh research loop.

This means the system spends compute where it needs to and skips what it does not.

Before the Cost Estimator runs, the system pauses for user review and approval. Users can examine the proposed architecture, request adjustments, or reject and restart. Cost projections only run on designs the user has explicitly approved.

Most multi-agent architecture tools require structured input, filling out forms, selecting services from dropdowns, specifying scaling parameters. We wanted to remove that barrier entirely.

With Amazon Nova Sonic, users describe their requirements in natural speech. Nova Sonic handles real-time transcription and natural language understanding, feeding directly into the LangGraph pipeline.

For non-technical founders and junior engineers especially, this changes the interaction model entirely. You do not need to know the right vocabulary to describe what you want to build. You just describe it.

Input: "Build a real-time e-commerce platform supporting 10 million daily active users, with real-time inventory updates, personalised recommendations, and global reach."

Research questions generated:

Architecture output:

Cost projection:

Two to five minutes. Production-grade output. No architect required.

We want to share what genuinely surprised us, not a list of conclusions, but the specific moments where our assumptions were wrong and our thinking had to change.

Scope matters more than capability. Our first instinct was that output quality was a model capability problem, use a bigger model and get better results. What we discovered was that output quality was actually a scope problem. A nova-pro agent asked to "design a complete AWS architecture" produces inconsistent results because the task is underspecified. The same agent asked to "given these 12 technical findings, design a solution architecture for a real-time e-commerce platform and populate these 8 specific fields" produces consistent, reliable output. The constraint is the feature, not a limitation. This was the core insight behind the whole multi-agent design.

Guardian patterns beat hard limits. We initially used a fixed iteration count for the research loop. The problem was that some projects needed one iteration and others needed three, and the fixed limit produced either over-researched simple architectures or under-researched complex ones. Switching to threshold-based termination, stop when we have enough services, enough findings, enough search results, meant the system adapts to the actual research quality rather than just counting steps. The Guardian is now one of the most valuable nodes in the graph.

The critic layer catches what schemas miss. Pydantic validation is excellent at catching structural errors; missing fields, wrong types, malformed data. It does not catch semantic errors; an architecture that passes schema validation but specifies Aurora for a use case that clearly needs DynamoDB, or a cost estimate where the line items do not add up to the stated total. Adding Nova Lite as a semantic reviewer on top of Pydantic validation was the difference between "technically valid" and "actually correct." These are not the same thing.

LLM tiering changes the economics of the whole system. When we profiled our early builds, roughly 40% of LLM costs were being spent on routing and research question generation, tasks that required fast, lightweight responses, not deep reasoning. Replacing nova-pro with nova-micro for routing and nova-2-lite for question generation cut total LLM costs by around 60% with no measurable impact on output quality. The lesson is not just "use cheaper models where possible"; it is that thinking carefully about what each task actually requires is a first-class engineering decision, not an optimisation you do later.

Voice changes who can use it. This one was harder to quantify but impossible to ignore. When we tested the system with non-technical users, founders, product managers, people who would never voluntarily open a CloudFormation template, the text interface created a consistent friction point. Users were uncertain about what vocabulary to use, what level of detail to provide, how to phrase requirements "correctly." Voice eliminated all of that. Users just described their product, the way they would describe it to a colleague. The adoption curve flattened immediately. If you are building tools for people who are not AWS experts, voice input is not a feature; it is an access decision.

The skills gap in cloud architecture is real and widening. AWS offers over 200 services. Architectural best practices evolve constantly. The teams who have a dedicated cloud architect get better infrastructure. The teams who do not make do. That gap compounds over time; the cost of architectural debt grows with the product.

This tool is our attempt to address that gap directly. Not by replacing architects, experienced architects will always add value that a system like this cannot, but by raising the floor for everyone else.

For the developer community: The project is open-source. We want other builders to extend it, contribute new agents, and adapt it for specialised domains, healthcare compliance requirements, government cloud configurations, industry-specific cost optimisation.

For education: We are exploring integration with AWS training programs. The system explains every service choice it makes. For a junior engineer, that is not just an architecture; it is a learning resource.

For the hackathon community: The patterns here, LLM tiering, guardian-based loops, critic validation, smart routing, are applicable to any multi-agent system, not just architecture design. We intend to write up these patterns separately and contribute them back to the LangGraph community.

The goal after the hackathon is to keep this running, gather real-world feedback, and continue improving the architecture output quality. If you use it and find gaps, we want to know.

Cloud architecture design has been gatekept behind expensive expertise for too long. The tools that exist today either require that expertise to use, or produce output too unreliable to trust.

The combination of Amazon Nova's multi-tier model family, Nova Sonic's voice understanding, and LangGraph's multi-agent orchestration makes it possible to build something that is genuinely different: accurate, fast, and accessible to anyone who can describe what they want to build.

That is the goal. Not a faster tool for experts - a capable tool for everyone.