Notas de Campo

Qué se rompe en un pipeline multiagente (y cómo lo acotamos)

18 de julio de 2026 · 7 min de lectura

Las demos multiagente son fáciles. Los sistemas multiagente que sobreviven a ejecuciones reales, redes inestables, cuotas de modelos y entrada hostil son otra disciplina. Construyendo Proposal Architect para el Google for Startups AI Agents Challenge 2026, la mayor parte de nuestro tiempo de ingeniería no se fue en hacer que los agentes conversen, sino en acotar lo que pasa cuando fallan.

Estas son las notas de campo: seis cosas que se rompieron, por qué se rompieron, y el patrón que corrigió cada una.

1. La llamada que nunca vuelve

Síntoma: una ejecución del pipeline se congela en una etapa y se queda ahí para siempre.

Causa raíz: una llamada al modelo sin deadline. Bajo carga, un endpoint de inferencia ocasionalmente ni responde ni falla: simplemente se cuelga, y un await sin límite convierte una llamada lenta en un pipeline muerto.

Patrón: cada llamada al modelo recibe un timeout duro, y cada ejecución un deadline general duro. La recuperación solo es posible cuando la falla es detectable, y la falla solo es detectable cuando la espera tiene límite.

2. Reintentar todo para arreglar una cosa

Síntoma: la última etapa falla, y el reintento ingenuo vuelve a ejecutar el pipeline entero: lento, caro, y capaz de producir una propuesta distinta de la que casi funcionó.

Causa raíz: lógica de reintento que trata el pipeline como una unidad atómica.

Patrón: checkpoint de estado entre agentes y reintento solo de la etapa fallida. Cuando nuestro compositor falló, re-ejecutamos solo el compositor contra el estado ya computado de las etapas anteriores; la arquitectura, las estimaciones y el precio quedaron exactamente como se aprobaron.

3. Las cuotas de los modelos preview se agotan en el peor momento

Síntoma: el pipeline muere en plena demo con errores de cuota.

Causa raíz: los modelos en tier preview vienen con cuotas ajustadas y compartidas, que bajo ejecuciones repetidas no se parecen en nada a los modelos GA.

Patrón: enrutar los caminos críticos a modelos generally-available y reservar los tiers preview o premium para el único paso donde la calidad visiblemente se compone (en nuestro caso, el agente arquitecto). El enrutamiento de tiers es una decisión de confiabilidad tanto como de costo.

4. El crítico que critica de memoria

Síntoma: el crítico adversarial rechaza borradores válidos con afirmaciones sobre capacidades de modelos que están simplemente desactualizadas.

Causa raíz: un crítico anclado en la memoria de entrenamiento alucina el presente.

Patrón: anclar el crítico en hechos vivos (en nuestro caso, un catálogo actual de modelos), para que sus objeciones referencien la realidad y no el recuerdo.

5. El brief es entrada hostil

Síntoma: ninguno, y ese es el problema: rara vez se ve la inyección que funcionó.

Causa raíz: un brief de cliente es texto controlado por el usuario que fluye al contexto de todos los agentes. Eso lo convierte en una superficie de inyección.

Patrón: tratar el brief como entrada no confiable. Endurecer los system prompts y validar todo lo que el modelo produce en la frontera donde se vuelve consecuente. Nuestro gate determinista de precios rechaza números malformados sin importar por qué están malformados: una alucinación y un ataque reciben la misma respuesta.

6. El teléfono se bloqueó y la ejecución "desapareció"

Síntoma: en móvil, el usuario recarga a mitad de una ejecución y pierde el pipeline que estaba mirando.

Causa raíz: estado de la ejecución viviendo en la sesión del navegador.

Patrón: la ejecución pertenece al servidor; el cliente solo la observa. Tras un reload, la interfaz se reconecta a la ejecución en curso en lugar de iniciar otra.

El metapatrón

Cada corrección de arriba es la misma corrección con ropa distinta: define la frontera, acota la espera, conserva el estado, ancla los hechos. Los frameworks de agentes te dan la conversación entre modelos. La ingeniería es todo lo que la rodea.