Los sistemas multi-agente necesitan tres capas de visibilidad. Salud del sistema, calidad de las ejecuciones y estado del workflow. Para eso usamos un stack de Sentry, Langfuse y LangGraph. Tres herramientas, tres tareas claramente separadas, ninguna resuelve el problema de las otras. Aquí cómo encajan en nuestro caso y por qué precisamente esta combinación.
Los sistemas multi-agente tienen una propiedad que todo el mundo subestima la primera vez que los ve en producción. Una llamada LLM individual es transparente. Metes un prompt, recibes una respuesta, ves las dos cosas. Un pipeline de ocho agentes que colabora durante cuatro días es una caja negra con ocho puertas, cada una con una hipótesis distinta sobre qué hacen las otras siete en cada momento.
Operamos una flota de unos 40 agentes worker repartidos en ocho flotas especializadas. Un pipeline que diseña, construye, revisa y publica servidores MCP. Un equipo de producto que mejora continuamente nuestra memoria SaaS. Un pipeline de contenido para la academia. Operaciones SaaS. Un orquestador chief-of-staff como capa 2 sobre los CEOs de cada flota. Todo sobre el Anthropic Claude Agent SDK en TypeScript, ejecutado a diario vía cron.
La pregunta no es cómo escala esto técnicamente. La pregunta es cómo mantener la calidad alta a lo largo del tiempo. Tres herramientas responden esa pregunta en nuestra arquitectura. Sentry, Langfuse y LangGraph. Cada una resuelve un problema distinto, ninguna resuelve el de las otras.
Lo que de verdad necesitan los setups multi-agente
Tres capas tienen que ser visibles, si no, no se aprende nada.
La primera capa es la salud del sistema. Qué servidor MCP es lento, qué llamada de herramienta devuelve errores JSON-RPC silenciosos en lugar de excepciones, dónde está el pico de latencia que rompe los cron runs. Es trabajo clásico de APM, solo que aplicado a llamadas LLM y servidores MCP en lugar de únicamente a peticiones web.
La segunda capa es la calidad de las ejecuciones. Encontró el agente reviewer los bugs reales o solo produjo findings de relleno. Entregó el agente architect un plan ejecutable o solo un texto bonito. Para un único test run, una persona puede juzgarlo. Para 40 workers y 30 días, eso lo tiene que poder un sistema.
La tercera capa es el estado del workflow. Cuando un subproceso de build crashea tras 13 minutos, no quieres reiniciar el build entero. Quieres reanudar desde el último checkpoint válido. Cuando un tester entrega una salida pendiente de aprobación, quieres human-in-the-loop sin escribir código a medida.
Estas tres capas son ortogonales. Las herramientas que intentan hacer las tres acaban haciendo las tres a medias. Las herramientas que hacen una capa con calidad de primera se combinan en un stack mejor que la suma.
Sentry para errores y salud de servidores MCP
Sentry dispone desde abril de 2026 de auto-instrumentación nativa para servidores MCP. Una línea de código por servidor MCP, y obtienes inmediatamente un dashboard con las herramientas más usadas, distribución de latencia por herramienta, tasa de errores, segmentación por cliente y distribución de transporte. Para cinco servidores MCP en producción, eso son cinco líneas de código para una capa de salud que de otra forma costaría semanas construir.
Lo más importante. El SDK MCP de Anthropic trata los errores como respuestas JSON-RPC en lugar de excepciones. Cuando una herramienta crashea internamente, el caller ve un status de éxito con contenido de error dentro del JSON. Las herramientas clásicas de stack-trace no lo ven. Sentry sí.
En la capa de agentes, Sentry hace auto-instrumentación del Anthropic SDK, escribe los tool-use loops como spans anidados en el trace y trackea token counts incluso cuando el pricing es plano. El volumen de tokens sigue siendo un proxy de calidad valioso aunque no se pague por token. Cuando un architect de pronto necesita cuatro veces más tokens sin que el output mejore, eso es una señal de drift.
El stack es compatible con OpenTelemetry e implementa las GenAI Semantic Conventions v1.36. Es decir, cualquier otra herramienta OTel puede leer los mismos spans. Sin lock-in a formatos de span específicos de Sentry.
Langfuse para calidad de ejecuciones, evals y gestión de prompts
Langfuse es la respuesta productiva a la pregunta de si los agentes mejoran o empeoran con el tiempo. Licencia MIT, self-host posible, integración dedicada para Claude Agent SDK en el SDK TypeScript v4.
Tres capacidades que marcan la diferencia en la práctica.
Tracing. Las llamadas multi-agente se visualizan como agent graphs, no solo como un span-tree lineal. Quién llama a quién, qué tool calls hay entre medias, dónde se rompe el trace, dónde explota el consumo de tokens.
Evals vía LLM-as-judge. Mantenemos goldsets, es decir, suites de tests curadas con outputs esperados, y los ejecutamos automáticamente en cada cambio de código sobre un agente. Evaluadores custom puntúan si el agente entregó los findings esperados. Eso hace que la calidad sea medible en el tiempo en lugar de subjetiva. Si el agente reviewer cogía 18 de 20 casos hace dos semanas y ahora solo 14, sabes que algo ha derivado y puedes ir a buscar la causa.
Gestión de prompts con versionado. Los prompts no viven hardcoded en source files. Versionados, labels para A/B tests, es decir, prod-a contra prod-b corriendo en paralelo, performance por versión trackeada automáticamente por latency, tokens y eval score. Rollback es un clic, no un git revert.
Self-host corre sobre Docker más Postgres más ClickHouse, exactamente la toolchain que ya tenemos en nuestro AI server. Licencia MIT, todas las features de producto sin límites, solo los módulos enterprise para SCIM, audit log y data-retention policies necesitan licencia.
LangGraph para workflows con estado
A LangGraph lo usamos de forma selectiva, no en todas partes. En concreto, en las secuencias donde un workflow corre a lo largo de varias llamadas a subprocesos y varias horas, y un crash a mitad no puede llevar a un re-run completo. El pipeline MCP factory es el caso de uso clásico. Architect escribe un plan, builder escribe el código, reviewer encuentra los findings, tester hace el smoke en vivo. Cuatro subprocesos, varias horas, muchos puntos donde algo externo puede romperse. Un npm install que falla, un git clone que da timeout, una tool-call MCP que se queda colgada.
Con LangGraph como state graph con checkpointing en Postgres, el workflow se vuelve durable. El estado, es decir, plan path, build slug, findings, vive en la StateGraph, cada output de un nodo se checkpointea. Un crash en el paso tres de cuatro significa reanudar desde el último checkpoint válido, no reinicio total. Output PARTIAL del tester dispara interrupt() para aprobación manual. Human-in-the-loop sin que tengamos que construirlo nosotros.
LangGraph lo corremos con un subprocess adapter. Cada nodo de LangGraph spawnea nuestro worker existente como subproceso en lugar de hacer una llamada LangChain ChatModel. Eso tiene un efecto importante. Nuestros workers se quedan inalterados sobre el Anthropic Claude Agent SDK, la arquitectura de pricing se mantiene, sin cambio a billing por token. LangGraph orquesta el workflow, los workers siguen siendo ellos mismos.
El adapter es manejable. Unas 80 líneas de TypeScript. El Postgres checkpointer es production-ready y crea tres tablas en su propio schema. Los MCP adapters de LangChain conectan servidores MCP existentes de forma transparente como herramientas LangChain, así que tampoco hay rewrite por ahí.
LangGraph trae un trade-off. Licencia propietaria, es decir, riesgo de lock-in si la estrategia de pricing cambia. Aceptamos ese riesgo solo donde el valor del resume entrega ROI real. Para el 80 por ciento de nuestros workflows, el Claude Agent SDK por sí solo es suficiente.
Dónde se solapa el stack
Un punto, una solución. Sentry y Langfuse instrumentan ambos las llamadas LLM vía OpenTelemetry. Si Sentry inicializa primero, que es lo que hace por defecto, se traga los spans de Langfuse. La solución está documentada. Un TracerProvider compartido, los dos SpanProcessor enganchados. Noventa minutos de setup, y luego cada herramienta ve sus propios spans.
Quien no sepa esto de antemano, lo debuggea durante dos días. Quien lo sepa, lo deja en el bootstrap file y se olvida.
Lo que mantiene unido al stack
Tres propiedades que pesamos al elegir herramientas.
Open standards primero. Sentry y Langfuse son ambos compatibles con OTel y GenAI Semantic Conventions. Los spans viajan sin cambio de código. Quien quiera mañana enviar esos spans a un tercer sink, sea Honeycomb, Datadog o un sistema propio, no necesita rewrite.
Self-host donde sea posible. Langfuse está self-hosted en nuestra propia infraestructura. Sentry Cloud lo usamos por conveniencia, pero Sentry también es self-hostable. La soberanía de los datos sigue siendo controlable.
Respetar el pricing plano. Nuestra arquitectura de pricing es plana, no por token. Las herramientas que nos forzaran a pasar a billing por token serían un coste real. El patrón de subprocess adapter mantiene a LangGraph compatible con esta arquitectura.
Lecciones que valen para todo el que construye multi-agente
Del trabajo de stack, no específicas de un dominio.
El volumen de tokens es también un proxy de calidad bajo pricing plano. De pronto cuatro veces más tokens para el mismo output es una señal de drift, da igual si pagas por ello o no. Quien no trace esto ve el drift solo semanas después, cuando el output empieza a notarse peor.
Los errores de servidores MCP como respuestas JSON-RPC en lugar de excepciones son una clase especial de bugs que las herramientas APM clásicas no cogen. Existe una toolchain que sí los coge, usarla cuesta minutos y devuelve días.
Workflows con estado y resume solo tienen sentido a partir de cierta complejidad. Los agentes single-step no necesitan eso. Workflows multi-step a lo largo de varias horas con dependencias externas reales como npm, git o APIs de terceros se benefician muchísimo. El umbral para el switch es más alto de lo que la mayoría de tutoriales sugiere. Quien mete LangGraph o una herramienta orquestadora comparable demasiado pronto se queda con más complejidad de stack que valor real.
Lo que el stack no hace
No toma las decisiones de arquitectura. No hace el prompt engineering. No hace el modelado del dominio. Hace visible lo que pasa. Lo que aprendes de eso, es trabajo tuyo.
Sentry más Langfuse más LangGraph son tres herramientas para tres problemas. Quien tiene los tres problemas, gana con el stack. Quien tiene solo uno, debería instalar solo uno. El tooling sprawl es un anti-patrón real en setups solo y equipos pequeños.
En nuestro caso los tres problemas corren a la vez por la flota. Por eso las tres herramientas.
