Caso de estudio

Sistema multi-agente para operación y soporte de datos

Agentes que consultan, diagnostican y re-ejecutan jobs de integración en producción.

// Rol: Integrations Engineer, cara técnica ante el cliente
// Contexto: Empresa fintech de conciliación y automatización de datos financieros (proyecto privado)
// Stack: Google ADK, LangGraph, Gemini, Text-to-SQL, DynamoDB, PostgreSQL vía MCP, AWS EKS, AWS Batch, AWS CloudWatch, sistema de tickets

Problema

Cada cliente llegaba con fuentes de datos distintas, y cada integración generaba trabajo operativo recurrente: preguntas sobre el estado de los jobs, fallos en pipelines que había que diagnosticar leyendo logs, y tickets de re-ejecución que alguien tenía que validar, lanzar y cerrar a mano.

Como Integrations Engineer yo estaba de cara al cliente. Escuchaba el problema en la reunión, entendía su fuente de origen y desarrollaba la conexión. Después de entregarla, el costo estaba en la operación diaria: el mismo tipo de ticket, varias veces al día, con el mismo patrón de diagnóstico.

La pregunta de diseño fue: qué parte de ese ciclo (consultar, diagnosticar, re-ejecutar) se puede automatizar con agentes sin perder control sobre los datos del cliente.

Arquitectura

Un patrón Router + Especialistas sobre un grafo con estado (LangGraph, Google ADK):

flowchart TD
User["User Events (Slack / Zendesk / CLI)"] --> Router

subgraph EKS["Agent Services on AWS EKS"]
    Router["AgentRouter (gemini-2.0-flash)"]
    Router -->|"DATA_QUERY"| SQL["JobsSQLAgent"]
    Router -->|"DOCUMENTATION"| Docs["DocsRAGAgent"]
    Router -->|"DIAGNOSTIC"| Diag["SupportDiagAgent"]
    Router -->|"REEXECUTION"| Reexec["ReexecutionAgent"]
end

SQL --> DB[("PostgreSQL via MCP")]
Docs --> KB["Markdown Knowledge Base"]
Diag --> DB
Diag --> CW[("AWS CloudWatch Logs")]
EKS -.-> DDB[("DynamoDB (State & Memory)")]

Reexec --> API[("Backend API")]
API --> Batch[("AWS Batch")]

classDef default fill:#0f172a,stroke:#38bdf8,stroke-width:1px,color:#e2e8f0
classDef router fill:#881337,stroke:#f43f5e,stroke-width:1px,color:#fecdd3
classDef specialist fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#e0e7ff
classDef storage fill:#022c22,stroke:#10b981,stroke-width:1px,color:#d1fae5

class Router router
class SQL,Docs,Diag,Reexec specialist
class DB,CW,API,Batch,KB,DDB storage

Routerun LLM clasifica la intención del evento entrante (ticket, chat, CLI) y delega al agente correcto. Todos comparten el mismo contexto de sesión.

Agente de consultas (Text-to-SQL)responde preguntas operativas sobre jobs consultando PostgreSQL a través de un toolbox MCP aislado. Valida el esquema y trabaja en modo solo lectura, con conjuntos de consultas curados.

Agente de documentación (RAG)responde sobre la base de conocimiento técnica en Markdown. Usa análisis de documento completo en vez de búsqueda vectorial cuando se necesita extraer requisitos exactos.

Agente de troubleshootingdiagnostica fallos cruzando los logs de ejecución en CloudWatch con los metadatos relacionales.

Agente de re-ejecución (orquestador)lee el ticket, valida los requisitos, apoya su decisión en el agente de consultas y el de troubleshooting, y dispara la re-ejecución a través de la API del backend. El job corre en AWS Batch - el agente nunca toca AWS directamente.

Estado y memoriasesiones en una base NoSQL con TTL; memoria semántica y trazas de ejecución en DynamoDB.

Decisión clave de arquitectura

Decisión clave: el agente de re-ejecución no tiene lógica propia de consulta ni de diagnóstico. Los llama como especialistas, así cada pieza se puede evaluar por separado.

Resultados

Medidos con mi propia evaluación, sin datos de clientes expuestos:

Agente de consultas

95%respuestas correctas, evaluación manual con la interfaz de adk run web

Agente de troubleshooting

98%+accuracy en mi evaluación

Agente de re-ejecución

4 de 5hasta 5 tickets de re-ejecución al día; cerraba de forma autónoma 4 de cada 5

Qué aprendí / siguiente paso

>La persistencia de la memoria es un problema de diseño, no de librería: prototipé con ChromaDB en local y migré todo a DynamoDB para producción. Qué debe recordar un agente, por cuánto tiempo y dónde guardarlo define su comportamiento.
>Las instrucciones y el contexto son el verdadero código de un agente: aprendí a refinar los prompts y el contexto que recibe cada especialista.
>Sin evals, monitoreo y observabilidad no hay mejora confiable: cada cambio hay que medirlo y el comportamiento en producción hay que observarlo.
>Un agente no debe ser un copiloto: el valor está en que autogestione el ciclo completo (consultar, diagnosticar, re-ejecutar) mientras el humano supervisa, no en que ejecute pasos a pedido.