AWS Quick incorpora seis agentes para product managers: de las quejas de los clientes a la especificación

Los agentes de programación han enseñado a los equipos a escribir código en días en lugar de semanas. El efecto secundario es desagradable: si construyes rápido algo que no hacía falta, simplemente llegas antes al fracaso. En su blog, AWS propone desplazar el esfuerzo río arriba, hacia donde el equipo elige el problema y formula la tarea. Para ello, la compañía lanzó AI-PDLC, un conjunto de seis agentes dentro de AWS Quick.

Qué problema resuelve

Las señales sobre lo que necesitan los clientes están dispersas en una decena de sistemas. Los comentarios están en Slack, los insights de ventas en Salesforce, los incidentes en ServiceNow, los requisitos en SharePoint, las tareas en Jira, y las decisiones se pierden en correos y reuniones. En cada traspaso se pierde contexto, y al desarrollador le llega un ticket de una sola línea sin explicación de para qué sirve.

AWS Quick funciona aquí como capa de conexión. Los conectores corporativos traen los datos, el sistema construye un grafo de conocimiento sobre personas, proyectos y decisiones, y los agentes se apoyan en esos datos y depositan los resultados en un Space compartido. El equipo no empieza cada iniciativa desde cero.

Cómo funciona el flujo

El usuario habla solo con el orquestador. Este lee las instrucciones de los especialistas durante el trabajo, hace preguntas sobre la etapa actual y pasa la tarea al agente adecuado. Solo se puede avanzar después de que una persona haya confirmado el resultado. Todas las decisiones se registran dos veces: el especialista las anota en su propio artefacto, y el orquestador mantiene un registro común y comprueba que las entradas estén ahí.

La publicación analiza cuatro etapas «de producto» de ocho. Las otras cuatro (Engineer, Ship, Operate, Learn) quedan en manos de los agentes de programación.

• Discover. El agente recopila quejas de Slack, Jira, tickets de soporte y Salesforce, evalúa cada una por gravedad y frecuencia y genera un Pain Point Board.
• Decide. El agente Prioritize asigna puntuaciones de 0 a 10. Para casos agénticos, examina el ajuste a las capacidades del LLM, la disponibilidad de herramientas y la adopción por parte de los usuarios. Para aplicaciones convencionales, examina la viabilidad, el impacto en el negocio y el esfuerzo. Después, Working Backwards redacta un PR/FAQ según el método de Amazon, con preguntas sobre economía unitaria, modos de fallo, riesgos regulatorios y competidores. Si la idea no lo supera, lo sabrás sobre el papel y no después de varios sprints.
• Design. Spec Generator convierte todo esto en una especificación con criterios de aceptación, escenario de usuario y restricciones. Cada requisito está vinculado al problema original, a la puntuación de prioridad y al PR/FAQ.
• Prototype. El agente Designer dibuja mapas de recorrido, wireframes y prototipos HTML interactivos.

El archivo final se llama prototype_spec.md. Sus criterios de aceptación sirven para dos fines: son el contrato para el agente de programación y la rúbrica para el agente de revisión. El traspaso se hace mediante Agent Client Protocol (ACP), un estándar abierto basado en JSON-RPC 2.0. El ejecutor puede ser Kiro, Claude Code u otro agente compatible.

El ritmo se elige de antemano. Deep Discovery plantea de 8 a 12 preguntas por etapa y es adecuado para un ámbito desconocido. Fast Track se limita a 3–5 preguntas y ofrece respuestas por defecto que se pueden aceptar o cambiar.

Cómo ponerlo en marcha y dónde aplicarlo

Hará falta un espacio de trabajo de AWS Quick con cliente de escritorio y permisos para crear agentes personalizados con conectores conectados. Después, paso a paso:

• clonar el repositorio AI-PDLC en GitHub y tomar el archivo JSON con los agentes;
• en Quick Desktop, ir a Customize → Agents → Create → Create from File;
• crear un Space compartido para los artefactos y dar acceso al equipo;
• elegir el orquestador y escribir «Run the full pipeline» o «Fast Track».

En reposo, los recursos no cuestan nada. AWS describe tres escenarios. Un producto nuevo recorre todo el camino. Una nueva funcionalidad puede saltarse la investigación profunda. Un bug de producción se comprime en un solo ciclo, donde la causa raíz se registra como problema y la especificación contiene criterios de aceptación verificables.

Limitaciones

Se trata de una publicación de un proveedor. La frase «las semanas se convierten en días u horas» es una estimación de AWS, sin mediciones ni análisis de implantaciones reales. La solución está ligada al ecosistema de Quick y a sus conectores: fuera de AWS habría que montar lo mismo a mano. La calidad también depende de los datos de entrada. Si en Slack hay ruido, la evaluación de la gravedad de los problemas será ruidosa, y la persona dentro del ciclo igualmente debe verificar las conclusiones.

Qué llevarse

Las ideas son útiles incluso sin AWS. La especificación para un agente de programación debe citar la fuente de cada requisito. Los criterios de aceptación conviene redactarlos de modo que sirvan a la vez como tarea y como rúbrica de revisión. Se necesitan puntos de confirmación entre etapas, y no un único «aprobar» al final. Si ya usas AWS, toma el repositorio como base y ejecuta Fast Track en una funcionalidad pequeña: así se verá rápido si el enfoque aporta una mejora en tu equipo.