Product Loop, Parte 2: Encontrar los errores que nadie reportó

En la Parte 1 de esta serie, exploramos por qué una respuesta exitosa del agente no siempre significa un resultado exitoso para el cliente, y por qué el ciclo de producto agéntico, desde la intención hasta la ejecución, corrección y resultado, es la unidad de medida correcta.

Product Loop es un sistema de diagnóstico construido por el equipo de ingeniería de GoDaddy Airo AI Builder. Conecta conversaciones de clientes, transcripciones de soporte, telemetría e historial de código para encontrar problemas que nunca aparecen como errores explícitos, y luego genera tickets estructurados de Jira para que los desarrolladores puedan actuar. Ya está en producción y nos ayuda a mejorar GoDaddy Airo AI Builder. Esta publicación se centra en la capa de diagnóstico: encontrar los problemas de los clientes, comprender sus causas y ayudar a los desarrolladores a solucionarlos.

Un modelo mental simple: bucles dentro de bucles

Piensa en cómo funciona un restaurante.

Un cocinero prueba un plato y ajusta el condimento. La cocina verifica que todo el pedido sea correcto antes de enviarlo. El gerente observa muchos pedidos y nota que los clientes siguen pidiendo que les recalienten la comida. Cada pedido se preparó correctamente, pero algo puede estar saliendo mal entre la cocina y la mesa.

Estos son tres niveles diferentes de retroalimentación:

• Bucle de ejecución — Tomar una acción, verificar el resultado y decidir qué hacer a continuación. Para un agente, eso podría significar llamar a una herramienta y leer su respuesta.
• Bucle de tarea — Seguir trabajando hasta que la tarea completa cumpla sus requisitos, por ejemplo, construir una página y verificar que funcione.
• Bucle de producto — Observar las experiencias de los clientes, investigar los problemas recurrentes y usar los hallazgos para mejorar el producto.

El gerente aún necesita investigar por qué las comidas llegan frías. El patrón le dice dónde buscar, no automáticamente qué lo causó. Product Loop desempeña un papel similar.

Cuando nada falla, pero el cliente sigue teniendo dificultades

Considera un cliente que le pide a Airo mover una imagen a la parte superior de una página. El agente dice que está hecho. El cliente responde: "No, quería decir encima del encabezado." Sigue otro intento, luego otra corrección.

Las llamadas a herramientas podrían tener éxito todas. El cliente podría eventualmente obtener el resultado correcto. Sin embargo, un cambio simple ha requerido más esfuerzo del necesario.

Un contador de fallos puede pasar por alto esa experiencia. Observar conversaciones similares puede revelar si es un malentendido aislado o un problema recurrente con la forma en que el agente interpreta la colocación de imágenes. No toda corrección indica un error; cierta iteración es normal. La pregunta útil es si los clientes tienen que trabajar repetidamente alrededor del mismo comportamiento.

A veces deleitar a los clientes significa eliminar la explicación adicional que nunca deberían haber necesitado dar.

Cómo reunimos la evidencia

Product Loop combina fuentes que cada una revela una parte diferente del problema:

El agente de Product Loop se ejecuta en el arnés de agente Claude. Nuestras conversaciones con clientes se capturan en diferentes sistemas backend, donde el agente puede consultar. El conocimiento sobre el producto y sus capacidades se obtiene a través del propio código base, lo que ayuda a Product Loop a interpretar esas señales desde una perspectiva de código.

La parte importante no es simplemente poner más texto frente a un modelo. Es conectar evidencia alrededor del mismo objetivo del cliente, aplicación, capacidad y período de tiempo. Los identificadores de sesión y aplicación proporcionan vínculos directos donde están disponibles; la redacción similar por sí sola no es suficiente para establecer que dos registros describen el mismo incidente.

De un síntoma repetido a una causa probable

Así es como podría desarrollarse una investigación, usando el ejemplo de colocación de imágenes. Esto es una ilustración, no un incidente de producción específico.

La primera pregunta es si el problema se repite entre clientes. Solicitudes y correcciones similares pueden revelar un patrón, pero el recuento debe reflejar clientes y aplicaciones afectados, no solo muchos mensajes de una conversación larga. Comparar esas conversaciones con llamadas a herramientas y registros ayuda a distinguir una acción que falló de una que tuvo éxito con la interpretación incorrecta.

Esa evidencia le da a la investigación de código una dirección. Un cambio reciente en cómo el agente selecciona secciones de página, por ejemplo, valdría la pena examinar. Verificar los issues existentes de Jira también podría revelar que el comportamiento es anterior a ese cambio: puede ser un problema antiguo cuyo impacto en el cliente fue subestimado en lugar de una nueva regresión.

El tiempo por sí solo no prueba que un PR causó un error. Un cambio fusionado puede que ni siquiera haya llegado a producción cuando ocurrió el problema. Un diagnóstico útil conecta el comportamiento, la ruta de código y la versión desplegada donde esa evidencia está disponible, y hace clara la incertidumbre donde no lo está.

Un ticket de Jira que da a los desarrolladores un punto de partida

Cuando Product Loop identifica un problema recurrente, nos ayuda a generar un ticket de Jira con la investigación adjunta. El ticket explica qué intentaron hacer los clientes, qué sucedió en su lugar y cuántos clientes o aplicaciones se vieron afectados dentro de la ventana de tiempo observada.

El análisis de causa raíz establece la explicación probable, su evidencia de apoyo y cualquier pregunta aún abierta. Las referencias a conversaciones, registros y código relevantes permiten que un desarrollador verifique el razonamiento. Cuando un PR reciente parece responsable, el ticket apunta a él y explica la conexión en lugar de simplemente nombrar un sospechoso.

Product Loop nos ayuda a clasificar los problemas por alcance y gravedad. El producto y la ingeniería pueden entonces sopesar esos hallazgos frente a la urgencia, el esfuerzo y otros compromisos. Apoya la priorización en lugar de convertir cada patrón detectado en una decisión automática de hoja de ruta.

Del diagnóstico a una solución propuesta

Tradicionalmente, un error podría esperar un reporte de cliente, una escalada de soporte, una investigación y varias transferencias antes de que un desarrollador tenga suficiente contexto para comenzar. Product Loop reúne gran parte de esa recopilación de evidencia y preparación de tickets. Los desarrolladores pasan menos tiempo reconstruyendo lo que sucedió y pueden comenzar con una explicación enfocada para verificar.

El mismo ticket también le da a nuestro agente de codificación un punto de partida útil. Con acceso autorizado al código base, los agentes de codificación pueden seguir la evidencia citada, probar la explicación propuesta y presentar un PR con una solución y pruebas de apoyo.

¿Por qué mantener un humano en el ciclo para las fusiones si el diagnóstico ya es tan bueno?

Porque un diagnóstico plausible y un parche funcional no son lo mismo que un cambio seguro. Una solución podría abordar el síntoma en lugar de la causa, afectar otro flujo de trabajo u omitir una restricción de seguridad o arquitectura. Aunque hemos automatizado la mayor parte de nuestro proceso de revisión de código, cada cambio aún pasa por un revisor humano que verifica el razonamiento, las pruebas y las consecuencias más amplias del cambio.

Qué cambia para el equipo y el cliente

Para el equipo de Airo en GoDaddy, Product Loop está cambiando cómo decidimos qué necesita atención. En lugar de comenzar con un reporte aislado de un cliente y reconstruir la historia, nuestros desarrolladores pueden comenzar con las conversaciones, los registros y el código relevante en un solo lugar. Nuestro equipo de producto obtiene una visión más clara de qué problemas siguen recurriendo, incluidos los problemas más antiguos del backlog cuyo impacto en el cliente era fácil de subestimar.

Para los propietarios de pequeñas empresas que usan Airo, el objetivo no es tener una mejor conversación con un agente. Es tener su sitio web listo y volver a administrar su negocio. Tener que explicar una colocación de imagen tres veces interfiere con ese objetivo, incluso si cada llamada a herramienta tiene éxito. Por eso este trabajo nos importa en GoDaddy. Queremos que Airo quite trabajo de las manos de nuestros clientes, no que les dé otro sistema que solucionar.

Preguntas frecuentes

Product Loop es un sistema de diagnóstico desarrollado por el equipo de ingeniería de GoDaddy Airo AI Builder. Conecta datos de conversaciones de clientes, transcripciones de soporte, registros de telemetría, pull requests de GitHub e issues de Jira para identificar problemas recurrentes en productos de IA agéntica, incluidos problemas que nunca desencadenan un error explícito.

El bucle de ejecución cubre un único ciclo de acción y verificación (por ejemplo, llamar a una herramienta y leer su respuesta). El bucle de tarea cubre la secuencia completa de pasos necesarios para completar un objetivo del cliente. El bucle de producto opera en el nivel más alto: observa muchas sesiones de clientes para encontrar patrones, fallos recurrentes y brechas sistémicas que ninguna sesión individual revela por sí sola.

Correlaciona señales de múltiples fuentes: correcciones en conversaciones (donde un cliente tuvo que re-explicar o reintentar), transcripciones de atención, registros de llamadas a herramientas y cambios de código recientes. Un patrón de correcciones similares en múltiples clientes, incluso cuando cada llamada a herramienta tiene éxito, puede indicar una mala interpretación sistemática que nunca aparecería en un registro de errores.

Un diagnóstico plausible y un parche funcional no son lo mismo que un cambio seguro. Una solución podría abordar el síntoma en lugar de la causa raíz, introducir una regresión en otro flujo de trabajo u omitir una restricción de seguridad o arquitectura. Los revisores humanos verifican el razonamiento, las pruebas y las consecuencias más amplias antes de que se fusione cualquier cambio.

El agente de Product Loop se ejecuta en el arnés de agente Claude, desarrollado por Anthropic. Consulta los sistemas backend internos de GoDaddy para obtener datos de conversaciones de clientes y usa el código base del producto como fuente de conocimiento para interpretar señales en contexto.

En la próxima publicación, veremos cómo las mismas señales de producción nos ayudan a construir evaluaciones alrededor de lo que los clientes realmente hacen.

Esta es la Parte 2 de una serie sobre la construcción y medición de productos de IA agéntica. Lee la Parte 1: Cuando tu producto deja de tener un único camino para empezar desde el principio.