Los ingenieros de Slack publicaron una explicación de arquitectura — cubierta por InfoQ el 28 de abril — sobre cómo manejan el contexto en sistemas multi-agente de larga duración, donde una aplicación puede abarcar cientos de requests y generar megabytes de salida. Los frameworks de agentes estándar acumulan historial de chat entre llamadas, pero en sesiones de producción largas ese enfoque pega contra el techo del context window y degrada la calidad de las respuestas bastante antes del límite duro. El staff engineer Dominic Marks describe la alternativa: reemplazar la acumulación de chat logs con canales de memoria estructurados, agentes críticos dedicados y una línea de tiempo destilada que sobrevive durante toda la vida del run.
La arquitectura es un patrón coordinator/dispatcher. Un coordinador central recibe las requests y las dirige a agentes especializados aguas abajo — expertos que hacen el trabajo real, y críticos que evalúan la salida de los expertos. Los críticos son necesarios porque (según Slack) una porción de los hallazgos de los expertos "podría estar inventada o malinterpretar groseramente los datos." Tres canales de contexto estructurados llevan el estado corriente en lugar de un chat log sin límite. El diario del director guarda la memoria de trabajo estructurada del director — hallazgos, observaciones, decisiones, preguntas abiertas, hipótesis — y es descrito como "la narrativa común que mantiene a los demás agentes en carril." La revisión del crítico es un reporte de hallazgos anotado con scores de credibilidad, construido por críticos instruidos estrechamente a "sólo hacer un juicio sobre los hallazgos presentados" — es decir, sin deriva, sin invención. La línea de tiempo del crítico construye una narrativa coherente a partir del diario del director, la última revisión y la línea de tiempo previa, deduplicando hallazgos y resolviendo conflictos prefiriendo evidencia ponderada por credibilidad.
El patrón importa porque la estrategia de acumulación de chat logs que funciona para interacciones cortas en agente único no escala a workflows de producción multi-paso. Tres cosas que el diseño de Slack implica ahora son sentido común de industria para agentes de larga duración: los agentes críticos son necesarios porque los agentes expertos alucinan a tasas significativas; la memoria estructurada le gana al historial de chat crudo porque fuerza a resumir y a scoring de credibilidad; y la destilación narrativa ordenada en el tiempo — la "línea de tiempo" de Slack — se necesita para mantener a los agentes coherentes a lo largo de cientos de requests. El patrón es generalizable: cualquier equipo que corra workflows multi-agente que abarquen minutos a horas en vez de segundos va a necesitar alguna forma de split director/crítico/línea-de-tiempo, o un equivalente cercano. Los nombres exactos de canales y estructuras van a variar, pero los tres roles — portador de narrativa, scorer de credibilidad, constructor de línea de tiempo — probablemente converjan entre frameworks.
Para los builders, tres cosas concretas. Primero, si construís workflows agentic que abarcan más que el estado de una sola ventana de chat, no acumules sólo historial de mensajes — diseñá canales de memoria estructurados con metadata de credibilidad desde el día uno. Retrofitear ese patrón más tarde es doloroso. Segundo, los agentes críticos restringidos a "sólo juzgar los hallazgos presentados" son la defensa más barata contra alucinación que Slack encontró: scope estrecho más rol dedicado más scoring de credibilidad. Construí eso en tu capa multi-agente en vez de esperar que el agente experto agarre sus propios errores. Tercero, la cultura de ingeniería importa: Slack está publicando esta arquitectura públicamente, lo que significa que los frameworks open source futuros probablemente estandaricen sobre algo como coordinator/director/crítico/línea-de-tiempo. Mirá LangGraph, AutoGen y CrewAI para ver si este patrón aterriza como abstracción de primera clase en los próximos meses.