Los agentes salieron del laboratorio: ganaron orquestador, cache durable y MCPs estandarizados en la misma semana en que un post-mortem catalogó 22 formas en que fallan silenciosamente.
Sesenta días.
Es cuánto un agente en producción puede pasar entregando resultados plausibles—y completamente falsos—antes de que alguien lo note.
Este es el Wire de ai|expert. Esta semana, agentes ganaron orquestrador, cache durable y MCPs estandarizados. Y un post-mortem catalogó 22 formas en que fallan sin hacer ruido.
El paper más importante de esta semana no vino de un laboratorio de investigación. Vino de un post-mortem de producción. [ref: longitudinal-study-uncovers-22]
Un agente personal en ejecución continua desde marzo de 2026: 40 jobs agendados, 8 proveedores de LLM, 4.286 pruebas unitarias, 827 verificaciones de gobernanza. Y aún así: 22 fallos silenciosos en ocho semanas, con un meta-patrón repitiéndose 28 veces.
Los autores nombraron cinco clases de mecanismo. La que más preocupa a arquitectos de producción es la Clase D—"encadenamiento de alucinación y fabricación".
Cuando el sistema encuentra un error, el modelo no lanza una excepción. Reescribe el error en narrativa coherente y lo entrega directo al usuario. Los autores llaman a esto "fail-plausible": el observador no está solo ciego. Está siendo activamente engañado por la propia señal de fallo.
El agente no falla. Fabrica una coartada.
Y 70% de esos fallos silenciosos fueron detectados por observación humana del output final—no por pruebas, no por auditorías automatizadas. La latencia del incidente varió de 13 horas a 60 días. Los más duraderos vivían en las costuras—entre el proxy de gobernanza de herramientas, el plano de memoria de base de conocimiento y los proveedores de LLM. Donde ninguna prueba se ejecuta.
Una auditoría retrospectiva de 15 incidentes encontró 0% de prevención ex-ante y 87% de bloqueo de regresión.
Las auditorías son motores de regresión. No de predicción. La investigación modeló esto como decaimiento entrópico: analizando más de 100.000 interacciones de producción y 40.000 trials controlados, el desorden se acumula monotónicamente con los rounds de interacción. El fallo silencioso no es una clase de bug para corregir. Es una restricción termodinámica a gobernar.
Para arquitectos de sistemas multi-agente: la complejidad del código no era predictor de incidente. El área de superficie de boundary era.
Un paper de UC San Diego, Johns Hopkins, University of Washington e UIUC llegó con una respuesta formal a una pregunta que equipos de producto responden empíricamente cada semana: ¿qué determina el rendimiento de un agente? [ref: agentspec-modular-framework-fo]
AgentSpec divide agentes embodied en seis componentes intercambiables con interfaces estandarizadas: Percepción, Memoria, Razonamiento, Reflexión, Acción y un módulo opcional de RL. Probado en DeliveryBench, ALFRED, MiniGrid y RoboTHOR.
El hallazgo central no es sobre la calidad de cada módulo. Es sobre compatibilidad de scaffold y efectos de interacción. El mejor módulo de razonamiento es inútil si la representación de memoria que recibe viola sus suposiciones sobre granularidad de estado y horizonte de tarea.
El hallazgo operacional más crítico: las políticas entrenadas con RL solo componen bien cuando se optimizan con la estructura de scaffold del deployment. Si versionas el scaffold sin actualizar el módulo de RL junto con él, el rendimiento colapsa. Training e inference no pueden versionarse de forma independiente.
Los scaffolds no son infraestructura neutral. Moldean el landscape de optimización de todo lo que hospedan.
Aún en el tema de detectar cuándo un agente está errando: un preprint en arXiv propone consistencia operádica—OC—como método sin label para detectar fallos de razonamiento composicional en tiempo de inferencia. [ref: detecting-llm-reasoning-failur]
El mecanismo: el modelo responde una query compleja directamente. Después, la misma query se descompone en sub-problemas, se responde parte a parte y se recompone. Las discrepancias entre los dos caminos señalan razonamiento sospechoso. Sin ground-truth. Sin anotador externo. Sin fine-tuning.
Probado en doce LLMs de 4B a 671B parámetros. Correlaciones de Pearson entre 0,86 y 0,94 con precisión en cuatro datasets de QA multi-hop—la única señal con r mayor o igual a 0,85 uniformemente en los cuatro. Chain-of-thought self-consistency cae a r de aproximadamente 0,45 en MuSiQue y StrategyQA. OC no.
Selective prediction con budget K=3 entrega lifts de AUARC de +0,086 a +0,096 y de AUROC de +0,092 a +0,164, con intervalos de confianza de 95% excluyendo cero en todas las celdas. El costo: tres passes de inferencia. Y para modelos de razonamiento con chain-of-thought opaco o llamadas de tool intercaladas, la descomposición falla silenciosamente.
El patrón que vale robar: la distancia entre la respuesta directa y la auto-descomposición es un score de confianza sin-label para cualquier prompt composicional.
Y mientras la investigación mapeaba los patrones de fallo, tres piezas de infraestructura llegaron la misma semana—como si la industria supiera que necesitaba cerrar la brecha.
Primero: Databricks open-sourceó Omnigent bajo Apache 2.0. Un meta-harness para componer y controlar agentes de código—Claude Code, OpenAI Codex, Pi y agentes customizados—a través de una API uniforme. [ref: databricks-launches-omnigent-to-operationalize-multi-agent-workflows]
El problema que motivó a Omnigent es concreto. En Databricks, con más de 5.000 ingenieros, el flujo real era ejecutar cuatro o cinco agentes en paralelo y copiar y pegar contexto entre terminal, Google Docs y Slack. La falta de un harness único que compartiera estado o delegara entre boundaries de herramientas estaba costando horas.
La arquitectura tiene dos componentes: un Runner que aísla cada agente en sesión sandboxed con interfaz uniforme—mensajes y archivos entran, text streams y tool calls salen—y un Server que hospeda políticas y lógica de compartición. Una línea de YAML para cambiar el modelo subyacente. Política de costo configurable: pausa el agente después de USD 100 de gasto por sesión.
El riesgo no abordado: sin benchmarks de latencia publicados, el overhead de rutear todo I/O de agente por el meta-harness es desconocido. Si el policy engine o el state tracker se degradan, todos los agentes compuestos se detienen—y el debug ahora atraviesa dos capas de abstracción.
Segundo: AWS habilitó durabilidad en ElastiCache para Valkey 9.0. El archivo append-only local se fue. Entró un log transaccional Multi-AZ que replica writes entre zonas de disponibilidad. [ref: aws-elasticache-adds-durabilit]
Dos perfiles de persistencia. Síncrono: reads por debajo de 300 microsegundos en 50.000 TPS, escalando a 879 microsegundos en 100.000 TPS, writes en milisegundos single-digit, con costo adicional. Asíncrono: latencia de microsegundos, sin costo extra—pero con ventana de hasta 10 segundos de pérdida si falla el primario.
Para stacks de agente que hoy ejecutan ElastiCache junto a DynamoDB para persistir contexto de conversación y estado de workflow, la simplificación es real: un cluster para memoria caliente y estado de corto plazo. Pero Corey Quinn, del Duckbill Group, avisa que la lección de no confundir cache con datastore primario usualmente se aprende después de una violación de SLA. Estado de transacción comprometido no pertenece aquí.
Tercero: HashiCorp anunció disponibilidad general del Terraform MCP Server el 11 de junio. Dieciséis herramientas en la configuración por defecto, con tres toolsets—registry, registry-private y terraform—exponiendo operaciones de workspace, inspección de planes y políticas Sentinel. [ref: hashicorp-mcp-server-enables-a]
Operaciones destructivas—create_run, plan_and_apply, eliminación de workspace—deshabilitadas por defecto detrás del flag ENABLE_TF_OPERATIONS=false. El default correcto: separación binaria a nivel de ambiente entre herramientas de descubrimiento somente-lectura y mutaciones destructivas. Si tu plataforma interna de agentes no tiene este gate, el blast radius está abierto.
Sin plan sandbox. Sin eval harness. La seguridad depende de IAM de ambiente más este toggle de ambiente. Un cliente comprometido con token válido aún puede exfiltrar metadatos de workspace.
La última pieza es el browser. WebMCP entró en origin trials en Chrome 149 el 19 de mayo, co-autorado por Google y Microsoft bajo el W3C Web Machine Learning Community Group. La propuesta: sitios exponen contratos de herramientas tipadas directamente a agentes en el browser, eliminando el loop no-determinístico que se quiebra con CSS layout shifts o carga tardía de anuncios. [ref: webmcp-standard-for-agentic-web-actuation-now-in-chrome-origin-trials]
Benchmarks de scriptwalker.app muestran completitud de tareas 8 a 12 veces más rápido que automatización por visión. Byteiota reportó 67% menos errores y 45% mejor tasa de conclusión comparado a scraping visual. Booking.com, Shopify, Instacart, Expedia, Intuit y Redfin se comprometieron a implementaciones. Adopción ya en 12% de sitios enterprise y 41% en e-commerce. Chrome DevTools para Agents 1.0 llegó junto con los trials, exponiendo logs de consola, tráfico de red y traces de performance vía servidor MCP con panel dedicado WebMCP.
Microsoft ya había embarcado soporte en Edge 147 en marzo de 2026.
El problema estructural: monocultura. El único agente consumiendo WebMCP hoy es Gemini en Chrome. Aún necesitas mantener stack paralela de automatización por visión para páginas no anotadas, para Firefox hasta Q3 y para Safari hasta Q4 de 2026.
Y el riesgo adversarial permanece sin abordarse: cualquier página puede registrar definiciones de herramientas falsas para manipular agentes en acciones no autorizadas. Trata como capa de bajo riesgo hasta que el modelo de permiso se endurezca. No conectes a flows de pago o identidad.
Agentes ganaron orquestrador, cache durable y MCP estandarizado. Y aún así, la mayoría de los fallos silenciosos en producción solo aparecen cuando un humano mira el output. La infraestructura llegó. La observabilidad en las costuras aún no. Wire el lunes. Hasta entonces.