AWS Quick Gets Six Agents for Product Managers: From Customer Complaints to a Spec

Coding agents have taught teams to write code in days instead of weeks. The side effect is an unpleasant one: if you quickly build the wrong thing, you simply reach failure faster. In its blog, AWS suggests shifting effort upstream, to where a team picks the problem and formulates the task. To that end, the company has released AI-PDLC, a set of six agents inside AWS Quick.

What problem it solves

Signals about what customers need are scattered across a dozen systems. Feedback sits in Slack, sales insights in Salesforce, incidents in ServiceNow, requirements in SharePoint, tasks in Jira, and decisions get lost in emails and meetings. Context is lost at every handoff, and the developer ends up with a one-line ticket that doesn't explain why it's needed.

AWS Quick works here as a connective layer. Enterprise connectors pull in the data, the system builds a knowledge graph of people, projects, and decisions, and the agents rely on that data and put their results into a shared Space. The team doesn't start every initiative from a blank slate.

How the pipeline works

The user talks only to the orchestrator. It reads the specialists' instructions on the fly, asks questions about the current stage, and hands the task to the right agent. You can move on only after a human has confirmed the result. All decisions are logged twice: the specialist records them in its own artifact, while the orchestrator keeps a shared log and checks that the entries are in place.

The post covers four "product" stages out of eight. The remaining four (Engineer, Ship, Operate, Learn) are left to coding agents.

• Discover. The agent collects complaints from Slack, Jira, support tickets, and Salesforce, scores each by severity and frequency, and produces a Pain Point Board.
• Decide. The Prioritize agent assigns scores from 0 to 10. For agentic use cases, it looks at fit with LLM capabilities, tool availability, and user adoption. For ordinary applications, it looks at feasibility, business impact, and effort. Then Working Backwards writes a PR/FAQ using the Amazon method, with questions about unit economics, failure modes, regulatory risks, and competitors. If an idea doesn't survive it, you find out on paper rather than after sprints.
• Design. Spec Generator turns all of this into a specification with acceptance criteria, a user scenario, and constraints. Every requirement is linked to the original pain point, the priority score, and the PR/FAQ.
• Prototype. The Designer agent draws journey maps, wireframes, and clickable HTML prototypes.

The final file is called prototype_spec.md. Its acceptance criteria serve two purposes: they are a contract for the coding agent and a rubric for the review agent. The handoff goes through the Agent Client Protocol (ACP), an open standard built on JSON-RPC 2.0. The executor can be Kiro, Claude Code, or another compatible agent.

The pace is chosen in advance. Deep Discovery asks 8–12 questions per stage and suits an unfamiliar domain. Fast Track limits itself to 3–5 questions and offers default answers that you can accept or change.

How to launch it and where to use it

You will need an AWS Quick workspace with the desktop client and permissions to create custom agents with connected connectors. Then, step by step:

• clone the AI-PDLC repository on GitHub and grab the JSON file with the agents;
• in Quick Desktop, go to Customize → Agents → Create → Create from File;
• create a shared Space for artifacts and give the team access;
• select the orchestrator and type "Run the full pipeline" or "Fast Track".

When idle, the resources cost nothing. AWS describes three scenarios. A new product goes through the whole path. A new feature can skip deep discovery. A production bug is compressed into a single cycle, where the root cause is recorded as a pain point and the spec contains verifiable acceptance criteria.

Limitations

This is a vendor post. The phrase "weeks turn into days or hours" is AWS's own estimate, with no measurements and no analysis of real deployments. The solution is tied to the Quick ecosystem and its connectors: outside AWS, you would have to assemble the same thing by hand. Quality also depends on the input data. If Slack is noisy, the severity scoring will be noisy too, and a human in the loop still has to check the conclusions.

What to take away

The ideas are useful even without AWS. A spec for a coding agent should cite the source of every requirement. Acceptance criteria should be written so that they serve as both the assignment and the review rubric. Confirmation points are needed between stages, not a single "approve" at the end. If you are already on AWS, take the repository as a starting point and run Fast Track on one small feature: that will quickly show whether the approach gives your team a boost.