Amazon Quick - Building a Four-Agent Pipeline That Turns Customer requirements into Delivery Packs
Migration pre-sales means turning customer documents into facts, readiness findings, architecture, and a draft SOW, with every step depending on the one before. This post shows how I built a four-agent pipeline on Amazon Quick.
Anyone who has worked on an AWS migration pre-sales cycle knows the pattern. A customer sends a document, sometimes a clean discovery summary and sometimes a pile of notes. Then comes the real work: pull out the facts, find the gaps, judge migration readiness, sketch an architecture, and turn it all into a draft SOW. Every step depends on the one before it, and any early mistake carries all the way to the end.
I wanted to see how much of that preparation could be accelerated without letting an AI quietly invent things. The result is a delivery accelerator built on Amazon Quick. This post walks through how it works, how the Flow is wired, and the design decisions that mattered most.
Why not one big agent?
My first instinct was a single "do everything" agent. I dropped it quickly, because one agent doing discovery, readiness, architecture, and scoping at once is hard to test and even harder to debug. When the output is wrong, you can't tell which kind of thinking failed.
So I split the work into four specialists, each with a clear job:
- Discovery Advisor: establishes facts, gaps, constraints, risks, and questions
- MAP Assess Advisor: interprets discovery through MAP Assess: readiness, portfolio, candidate 7 Rs, and Mobilize prerequisites
- Architecture Advisor: recommends AWS architecture, justified by evidence
- SOW Advisor: turns the grounded solution into scope, assumptions, dependencies, and exclusions
The flow is linear: Discovery → MAP Assess → Architecture → SOW → Final Delivery Pack → Consultant Review.
Each stage has its own operating manual, its own output contract, and its own test criteria. If something goes wrong, I know where to look.
The rule that holds it together: an evidence hierarchy
The most important design choice wasn't about agents at all. It was deciding what the system is allowed to believe, and in what order:
- Current customer evidence is authoritative for the engagement.
- Validated consultant decisions are approved human corrections.
- Operating manuals and templates hold the stable rules and output formats.
- Historical project knowledge is supporting evidence only: patterns, precedent, and lessons learned.
That last point matters a lot. I loaded past engagements into a searchable knowledge space so the agents can say, "a similar project hit this issue." But historical context never overrides what the current customer actually told us. When an agent uses it, the output has to label it as historical evidence.
Discovery also tags every statement as Confirmed, Historical evidence, Assumption, Requires confirmation, or Preliminary recommendation. Those labels carry through the whole pipeline. Architecture can't quietly promote an assumption to a fact, and the SOW can't quietly treat an open question as settled.
Teaching the agents to say "I don't know"
Most of the effort went into making the agents comfortable with uncertainty. The MAP Assess Advisor is the clearest example. It is explicitly told never to:
- claim an official Migration Readiness Assessment was completed when it wasn't
- invent MAP funding, credits, or eligibility
- fabricate TCO, ROI, migration cost, payback, utilization, or licensing details
- assign a 7 R strategy it can't justify
Instead, if a strategy can't be supported by the evidence, the agent writes "Strategy not yet determinable" and moves on. Missing information stays "Requires confirmation." The SOW Advisor follows the same discipline: pricing, effort, dates, and staffing that nobody supplied are marked "To be confirmed" rather than guessed.
The output can look less impressive at first glance, because it has visible gaps. But I'd rather a consultant see an honest gap on page two than discover an invented number during a customer call.
Why MAP Assess sits before Architecture
I deliberately placed MAP Assess between Discovery and Architecture. Readiness and portfolio reasoning (landing zone maturity, network and identity posture, operations and governance, skills, which workloads might be pilots) should shape the target architecture, not be bolted on after it.
The Architecture Advisor therefore consumes both upstream outputs. Discovery stays the source of customer facts, and MAP Assess supplies readiness and migration-strategy context. For every major recommendation, the agent has to provide:
- the recommendation itself
- the rationale
- the requirement that supports it
- relevant historical evidence, if any
- what needs to be validated
- the trade-offs
It also isn't allowed to silently turn a candidate 7 R into a final decision. That keeps migration strategy choices where they belong, with people who can confirm the facts.
How the pieces are wired together in Amazon Quick
Each advisor is a chat agent in Amazon Quick with:
- a main instruction defining its behavior
- an operating manual uploaded as a reference document (stable rules and templates)
- access to the AWS Modernization Knowledge Hub for historical context
- web search off for the MVP, so I could first prove the value of governed internal knowledge
A Quick Flow chains the agents together. The user provides an opportunity name and uploads a customer document, and the pipeline runs from there.
The flow, step by step
I named the Flow ƒDelivery Accelerator - Document Intake. It takes two inputs, an opportunity name (text) and the customer document (file upload), and passes everything downstream through real
@ references:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Opportunity Name (Text) + Discovery Document (File)
|
v
Discovery Advisor
(facts, gaps, questions, historical evidence)
|
v
MAP Assess Advisor
(readiness, candidate 7 Rs, Mobilize prerequisites)
|
v
Architecture Advisor
(justified AWS recommendations)
|
v
SOW Advisor
(scope, assumptions, dependencies, exclusions)
|
v
Final Delivery Pack
|
v
Consultant ReviewEach step receives only what it needs, and each prompt repeats the guardrails so they hold even when an upstream output is long.
- Discovery Advisor receives
@Opportunity Nameand@Discovery Document. It treats the document as authoritative for the current customer and never invents missing information. - MAP Assess Advisor receives
@Discovery Advisor. It marks missing evidence "Requires confirmation" and doesn't claim an official MRA or MAP funding. - Architecture Advisor receives
@Discovery Advisorand@MAP Assess Advisor. Discovery is the source of customer facts, and candidate 7 Rs are not turned into final decisions. - SOW Advisor receives
@Discovery Advisor,@MAP Assess Advisor, and@Architecture Advisor. It uses MAP gaps to strengthen assumptions and exclusions, and marks commercials "To be confirmed." - Final Delivery Pack receives all four stage outputs. It creates no new facts and preserves unresolved items and citations.
What the prompts actually look like
The first prompt sets the tone for everything downstream:
1
2
3
4
5
6
7
8
9
10
11
12
13
Analyse the current AWS opportunity below.
Opportunity name:
@Opportunity Name
Current opportunity document:
@Discovery Document upload
Treat the referenced document as authoritative information for the
current customer. Produce the complete Discovery Assessment using your
configured Discovery Advisor Operating Manual. Clearly distinguish
Confirmed, Historical evidence, Assumption, Requires confirmation and
Preliminary recommendation. Never invent missing customer information.From there, each hand-off is just a labeled block plus the stage's rules. Here's the MAP Assess step:
1
2
3
4
5
6
7
8
9
10
11
Use the complete Discovery Assessment below as the authoritative
current-opportunity input.
DISCOVERY ASSESSMENT
@Discovery Advisor
Produce the complete MAP Assess Assessment using your configured
operating manual. Do not invent readiness evidence, portfolio data,
costs, TCO/ROI, licensing facts or customer decisions. Do not claim an
official MRA or MAP funding/eligibility. If a 7 R cannot be justified,
state "Strategy not yet determinable."Architecture and SOW follow the same pattern, adding one labeled block per upstream stage (
DISCOVERY ASSESSMENT, MAP ASSESS ASSESSMENT, ARCHITECTURE RECOMMENDATION). The labels make it obvious to the agent, and to anyone debugging the Flow, which input is which.The last step assembles the Final Delivery Pack from all four outputs, in a fixed structure: executive summary, the four stage outputs, outstanding questions, MAP gaps and Mobilize prerequisites, open architecture decisions, assumptions to validate, commercial items to confirm, key risks, next actions, and historical source references. Then it closes with the one line that never changes:
Solution Architect review required.
What cost me the most time
If you build something like this, learn from my mistake: hand-offs in a Flow must use real
@ reference tokens, selected from the picker. Typing "@Discovery Advisor" as plain text looks right but passes nothing downstream.The symptom is confusing. An advisor seems to see context while the Flow runs, but the content isn't there afterward, and it's easy to blame the agent. Before you do that, check the references. Delete any manually typed step names, type
@, and pick the actual previous step. For Architecture, confirm both Discovery and MAP Assess appear as real tokens. For the SOW, confirm all three upstream steps do.I also learned to rely on the Final Delivery Pack as the persistent output, since it consolidates everything in one place.
Testing: pass/fail, not vibes
I tested against a primary scenario first, then used a second as a regression case. The second was a roughly 120-VM VMware estate with Linux, Windows Server 2019, and SQL Server, a six-month migration goal, and selective modernization.
Rather than judging outputs by feel, I defined explicit pass conditions:
- Factual grounding: current-opportunity facts match the source document
- Missing information: unsupported items stay "Requires confirmation" or "Strategy not yet determinable"
- Historical retrieval: past projects are labeled as supporting evidence, never as current facts
- MAP Assess: no invented MRA results, funding, TCO/ROI, or unsupported 7 R decisions
- Hand-offs: each downstream agent actually receives its upstream outputs
- SOW: no invented commercials
- Final pack: contains all four stages and ends with the review requirement
The second test case was especially useful because it checks that the system doesn't treat every workload as a rehost candidate. A mixed estate like that calls for real options and trade-offs, and the missing details (RTO/RPO, dependencies, SQL editions and licensing, landing zone maturity, connectivity, compliance) should stay visibly unresolved.
What I'd tell you if you're building something similar
- Split by kind of thinking, not by convenience. Facts, readiness, architecture, and scoping are different jobs.
- Define an evidence hierarchy before writing prompts. It does more for output quality than any clever wording.
- Make "unknown" a first-class answer. Give agents exact phrases to use when evidence is missing.
- Keep reference examples separate from historical evidence. Otherwise a sample output can be mistaken for a real customer engagement.
- Test with pass/fail criteria. They make regressions obvious.
- Keep a human at the end. The pipeline speeds up preparation, but it doesn't transfer accountability.
That last point is the principle I keep coming back to. This solution accelerates delivery preparation, but professional judgment stays with the consultant. Current customer evidence is authoritative, historical knowledge is supporting context, missing information stays explicit, and anything customer-facing gets reviewed by a person.
What's next
The core pipeline is working, so I'm looking at what to add around it.
The next piece is a Well-Architected Advisor that branches off after Architecture. It would review the proposed design against the six pillars and flag anything worth a closer look. I'd keep its wording cautious, something like "potential risk, needs Well-Architected validation," because an AI reading a document isn't a formal review, and the output shouldn't suggest it is.
I'm also planning more regression testing. Every new scenario shows me where the agents are too confident or too vague, and that feedback has been the fastest way to improve them.
If you're building multi-agent workflows in Amazon Quick, I'd like to hear how you're handling hand-offs between agents and keeping the outputs grounded.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article