AWS Quick ganha seis agentes para product managers: das reclamações de clientes à especificação

Os agentes de código ensinaram as equipes a escrever código em dias em vez de semanas. O efeito colateral é desagradável: se você construiu rapidamente algo que não era necessário, apenas chegou mais depressa ao fracasso. Em seu blog, a AWS propõe deslocar o esforço rio acima, para o ponto em que a equipe escolhe o problema e formula a tarefa. Para isso, a empresa lançou o AI-PDLC, um conjunto de seis agentes dentro do AWS Quick.

Que problema isso resolve

Os sinais sobre o que os clientes precisam estão espalhados por dezenas de sistemas. Os feedbacks ficam no Slack, os insights de vendas no Salesforce, os incidentes no ServiceNow, os requisitos no SharePoint, as tarefas no Jira, e as decisões se perdem em e-mails e reuniões. A cada repasse o contexto se perde, e o que chega ao desenvolvedor é um ticket de uma linha, sem explicação de por que ele é necessário.

O AWS Quick funciona aqui como camada de ligação. Conectores corporativos puxam os dados, o sistema constrói um grafo de conhecimento de pessoas, projetos e decisões, e os agentes se apoiam nesses dados e depositam os resultados em um Space compartilhado. A equipe não começa cada iniciativa do zero.

Como funciona o pipeline

O usuário conversa apenas com o orquestrador. Ele lê as instruções dos especialistas durante a execução, faz perguntas sobre a etapa atual e repassa a tarefa ao agente adequado. Só é possível avançar depois que uma pessoa confirma o resultado. Todas as decisões são registradas duas vezes: o especialista as anota em seu artefato, e o orquestrador mantém um log geral e verifica se os registros estão lá.

O post detalha quatro etapas «de produto» das oito. As outras quatro (Engineer, Ship, Operate, Learn) ficam com os agentes de código.

• Discover. O agente coleta reclamações do Slack, do Jira, de tickets de suporte e do Salesforce, avalia cada uma por gravidade e frequência e entrega o Pain Point Board.
• Decide. O agente Prioritize atribui notas de 0 a 10. Em casos agênticos, avalia a adequação às capacidades do LLM, a disponibilidade de ferramentas e a adoção pelos usuários. Em aplicativos comuns, avalia viabilidade, impacto no negócio e esforço. Em seguida, o Working Backwards escreve um PR/FAQ pelo método da Amazon, com perguntas sobre economia unitária, modos de falha, riscos regulatórios e concorrentes. Se a ideia não sobrevive a ele, você descobre isso no papel, e não depois de sprints.
• Design. O Spec Generator transforma tudo isso em uma especificação com critérios de aceitação, cenário de usuário e restrições. Cada requisito está vinculado à dor original, à nota de prioridade e ao PR/FAQ.
• Prototype. O agente Designer desenha jornadas, wireframes e protótipos HTML clicáveis.

O arquivo final chama-se prototype_spec.md. Seus critérios de aceitação servem a dois propósitos: são o contrato para o agente de código e a rubrica para o agente de revisão. A entrega ocorre via Agent Client Protocol (ACP), um padrão aberto sobre JSON-RPC 2.0. O executor pode ser o Kiro, o Claude Code ou outro agente compatível.

O ritmo é escolhido de antemão. O Deep Discovery faz de 8 a 12 perguntas por etapa e é indicado para áreas desconhecidas. O Fast Track se limita a 3–5 perguntas e sugere respostas padrão, que podem ser aceitas ou alteradas.

Como iniciar e onde aplicar

São necessários um workspace do AWS Quick com cliente desktop e permissões para criar agentes personalizados com conectores ligados. Depois, passo a passo:

• clone o repositório AI-PDLC no GitHub e pegue o arquivo JSON com os agentes;
• no Quick Desktop, vá em Customize → Agents → Create → Create from File;
• crie um Space compartilhado para os artefatos e dê acesso à equipe;
• escolha o orquestrador e escreva «Run the full pipeline» ou «Fast Track».

Em repouso, os recursos não custam nada. A AWS descreve três cenários. Um produto novo percorre todo o caminho. Uma nova funcionalidade pode pular a pesquisa aprofundada. Um bug de produção se comprime em um único ciclo, em que a causa raiz é registrada como dor e a especificação contém critérios de aceitação verificáveis.

Limitações

Este é um post de fornecedor. A frase «semanas se transformam em dias ou horas» é uma estimativa da AWS, sem medições e sem análise de implantações reais. A solução está atrelada ao ecossistema do Quick e a seus conectores: fora da AWS, seria preciso montar o mesmo manualmente. A qualidade também depende dos dados de entrada. Se há ruído no Slack, a avaliação da gravidade dos problemas será ruidosa, e a pessoa no ciclo ainda precisa verificar as conclusões.

O que levar daqui

As ideias são úteis mesmo sem a AWS. A especificação para um agente de código deve citar a fonte de cada requisito. Os critérios de aceitação devem ser escritos de modo a servir tanto de tarefa quanto de rubrica de revisão. Os pontos de confirmação são necessários entre as etapas, e não um único «aprovar» no final. Se você já está na AWS, use o repositório como base e rode o Fast Track em uma funcionalidade pequena: assim logo ficará claro se a abordagem traz ganho para a sua equipe.