Anatomía de un equipo empresarial de IA: orquestación de agentes con LangGraph y FastAPI
Un recorrido por una plataforma multiagente de código abierto: cómo se orquestan los agentes cofundador, gerente y especialista, comparten información, hacen pausas para obtener aprobación e informan.
La mayor parte de la automatización basada en IA sigue un modelo de agente único: un modelo recibe una solicitud y devuelve una respuesta. Eso funciona bien para responder preguntas, pero el trabajo empresarial real se distribuye entre diferentes roles, algunas etapas se ejecutan en paralelo y otras deben esperar a que una persona dé su aprobación. Esta guía analiza una plataforma de código abierto, Multi Agent for Business Automation, que modela a un pequeño equipo de startups como agentes coordinados. Al final, deberías comprender cómo se integran su orquestación, memoria, mecanismos de aprobación y la interfaz API, así como qué opciones de diseño puedes reutilizar en tus propios sistemas de agentes.
De un chatbot a una oficina virtual
Considere cómo se planifica realmente una nueva empresa. Un fundador expone la visión. Un gerente la convierte en tareas concretas. El departamento financiero verifica las suposiciones sobre ingresos y costos, el marketing define la estrategia de posicionamiento, el área legal analiza los riesgos y el equipo de ventas prepara las acciones de acercamiento. Algunas de estas actividades se realizan en secuencia, otras simultáneamente, y algunas quedan bloqueadas hasta que una persona aprueba el siguiente paso.
Según su README, el proyecto es una plataforma para automatizar el trabajo empresarial y apoyar la toma de decisiones, en la cual agentes con roles, personalidades y herramientas distintas se coordinan a través de flujos de trabajo de LangGraph, memoria compartida y sistemas de aprobación con intervención humana (HITL), además de generar informes e integraciones externas. La ambición no es crear otro chatbot, sino un despacho virtual donde los agentes colaboren como lo haría un equipo de startup.
Las cinco capas arquitectónicas
El sistema se divide claramente en cinco capas:
- Frontend: un panel de control de React para la onboarding basada en chat, visualización de flujos de trabajo, aprobaciones y análisis.
- Backend API: puntos de extremo REST de FastAPI, flujos de datos por WebSocket, autenticación, informes y APIs de memoria.
- Capa de agentes: los agentes Cofounder, Manager, Finance, Marketing, Legal, Money y Sales.
- Capa de orquestación: flujos de trabajo de LangGraph junto con un orquestador personalizado, delegación de tareas y control de puntos de verificación.
- Memoria e infraestructura: Neo4j, Qdrant, Redis o Upstash, Supabase y almacenamiento de informes.
Según el README, la pila tecnológica incluye React 18 con Vite, FastAPI, LangGraph además de LangChain y CrewAI para flujos de trabajo de agentes, Neo4j, Qdrant y Redis para la memoria y colas, y Supabase como capa opcional para autenticación y persistencia.
El ciclo de vida general sigue un flujo de arriba hacia abajo, desde la visión del usuario pasando por los agentes líderes hasta los especialistas, y finalmente hacia la memoria compartida, las aprobaciones y los resultados:
User Vision
↓
Cofounder Agent
↓
Manager Agent
↓
Specialist Agents
├── Finance
├── Marketing
├── Legal
├── Money
└── Sales
↓
Shared Memory + Approval Gates
↓
Reports + Dashboard + Integrations
Lo importante que se puede extraer de este diagrama es que el diseño corresponde a un sistema de flujos de trabajo, no a una cadena de prompts. El estado, la memoria, las aprobaciones, los intentos repetidos, la observabilidad y los resultados persistidos son todos aspectos de primera importancia.
El flujo de trabajo en cinco etapas
Etapa 1: convertir una idea vaga en un contexto estructurado
Todo comienza cuando el usuario explica qué desea: un concepto de producto, una idea de negocio o algún objetivo operativo. El Agente Cofundador recibe esta información, que puede ser tan simple como una sola oración:
Input:
"I want to build an AI tool for small businesses."
Su tarea es convertirla en un contexto estructurado con el que el resto del equipo pueda trabajar:
Cofounder Output:
- Vision statement
- Target users
- Problem definition
- Market opportunity
- Strategic assumptions
- Initial business direction
El README denomina a este paso “Recopilación de la visión”. En el backend se puede activar a través de varios puntos de entrada, dependiendo de si el cliente desea un proyecto puntual, una conversación o una sesión ampliada:
POST /api/start-project
POST /api/conversation/start
POST /api/enhanced/start-session
Sea cual sea la ruta utilizada, el backend crea un proyecto o sesión, registra el estado inicial y envía el mensaje al agente adecuado.
Etapa 2: planificación y delegación por parte del Gerente
Una vez que la visión está estructurada, el Agente Gerente toma el control y desglosa la estrategia en tareas que realmente pueden ejecutarse:
Manager Responsibilities:
- Convert vision into roadmap
- Break work into functional domains
- Create agent assignments
- Define task dependencies
- Decide which agents should execute in parallel
En el orquestador personalizado esto se implementa en AgentOrchestrator.start_project(), que se encuentra en backend/flows/orchestrator.py. Este método genera un ID de proyecto, ejecuta primero al Cofounder, pasa el resultado del Cofounder al Gerente y luego activa a los especialistas según las asignaciones del Gerente. En pseudocódigo:
cofounder_result = await Cofounder.execute(vision_task)
manager_result = await Manager.execute(manager_task)
specialist_results = await execute_specialists(manager_result)
generate_outputs(all_results)
El Gerente constituye la capa de control. Sin él, cada especialista trabajaría de forma aislada a partir de la idea inicial y devolvería resultados que no estarían relacionados entre sí. La centralización de la descomposición en un único agente es lo que permite que los resultados de los especialistas formen un plan coherente.
Etapa 3: ejecución paralela de los especialistas
Una vez que existen las tareas asignadas, toman el control los agentes del dominio. El equipo por defecto y sus responsabilidades son:
- Cofundador: visión, estrategia y oportunidades de mercado.
- Gerente: hoja de ruta, descomposición de tareas y delegación.
- Finanzas: modelo de ingresos, modelo de costos, ROI y proyecciones.
- Marceting: posicionamiento, campañas y estrategia de contenido.
- Legal: cumplimiento, riesgos, contratos y verificaciones de políticas.
- Economía: fijación de precios, monetización y operaciones de ingresos.
- Ventas: pipeline, prospección y estrategia de ventas.
Cada agente está definido en backend/agents/personalities.py, y cada definición incluye rasgos, un estilo de comunicación, áreas de especialización y herramientas específicas para su rol. Eso es importante: los agentes se modelan como ejecutores especializados con su propio comportamiento, umbrales de confianza y contexto de tarea, y no simplemente como diferentes instrucciones del sistema.
La ejecución está a cargo de _execute_specialists(), que prepara una tarea por especialista (Finanzas, Marketing, Legal y Dinero, además de Ventas cuando está habilitada). Cada llamada a un agente cuenta con un tiempo de espera de 60 segundos:
parallel_executions = [
asyncio.wait_for(agent.execute(task), timeout=60.0)
for agent_name, task in specialist_tasks
]
Todas esas llamadas envueltas se esperan simultáneamente:
specialist_results = await asyncio.gather(
*parallel_executions,
return_exceptions=True
)
Dado que asyncio.gather() recibe el parámetro return_exceptions=True, un tiempo de espera o fallo en uno de los agentes se devuelve como un objeto de excepción en la lista de resultados en lugar de cancelar todo el lote. La contrapartida es que el código que llama debe inspeccionar cada resultado y decidir si se debe intentar nuevamente, omitir o escalonar al agente que falló. La decisión de diseño general es acertada: cuando el análisis financiero nunca necesita los resultados del marketing, o viceversa, no hay razón para ejecutarlos uno tras otro.
Etapa 4: memoria compartida y propagación de contexto
Un sistema multiagente se degrada rápidamente cuando cada agente solo puede acceder a su propio contexto. La plataforma aborda este problema con una capa de memoria unificada en la que cada almacenamiento tiene una función específica:
Neo4j → graph memory and relationships
Qdrant → vector memory and semantic retrieval
Redis → task queue, cache, runtime coordination
Local data → fallback storage and exported outputs
El README resume esto como memoria de gráfico Neo4j, búsqueda vectorial Qdrant, colas Redis o Upstash, y caché local con fallback adecuado. Cada almacenamiento satisface una necesidad diferente.
Memoria de gráfico: registra las relaciones entre agentes, tareas, proyectos y resultados:
Agent → executed → Task
Task → belongs_to → Project
Agent → produced → Output
Output → depends_on → PriorContext
Esa estructura permite visualizar la colaboración y rastrear con exactitud qué agente produjo qué resultado, y a partir de qué contexto previo.
Memoria vectorial en Qdrant admite recuperación semántica, de modo que un agente puede buscar trabajos anteriores por su significado en lugar de por su ID:
"Find previous market assumptions."
"Retrieve prior financial analysis."
"Use the earlier legal risk summary."
Memoria de colas respaldada por Redis: se encarga de la coordinación en tiempo de ejecución:
- Event streaming
- Task queues
- Cache
- Agent activity updates
- WebSocket event propagation
El proyecto también funciona de manera adecuada cuando faltan servicios. En el desarrollo local, Redis puede ser reemplazado por un adaptador en memoria, y las llamadas a LLM pueden dirigirse a un proveedor simulado. Esto reduce las barreras para ejecutar todo el sistema en una laptop sin tener que configurar todas las dependencias de producción, aunque también significa que las pruebas locales no detectarán problemas que solo aparecen con servicios reales.
Etapa 5: aprobación por un humano
Las acciones de alto impacto no deben ejecutarse de forma automática, y aquí la aprobación humana forma parte del flujo de trabajo principal en lugar de ser algo adicional. Las restricciones se aplican a decisiones que pueden afectar:
- Customer-facing campaigns
- Pricing recommendations
- Legal-sensitive outputs
- CRM updates
- Social media publishing
- Financial projections
- Business-critical recommendations
El README destaca los ganchos de notificación de Slack y los tiempos de espera configurables para estos flujos de aprobación. En el lado de la API, las aprobaciones se exponen a través de endpoints como:
GET /api/approvals/pending
POST /api/approvals/{approval_id}/respond
GET /api/approvals/advanced/pending
GET /api/approvals/stats
El ciclo de vida básico de una aprobación es el siguiente:
Agent generates action
↓
System evaluates confidence/risk
↓
Approval request is created
↓
Frontend or Slack notifies human
↓
Human approves/rejects/provides feedback
↓
Workflow continues or stops
El resultado es un modelo de autonomía por niveles: el trabajo de bajo riesgo se procesa automáticamente, mientras que todo lo relacionado con el cliente, las finanzas o lo sensible desde el punto de vista legal espera una decisión humana. Si está diseñando mecanismos similares, un recorrido relacionado sobre patrones de enrutamiento, distribución y aprobación en LangGraph explica con más detalle las mecánicas a nivel de grafo.
Dentro del backend de FastAPI
El punto de entrada principal del backend, backend/main.py, instancia un conjunto de servicios globales cuando se inicia la aplicación:
AgentOrchestrator
Enhanced Orchestrator
ReportGenerator
SimplePredictor
AgentCollaborator
AdvancedApprovalManager
AgentService
ReportService
LangGraphOrchestrator
Queue Manager
Según el README, cada ruta se monta mediante backend/main.py; backend/api/main.py es un punto de entrada alternativo más ligero que solo monta un subconjunto de rutas. El código está organizado según sus responsabilidades:
backend/
├── main.py # Primary FastAPI app
├── api/ # Route controllers
├── agents/ # Agent implementations and personalities
├── workflows/ # LangGraph and HITL orchestrators
├── flows/ # PRD DAG orchestrator
├── memory/ # Graph, vector, cache managers
├── task_queue/ # Redis/Upstash queue with fallback
├── integrations/ # HubSpot, Slack, Instagram clients
├── approvals/ # Approval managers
├── collaboration/ # Cross-agent communication
├── outputs/ # Report generation
├── analytics/ # Predictions and metrics
├── auth/ # Supabase auth
├── services/ # LLM, agent, report services
└── tools/ # Search and tool registry
Merece la pena destacar la separación entre workflows/ (orquestadores de LangGraph e HITL) y flows/ (el orquestador DAG basado en PRD): el proyecto utiliza dos enfoques de orquestación simultáneamente, lo cual es flexible pero implica que se debe verificar qué ruta utiliza un endpoint determinado.
La superficie de la API, por grupo
Autenticación
POST /api/auth/signup
POST /api/auth/signin
GET /api/auth/user
En modo similar al de producción, estos endpoints dependen de la autenticación de Supabase. En modo local o de demostración, la aplicación puede omitir por completo a Supabase y recurrir a una lógica de desarrollo más ligera. Las opciones de configuración mencionadas en el README incluyen DEMO_MODE, las variables de Supabase y las variables del proveedor de LLM. Los controladores correspondientes son:
signup() → creates user account
signin() → authenticates user
get_current_user()→ verifies token and returns user profile
Ciclo de vida del proyecto
GET /api/projects
POST /api/projects
POST /api/start-project
POST /api/auto-execute
GET /api/auto-execute/status
Estos se corresponden con las siguientes funciones:
get_user_projects() → fetch projects for authenticated user
create_project() → create new project record
start_project() → execute Cofounder → Manager → Specialists workflow
auto_execute_project() → start automated coordination from raw vision
get_auto_execution_status() → return execution progress and logs
start_project() es el núcleo de este grupo. Su secuencia interna es:
1. Generate project_id
2. Execute Cofounder Agent
3. Log Cofounder result
4. Execute Manager Agent with Cofounder context
5. Log Manager result
6. Execute specialist agents in parallel
7. Export and persist final outputs
8. Return project status and timeline
Esa secuencia corresponde directamente a AgentOrchestrator.start_project() y _execute_specialists() en el módulo del orquestador.
Sesiones mejoradas
POST /api/enhanced/start-session
POST /api/enhanced/continue-session
POST /api/enhanced/approve-and-execute
GET /api/enhanced/session-status
GET /api/enhanced/live-logs
GET /api/enhanced/session-results
GET /api/enhanced/system-metrics
POST /api/enhanced/cancel-session
POST /api/enhanced/cleanup-sessions
Cada endpoint tiene un propósito específico:
start-session → create enhanced automation session
continue-session → continue existing multi-turn planning session
approve-and-execute → approve captured vision and run workflow
session-status → inspect session state
live-logs → stream logs for UI monitoring
session-results → return final session output
system-metrics → expose high-level runtime metrics
cancel-session → stop active session
cleanup-sessions → remove old sessions
Este es el enfoque más orientado a la producción, ya que divide la conversación, la aprobación, la ejecución, el monitoreo y la recuperación de resultados en llamadas separadas. Un cliente puede consultar el estado o recibir logs en tiempo real sin mantener una solicitud abierta durante mucho tiempo, y una sesión puede ser cancelada o eliminada de forma explícita.
Gestión de agentes
GET /api/agents/status
GET /api/agents/list
GET /api/agents/personalities
GET /api/agents/configs
POST /api/agents/configs
POST /api/agents/execute
GET /api/agents/logs/live
Qué hace cada ruta:
agents/status → current status of all agents
agents/list → available agent inventory
agents/personalities→ UI-visible personality metadata
agents/configs → current agent runtime settings
update configs → update temperature, approval mode, priority, enabled flag
agents/execute → execute a single agent manually
logs/live → recent agent execution logs
Cuando se llama a /api/agents/list, la lista de agentes regresa ordenada en cuatro categorías (estratégicos, comerciales, operativos y especializados), y los puntos de configuración en tiempo de ejecución permiten al operador cambiar la temperatura, el modo de aprobación, la prioridad y si un agente está habilitado.
Conversaciones
POST /api/conversation/start
POST /api/conversation/{conversation_id}/message
POST /api/conversation/{conversation_id}/approve
Los controladores responsables de ellas:
start_conversation() → starts a Cofounder-led discovery conversation
continue_conversation() → continues the existing conversation with stored context
approve_conversation() → approves the captured vision and starts task distribution
Este flujo existe para que el sistema pueda recopilar suficientes detalles antes de invertir esfuerzos en agentes especializados. Internamente, el proceso se desarrolla de la siguiente manera:
1. User sends initial idea
2. Cofounder Agent asks clarifying questions or structures the vision
3. Conversation state is persisted
4. System detects whether vision is ready for approval
5. User approves
6. System starts agent coordination
En el orquestador, start_conversation() asigna un nuevo ID de conversación, guarda lo que escribió el usuario, llama al Agente Cofounder, persiste la respuesta y devuelve una bandera ready_for_approval que indica al cliente si la visión está lo suficientemente completa como para ser aprobada.
Flujos de trabajo de LangGraph
POST /api/workflow/execute
POST /api/workflow/resume/{thread_id}
Las funciones correspondientes:
execute_langgraph_workflow() → runs a LangGraph-based workflow
resume_workflow() → resumes workflow from checkpoint
Estos puntos de acceso exponen directamente la capa LangGraph. En el README se describe como máquinas de estado de LangGraph que guardan puntos de control de su progreso, pueden corregirse a sí mismas e incluyen nodos de interrupción donde interviene un humano. La capacidad de reanudación es la propiedad clave: cuando un flujo de trabajo de larga duración se pausa a la espera de aprobación o falla a mitad de camino, debe continuar desde su último punto de control en lugar de empezar de nuevo y pagar nuevamente por cada llamada al LLM. Nuestro análisis de cómo almacena LangGraph sus puntos de control mediante InMemorySaver explica qué se persiste realmente en cada paso.
Informes
GET /api/reports/comprehensive
GET /api/reports/{report_type}
POST /api/reports/generate-pdf
GET /api/reports/download/{filename}
GET /api/reports/domains
GET /api/reports/domains/{domain}
Qué produce cada ruta de informe:
comprehensive report → generate full business report
specific report → generate executive, marketing, financial, etc.
generate PDF → convert report data into downloadable PDF
download report → serve generated PDF/HTML
domain reports → return modular reports by business domain
La generación de informes es una característica destacada: informes ejecutivos, de marketing, financieros y completos en formato JSON, con salida en PDF mediante WeasyPrint. Esto es lo que diferencia al sistema de un chatbot, ya que el resultado final es un artefacto empresarial y no un mensaje de chat.
Memoria
GET /api/memory/graph
GET /api/memory/stats
POST /api/memory/export
DELETE /api/memory/clear
Y lo que devuelven:
memory/graph → return graph nodes and edges for visualization
memory/stats → return vector/graph memory statistics
memory/export → export stored memory and outputs
memory/clear → clear memory stores
El README agrupa estos elementos en /api/memory/* para la exportación de gráficos y estadísticas. Con ellos se puede auditar el conocimiento acumulado por los agentes, rastrear sus salidas y ver cuánto almacenamiento utiliza cada backend de memoria. Tenga en cuenta que el endpoint de eliminación es destructivo y merece los mismos controles de acceso que cualquier otra acción administrativa.
Análisis
GET /api/analytics/predictions
GET /api/enhanced/system-metrics
GET /api/communication/stats
Su propósito:
predictions → analyze generated outputs and estimate success/revenue/market timing
system metrics → return enhanced orchestrator metrics
communication stats → return inter-agent communication analytics
Detrás de ellos se encuentran funciones auxiliares simples:
_analyze_project_success()
_analyze_revenue_trend()
_analyze_market_timing()
Estos analizan las salidas de los agentes e identifican indicadores relevantes para el negocio, como la probabilidad de éxito, la dirección del crecimiento de los ingresos y el momento recomendado para actuar. Se trata de heurísticas basadas en texto generado, por lo que su salida debe considerarse indicativa y no como predicciones.
Integraciones
/api/integrations/*
El repositorio enumera HubSpot, Slack y la API de Instagram Business, cada uno con una función específica:
HubSpot → CRM workflows
Slack → HITL approval notifications
Instagram → marketing automation with compliance checks
La idea fundamental es que los agentes deben enviar los resultados a sistemas empresariales reales, y no solo generar contenido, mientras que las barreras de aprobación protegen cualquier información sensible.
WebSockets y transmisión en tiempo real
WS /ws/agent-updates
WS /ws/agent-events
GET /api/stream/logs
Qué contiene cada flujo de datos:
/ws/agent-updates → periodically sends agent status updates
/ws/agent-events → streams queue/Redis events to frontend
/api/stream/logs → streams recent logs via server-sent response
En una interfaz de usuario multiagente, esta visibilidad es esencial. Los operadores necesitan ver qué agente está en ejecución, qué tarea está activa, si hay una aprobación pendiente y dónde se ha interrumpido un flujo de trabajo.
La interfaz frontal de React
El cliente está construido con esta tecnología:
React 18
Vite
React Router
Tailwind CSS
React Flow
Recharts
Según el README, el panel de control combina un flujo de onboarding basado en chat, el estado en tiempo real de los agentes, un mapa visual del flujo de tareas y vistas para verificar el cumplimiento de los PRD. Sus responsabilidades son:
1. Capture the user’s project vision
2. Display agent execution status
3. Visualize task flow
4. Show pending approval requests
5. Display reports and analytics
6. Show memory/monitoring data
7. Connect to WebSocket streams
8. Communicate with FastAPI through api.js
El diseño original es compacto:
frontend/
└── src/
├── App.jsx
├── pages/
├── components/
└── services/api.js
App.jsx funciona como la interfaz autenticada, pages/ alberga las vistas relacionadas con el flujo de trabajo, los análisis y la supervisión, mientras que components/ proporciona los elementos básicos: paneles para el panel de control, pantallas de aprobación, vistas de cumplimiento de PRD y configuraciones de integración. Cada solicitud HTTP pasa por services/api.js, el cual gestiona las reintentos y el caché en un solo lugar, manteniendo los problemas de red fuera de los componentes.
El flujo de extremo a extremo
En conjunto, la ruta principal a través del sistema se desarrolla de la siguiente manera:
1. User submits business vision from React UI
2. Frontend sends request to FastAPI
3. FastAPI creates project/session
4. Cofounder Agent structures vision
5. Manager Agent converts vision into roadmap and assignments
6. Specialist agents execute assigned tasks
7. Results are stored in memory
8. HITL approval is requested where required
9. Reports are generated
10. Frontend displays logs, status, graph, reports, and outputs
Al asociarlo con módulos y métodos reales, el mismo flujo se presenta de esta forma:
React UI
↓ HTTP/WebSocket
FastAPI main.py
↓
AgentOrchestrator / EnhancedOrchestrator
↓
CofounderAgent.execute()
↓
ManagerAgent.execute()
↓
_execute_specialists()
↓
FinanceAgent / MarketingAgent / LegalAgent / MoneyAgent / SalesAgent
↓
MemoryManager + GraphMemory + VectorMemory
↓
ReportGenerator
↓
Dashboard + PDF/HTML/JSON Output
Cada capa tiene una función específica: la interfaz de usuario se encarga de las interacciones, los orquestadores coordinan las acciones, los agentes ejecutan las tareas, los gestores de memoria conservan el contexto y el generador de informes da forma al resultado final.
¿Por qué un orquestador de grafos en lugar de una cadena?
Los flujos de trabajo multiagente necesitan algo más que una serie de llamadas a funciones. Necesitan:
- State transitions
- Conditional routing
- Checkpointing
- Retry behavior
- Human approval interruptions
- Recovery after failure
- Resume from previous state
El README denomina a las máquinas de estado de LangGraph como la capa de orquestación precisamente por estas capacidades. Una simple cadena de instrucciones es lineal:
A → B → C → Done
Un flujo de trabajo empresarial se ramifica según los resultados intermedios:
A → B
├── if finance confidence low → retry Finance
├── if legal risk high → ask human approval
├── if marketing ready → generate campaign
└── if all complete → generate report
Una baja confianza financiera desencadena un intento de nuevo, un alto riesgo legal requiere una revisión humana, y el informe final espera a que todas las ramificaciones estén completas. Codificar esto como llamadas secuenciales hard-coded se convierte rápidamente en un laberinto de condicionales; un grafico con nodos, aristas y puntos de control explícitos mantiene todo inspeccionable y permitiendo reanudar el proceso.
Lo que hace bien el diseño
- Límites claros entre agentes: cada agente gestiona un dominio de negocio específico, lo que mantiene los resultados consistentes y facilita la adición de nuevos roles.
- Orquestación centrada en flujos de trabajo: la ejecución se modela como un flujo de trabajo, y no como una secuencia de respuestas a solicitudes.
- Especialistas en paralelo: los departamentos de Finanzas, Marketing, Legal, Tesorería y Ventas operan simultáneamente donde las dependencias lo permiten, acortando el tiempo total del proceso.
- Memoria compartida: Neo4j, Qdrant, Redis y el almacenamiento local trabajan juntos para gestionar relaciones, recuperación semántica, colas, caché y soluciones de respaldo.
- Seguridad con intervención humana: los controles de aprobación permiten utilizar el sistema para tomar decisiones con consecuencias reales.
- Observabilidad en tiempo real: WebSockets, registros, líneas de tiempo, paneles de control y análisis muestran qué están haciendo los agentes.
Mejoras para su uso en producción
Las bases son sólidas: un backend modular, agentes dedicados, una abstracción de memoria, un flujo de aprobación y una interfaz frontal observable. Los siguientes pasos obvios se refieren a la fiabilidad, seguridad, monitoreo, evaluación y control de costos:
1. Add distributed tracing with OpenTelemetry
2. Add LangSmith or custom LLM evaluation dashboards
3. Add cost tracking per agent and per workflow
4. Add stronger RBAC for users, agents, and approvals
5. Add persistent workflow checkpoints in Postgres or Redis
6. Add retry policies per agent type
7. Add queue-based background execution with Celery/RQ/Arq
8. Add structured output validation with Pydantic schemas
9. Add agent-level unit tests and golden-output evaluation
10. Add Docker production profiles and deployment manifests
Dos de estos puntos merecen especial atención. El seguimiento de costos por agente y por flujo de trabajo es importante porque los especialistas que trabajan en paralelo multiplican las llamadas al LLM, y los costos solo se vuelven visibles una vez que se miden. La validación estructurada de los resultados con esquemas Pydantic es crucial, ya que cada paso posterior, desde las escrituras en memoria hasta los informes y las actualizaciones en CRM, solo es tan fiable como la estructura de los datos que devuelve un agente.
Puntos clave
- Trate la capa de orquestación como el producto principal; el LLM es solo uno de sus componentes.
- Asigne un agente de tipo gestor encargado de la descomposición para que los resultados de los especialistas mantengan coherencia.
- Ejecute agentes independientes de forma concurrente con tiempos de espera por agente, y maneje explícitamente los fallos parciales.
- Asigne a cada almacenamiento de memoria una función específica: gráficos para el rastreo de origen, vectores para la recuperación de información y colas para la coordinación.
Lecturas relacionadas
- Agentes con puertas de aprobación en LangGraph: interrupt(), puntos de control y un almacén — Construya un agente de LangGraph paso a paso: un grafo ReAct explícito, aprobación humana mediante interrupt(), y memoria entre hilos con un almacén, todo ello culminando en un asistente de bandeja de entrada que pregunta primero.
- Enrutamiento, difusión, ReAct, crítica y aprobación: cinco patrones de LangGraph — Aprenda cinco patrones de flujo de trabajo para agentes en LangGraph, desde routers y bucles ReAct hasta puertas de evaluación y aprobación humana, incluyendo las medidas de seguridad que cada uno necesita en entornos de producción.