AWS Quick Launches Six-Agent AI-PDLC for Evidence-Grounded Product Development

Summary:AWS has published and demonstrated a six-agent AI-driven product development lifecycle in Amazon Quick. An Orchestrator coordinates Discovery, Prioritization, Working Backwards, specification generation, design, and prototype generation, converting fragmented enterprise evidence from Slack, Salesforce, Jira, SharePoint, ServiceNow, and related systems into traceable pain-point boards, prioritization matrices, PR/FAQ documents, build specifications, and clickable prototypes. Human approval gates

---

Six Agents for the Upstream Product-Development Chain

AWS has provided a configurable reference implementation of an AI-driven product development lifecycle in Amazon Quick. It consists of an Orchestrator and five specialized agents: Discovery collects customer evidence, Prioritize evaluates candidate use cases, Working Backwards challenges proposals through a PR/FAQ, Spec Generator produces the engineering specification, and Designer creates journey maps, wireframes, and clickable HTML prototypes.

The six agents cover the Discover, Decide, Design, and Prototype phases. Engineer, Ship, Operate, and Learn are handed to coding agents such as Kiro. AWS has published the agent instructions, question frameworks, configuration files, and reference architecture in a GitHub repository so teams can begin from a working structure rather than construct an entire prompt stack from scratch.

Orchestration: Loading Expert Contracts at Runtime

The Orchestrator acts as the control plane. At runtime, it reads each specialist's instructions, selects the question framework appropriate to the current phase, asks structured questions, and dispatches artifact-generation work to the relevant agent. The pipeline advances only after the current human gate is approved.

This differs from simply chaining six agents sequentially. Control logic is separated from domain rules: specialists produce artifacts, while the Orchestrator advances state and checks consistency. Each specialist records its decisions, scores, and rationale in the artifact it creates. The Orchestrator independently verifies that those fields exist and maintains a shared log across phases. Under normal operation, this produces two layers of auditability; if one layer is incomplete, the other may still preserve some of the evidence.

The system supports two pacing modes. Deep Discovery asks approximately eight to twelve questions per phase and is intended for new problem spaces and edge-case exploration. Fast Track asks three to five essential questions and proposes defaults from existing context, making it suitable for time-boxed workshops. The former increases coverage; the latter reduces interaction overhead, although proposed defaults still require confirmation.

Bringing Enterprise Knowledge into the Decision Chain

AWS Quick uses Enterprise Connectors to ingest data from Slack, Outlook, Jira, Salesforce, SharePoint, ServiceNow, and other systems. It organizes relevant people, projects, and decisions into a personal knowledge graph. The context that informs a decision therefore includes not only document text but also discussion history, participants, requirement origins, and prior decision relationships.

The Discovery agent can combine interactive questions, URL ingestion, and connector data to build a Pain Point Board, then rank issues by severity and frequency. These 0-to-10 scores are structured heuristics rather than statistically calibrated business forecasts. Severity and frequency may be inferred semantically by the model and remain exposed to sampling bias, duplicated feedback, and missing customers. The scoring matrix is therefore useful for structuring discussion and ranking, but it should not replace market research or financial analysis.

Prioritize uses different weighted criteria for agentic and traditional applications. Agentic cases are evaluated for LLM capability fit, tool availability, and user acceptance; conventional cases are evaluated for feasibility, business impact, and effort. The team can inspect the Scoring Matrix to understand why one use case ranks above another. This explicit weighting is more governable than an opaque aggregate score, although it also moves potential bias into metric design and human assignment.

From Customer Problem to Engineering Specification

After a use case is selected, the Working Backwards agent creates customer-facing and internal PR/FAQ documents covering unit economics, failure modes, regulatory risk, and the competitive landscape. The purpose is not to produce promotional material quickly, but to attempt to invalidate the concept before engineering resources are committed. If the proposal cannot answer key questions, the team can expose the gap on paper.

The Spec Generator converts the validated PR/FAQ into prototype_spec.md, including acceptance criteria, user flows, constraints, screens, a data model, and a design handoff brief. Each requirement can be traced back to the original pain point, prioritization score, and PR/FAQ. One artifact then serves two purposes: it is the build contract for coding agents and the evaluation rubric for a review agent.

The Designer produces journey maps, wireframes, and clickable HTML prototypes. Teams can validate the concept before moving into Figma or formal engineering, reducing ambiguity in text-only discussions. Yet generated prototypes can amplify ambiguities already present in the requirements and cannot replace usability testing, professional visual design, or real user behavior data.

Connecting Coding Agents through ACP

AWS Quick delivers work to downstream coding agents through the Agent Client Protocol (ACP). ACP is an open JSON-RPC 2.0 protocol that AWS describes as vendor-lock-in resistant, allowing coding agents such as Kiro and Claude Code to consume the shared specification.

Separating protocol from business workflow is an important engineering benefit. Product teams do not need to rewrite the requirements into one coding agent's proprietary format, and the organization retains control over specifications, approvals, and build entry points. Protocol interoperability, however, does not eliminate model misunderstanding. Delivery quality still depends on executable acceptance criteria, complete test fixtures, and sufficient permissions to access external systems.

Engineering Trade-offs: Speed, Governance, and Integration Cost

The primary advantage is that evidence collection, document drafting, and prototype generation can occur within one conversational workflow. The source states that prototype work that previously took weeks may fall to days or hours, but it provides no controlled experiment, sample size, token consumption, model configuration, or end-to-end cost. The claim should therefore not be treated as a universal production metric.

The main costs fall into three areas:

1. Connector and permission management: Connecting Slack, Jira, Salesforce, and similar systems introduces least-privilege requirements, sensitive-data handling, employee offboarding, broken-connector behavior, and data-residency constraints.
2. Context and retrieval quality: Adding more enterprise data does not automatically improve decisions. Irrelevant context dilutes attention, while erroneous retrieval can create confidently presented but unsupported conclusions.
3. Multi-agent consistency: Separate specialist and Orchestrator logs improve traceability but introduce state synchronization, retry, and version-conflict issues. A production implementation needs a durable state machine, idempotent jobs, artifact schema validation, and approval signatures. Prompt and JSON configuration in the GitHub example does not automatically provide these capabilities.

Human gates can also become throughput bottlenecks. If several roles must approve artifacts sequentially, only part of the drafting time saved by agents may translate into shorter delivery cycles. The result depends on whether approvals can run in parallel, whether feedback is structured, and whether reviewers are willing to work directly with Quick Spaces artifacts.

Deployment Recommendations and Validation Checklist

Teams should pilot the workflow with a low-risk product feature rather than immediately covering the entire development organization. Before deployment, they should:

• Define least-privilege scopes, retention policies, and auditable access records for every connector;
• Define fixed schemas for pain points, scores, specifications, and approvals, separating source evidence, model inference, and human decisions;
• Replay historical projects to test score stability, PR/FAQ risk discovery, and specification ambiguity;
• Blind-compare generated and human specifications while separately measuring rework time, missed requirements, and coding-agent first-pass success;
• Record model versions, prompt versions, specification hashes, and approvers at the ACP handoff to preserve reproducibility;
• Conduct real-user testing rather than treating generation speed as validation strength.

AWS also states that retained agents and test artifacts incur no cost at rest, but the billing behavior of connector calls, model inference, storage, and downstream coding-agent execution must be checked for the target deployment.

Core Value

AI-PDLC does not replace the product team with one super-agent. It separates evidence collection, proposal challenge, specification generation, design prototyping, and coding handoff into auditable stages. Its strongest feature is not faster document production, but the use of one traceable specification to connect customer signals, business decisions, and engineering execution, bounded by human approvals and an open handoff protocol.

That is still a reference architecture and implementation guide from AWS, not a new model or autonomous engineering system validated by a public benchmark. Its real engineering value must be measured through historical-project replay, defect discovery, requirements rework, delivery cycle time, and cost per project.

---

Source: AWS Machine Learning Blog (2026-11-11)

— END —

Tags: #AWS Quick Follow #AI-PDLC Follow #Multi-Agent Orchestration Follow #Agent Client Protocol Follow #Product Development Follow