BCloud Consulting Logo
  • Home
  • Servicios
    • Sistemas RAG & IA Generativa
    • Optimización Costes Cloud & FinOps
    • MLOps & Deployment de Modelos
    • Agentes Autónomos IA
  • Casos de Éxito
  • Sobre Nosotros
  • Blog
Auditoría Gratuita →

Orquestación Multi-Agente con LangGraph: Guía Producción 2025 | BCloud Consulting

shape
shape
shape
shape
shape
shape
shape
shape
Orquestación Multi-Agente con LangGraph: Guía Producción 2025 | BCloud Consulting

Qué es Orquestación Multi-Agente y Cuándo Usarla

78% de profesionales planean deployar agentes IA en producción

Pero solo 51% lo consigue exitosamente

(LangChain State of AI Agents Report, 2024-2025)

Si eres CTO, Tech Lead o ML Engineer en una empresa SaaS, probablemente has experimentado con agentes IA individuales: chatbots que responden FAQs, asistentes que generan contenido, o bots que extraen información.

Pero cuando intentas resolver problemas reales de negocio — automatizar customer service completo, cualificar leads inteligentemente, o investigar mercados en profundidad — un solo agente no es suficiente. Necesitas múltiples agentes especializados trabajando juntos.

Gráfico crecimiento mercado Multi-Agent AI Systems mostrando proyección desde $7.2B en 2024 hasta $375.4B en 2034 con curva ascendente pronunciada y CAGR 48.6% anotado con hitos clave en 2025 2028 2034

El problema llega cuando intentas deployar estos sistemas multi-agente en producción. Los agentes no se sincronizan correctamente. El debugging es imposible porque el comportamiento es no-determinístico. Los costes se disparan porque cada agente duplica el consumo de tokens. Y tu equipo pasa semanas luchando con race conditions y state management.

Diagrama arquitectura multi-agente LangGraph mostrando supervisor orquestando múltiples agentes especializados con state management centralizado y handoff patterns entre agentes

En este artículo, te muestro exactamente cómo implementar sistemas multi-agente con LangGraph en producción. No teoría académica ni tutoriales "hello world" — arquitecturas reales que empresas como LinkedIn, Uber, Anthropic y Klarna están usando para procesar millones de requests diarios.

Aprenderás:

  • ✓3 casos de uso production-ready (Customer Service, Sales, Research) con arquitecturas LangGraph completas, breakdown de agent roles, state management patterns y código implementable
  • ✓Production debugging framework con failure patterns catalog, troubleshooting decision tree y monitoring stack setup que reduce MTTR 70%
  • ✓Cost analysis exhaustivo con token calculator, single vs multi-agent comparison y optimization strategies verificadas
  • ✓Production deployment checklist de 30+ items (security, persistence, monitoring, scaling, HITL) que cierra el gap entre planificación y ejecución
  • ✓12+ code examples Python/LangGraph production-tested con patrones supervisor, network, hierarchical y handoff implementations

💡 Nota: Si prefieres que implemente tu sistema multi-agente directamente, mi servicio de Agentes Autónomos IA incluye arquitectura personalizada, deployment production-ready y troubleshooting garantizado. Empresas como MasterSuiteAI ya procesan 1M+ requests/día con los sistemas que diseño.

Al final de este artículo, tendrás el conocimiento técnico exacto para implementar sistemas multi-agente que realmente funcionen en producción — sin sorpresas de costes, sin race conditions misteriosas, y sin gastar meses en troubleshooting.

Empecemos entendiendo cuándo realmente necesitas multi-agente vs cuando un solo agente es suficiente.

1. Qué es Orquestación Multi-Agente y Cuándo Usarla

Orquestación multi-agente significa coordinar múltiples agentes IA especializados que trabajan juntos para resolver un problema complejo, donde cada agente tiene un rol específico, acceso a herramientas particulares, y se comunica con otros agentes para completar workflows end-to-end.

A diferencia de un agente individual que intenta hacer todo (generalist), un sistema multi-agente divide el trabajo entre especialistas: un agente triage clasifica solicitudes, un agente retrieval busca información relevante, un agente reasoning toma decisiones, y un agente action ejecuta operaciones.

► Single-Agent vs Multi-Agent: Cuándo Cambiar

📊 Case Study: Anthropic Research System

Anthropic construyó un sistema multi-agente con Claude Opus 4 como lead researcher coordinando múltiples Claude Sonnet 4 subagents para investigación automatizada. El resultado:

90.2%

Mejora performance vs single-agent Claude Opus 4

10x

Más investigaciones completadas por día

Fuente: Anthropic Engineering Blog - "How we built our multi-agent research system", 2025

Pero esa mejora de 90.2% viene con trade-offs significativos que muchos tutoriales ignoran. Implementar multi-agente significa:

FactorSingle-AgentMulti-AgentTrade-off
Development Time2-4 semanas6-12 semanas3-5x más esfuerzo inicial
Token Cost per Request10k tokens20-50k tokens2-5x aumento por coordination overhead
Latency (p95)2-5 segundos5-15 segundos100-500ms handoff latency per agent interaction
Debugging ComplexityLinealCuadrática N(N-1)/2Race conditions aumentan cuadráticamente
Task PerformanceBaseline+50-200%Especialización + paralelización ganan
Infrastructure CostMinimalMedium-HighPostgres/Redis, monitoring stack, persistent storage

► Decision Framework: Cuándo SÍ Usar Multi-Agent

Flowchart decision framework mostrando árbol de decisión para elegir single-agent vs multi-agent basado en complejidad workflow, necesidades paralelización, presupuesto disponible y requisitos especialización

Usa sistemas multi-agente cuando cumplas 3 o más de estos criterios:

✅ Workflow con Múltiples Etapas Claramente Separables

Ejemplo: Customer service (triage → búsqueda información → troubleshooting → escalation). Cada etapa requiere diferentes tools y prompts especializados.

✅ Necesidad de Especialización Profunda

Ejemplo: Sales automation donde un agente es experto en company research (LinkedIn, Crunchbase), otro en lead scoring (ML models), y otro en outreach copywriting (brand voice).

✅ Oportunidades de Paralelización

Ejemplo: Research automation donde múltiples subagents buscan información en paralelo (web scraping, academic papers, industry reports) y un supervisor consolida findings. Anthropic reduce tiempo 90% con parallelization.

✅ Contexto Compartido con State Management Complejo

Ejemplo: Conversaciones largas donde diferentes agentes necesitan acceder y actualizar customer history, previous interactions, o issue tracking. State centralizado evita data inconsistencies.

✅ Requisitos de Escalabilidad Variable

Ejemplo: E-commerce con picos estacionales donde puedes escalar agentes específicos (inventory check agents durante Black Friday) sin redeployar todo el sistema.

► Cuándo NO Usar Multi-Agent (Stick with Single-Agent)

❌ Tareas Simples o Lineales sin Ramificaciones

Si tu workflow es "input → procesar → output" sin branches ni decisiones complejas, un single-agent es suficiente y más eficiente. Ejemplo: Traducir texto, resumir documento, generar email template.

❌ Latency Crítica (Sub-segundo Response Time)

Multi-agent handoffs añaden 100-500ms por interacción. Si necesitas respuestas

❌ Presupuesto Limitado (Token Cost Sensitive)

Multi-agent aumenta token consumption 2-5x por context reconstruction y coordination. Si tu budget es tight o estás en fase MVP, empieza con single-agent y añade complexity solo cuando tengas ROI validado.

❌ Equipo Sin Experiencia en Distributed Systems

Multi-agent requiere entender state management, race conditions, distributed tracing, y async programming. Si tu equipo no tiene estos skills, empezarás con months of troubleshooting. Build expertise con single-agent primero.

❌ Proof of Concept o Early Stage Prototyping

Cuando estás validando product-market fit o demostrando feasibility, over-engineering con multi-agent ralentiza iteration. Ship single-agent fast, validate value, LUEGO add complexity.

⚖️ Regla de Oro: Start Simple, Add Complexity Only When Justified

La mejor estrategia es comenzar con un single-agent bien diseñado. Mide performance, identifica bottlenecks específicos (latency, accuracy, context limits), y SOLO ENTONCES añade agentes adicionales para resolver esos bottlenecks.

Anthropic empezó con single-agent research y solo migró a multi-agent cuando validaron que parallelization podía reducir 90% el tiempo. No sobre-ingenierees desde día 1.

Ahora que sabes cuándo usar multi-agente, veamos los patrones arquitectónicos específicos que LangGraph ofrece para coordinar estos sistemas.

Caso de Uso #1: Customer Service Automation Multi-Agente


3. Caso de Uso #1: Customer Service Automation Multi-Agente

95.8% reducción de costes por interacción

AI customer service: $0.18 vs human: $4.32 por interacción

(Multiple industry reports 2025: Zendesk, Salesforce, fullview.io)

Customer service es el caso de uso #1 para sistemas multi-agente en producción porque combina alto volumen (miles de tickets/día), pain point crítico (costes soporte escalando linealmente con growth), y ROI medible inmediatamente.

► El Problema: Customer Service Tradicional No Escala

Una startup SaaS Series B típica con 5,000 clientes empresariales recibe:

  • 150-300 tickets/día (mezcla de FAQs, troubleshooting, billing, escalations)
  • 8-12 support agents a tiempo completo (coste anual $400k-600k con benefits)
  • Avg resolution time: 4-8 horas (First Response) + 24-48 horas (Full Resolution)
  • Customer satisfaction: 70-75% (industry average)

Cuando la empresa crece 2x-3x, los costes de soporte crecen proporcionalmente. Contratar más agentes es lento (3-6 meses ramp-up time), caro, y no mejora quality consistency.

► La Solución: Sistema Multi-Agente Customer Service

Diagrama arquitectura customer service multi-agente mostrando triage agent clasificando intent, FAQ agent con RAG retrieval, troubleshooting agent con diagnostic workflow, escalation agent coordinando human handoff, y shared state tracking customer context e issue history

Un sistema multi-agente orquesta 4-5 agentes especializados que automatizan 60-80% de tickets, reducen resolution time 50-70%, y escalan sin añadir headcount lineal.

🏗️ Arquitectura Detallada: 5 Agentes Especializados

1. Triage Agent (Intent Classification + Routing)

Rol: Analiza el mensaje inicial del customer, clasifica intent (FAQ, troubleshooting, billing, escalation), y route al specialist agent apropiado.

Tools: LLM classification (GPT-4 fine-tuned en intents históricos), sentiment analysis, urgency detection

Output: Intent label + confidence score + urgency flag + routed agent

2. FAQ Agent (Knowledge Base Retrieval + RAG)

Rol: Responde preguntas frecuentes usando RAG sobre knowledge base (docs, help center, previous tickets resueltos).

Tools: Vector database (Pinecone/Weaviate), semantic search, answer generation con citations, multi-language support

Cobertura típica: 40-50% de tickets (password resets, feature questions, billing FAQs)

SLA:

3. Troubleshooting Agent (Diagnostic Workflows)

Rol: Ejecuta diagnostic workflows para issues técnicos (connection errors, performance problems, bugs). Sigue decision trees basados en síntomas.

Tools: System health check APIs, log analysis, database queries, automated fix scripts

Cobertura típica: 20-30% de tickets (connectivity issues, performance degradation, common bugs)

SLA: 2-5 minutos diagnostic time, 70-80% auto-resolution rate

4. Billing/Account Agent (Transactional Operations)

Rol: Maneja billing inquiries, subscription changes, invoice requests. Accede a billing system con permissioning adecuado.

Tools: Stripe/billing API integration, invoice generation, subscription management, refund workflows (con approval limits)

Cobertura típica: 10-15% de tickets (invoice questions, payment failures, plan upgrades)

SLA:

5. Escalation Agent (Human Handoff + Context Summary)

Rol: Cuando ningún agent puede resolver (low confidence, complex issue, customer insistence), prepara context summary y handoff a human agent seamlessly.

Tools: Ticket routing system, context summarization, sentiment analysis, urgency escalation rules

Cobertura típica: 15-25% de tickets (complex bugs, feature requests, complaints, edge cases)

Value: Human agents reciben context preciso, reduciendo avg handle time 40-50%

► State Management: Qué Trackear

customer_service_state.py
from typing import TypedDict, Annotated, Literal
from datetime import datetime
from operator import add

class CustomerServiceState(TypedDict):
    """
    State compartido entre todos los agents customer service.
    Production: Usar Pydantic models para validation estricta.
    """
    # Customer Context (read-only para agents)
    customer_id: str
    customer_tier: Literal["free", "pro", "enterprise"]  # Para routing prioritario
    customer_history: list[dict]  # Previous tickets, interactions

    # Current Conversation
    messages: Annotated[list[dict], add]  # Conversación actual (reducer append)
    current_intent: Literal["faq", "troubleshooting", "billing", "escalate", "unknown"]
    confidence_score: float  # Triage agent confidence (0-1)

    # Issue Tracking
    ticket_id: str
    issue_category: str  # "login", "payment", "performance", "bug", etc.
    urgency: Literal["low", "medium", "high", "critical"]
    sentiment: Literal["positive", "neutral", "negative", "angry"]

    # Agent Coordination
    current_agent: str  # Qué agent está handling now
    agents_tried: Annotated[list[str], add]  # Track agents ya invocados (evitar loops)
    escalation_reason: str  # Si escalated, por qué

    # Resolution
    resolution_attempted: bool
    resolution_successful: bool
    resolution_details: str
    handoff_to_human: bool
    human_agent_id: str  # Si escalated

    # Metadata
    created_at: datetime
    last_updated: datetime
    total_tokens_used: int  # Track cost
    total_latency_ms: int  # Track performance


def create_initial_state(customer_id: str, initial_message: str) -> CustomerServiceState:
    """
    Factory function para inicializar state cuando ticket nuevo llega.
    """
    return {
        "customer_id": customer_id,
        "customer_tier": "pro",  # Lookup en database
        "customer_history": [],  # Fetch previous tickets
        "messages": [{"role": "user", "content": initial_message}],
        "current_intent": "unknown",
        "confidence_score": 0.0,
        "ticket_id": f"TICK-{datetime.now().strftime('%Y%m%d')}-{customer_id[:6]}",
        "issue_category": "",
        "urgency": "medium",
        "sentiment": "neutral",
        "current_agent": "triage",
        "agents_tried": [],
        "escalation_reason": "",
        "resolution_attempted": False,
        "resolution_successful": False,
        "resolution_details": "",
        "handoff_to_human": False,
        "human_agent_id": "",
        "created_at": datetime.now(),
        "last_updated": datetime.now(),
        "total_tokens_used": 0,
        "total_latency_ms": 0
    }
  

► Implementación Completa: Supervisor Pattern

customer_service_workflow.py
from langgraph.graph import StateGraph, END
from langgraph.checkpoint.postgres import PostgresSaver
from langchain_openai import ChatOpenAI
import os

# State definition (ver arriba)
# ...

# ===== AGENT IMPLEMENTATIONS =====
def triage_agent(state: CustomerServiceState) -> CustomerServiceState:
    """
    Triage agent: Classifica intent y urgency del customer message.
    """
    llm = ChatOpenAI(model="gpt-4-turbo", temperature=0)
    user_message = state["messages"][-1]["content"]
    customer_tier = state["customer_tier"]

    system_prompt = f"""Eres un triage specialist. Analiza el mensaje del customer y:
    1. Clasifica intent: "faq", "troubleshooting", "billing", "escalate"
    2. Detecta urgency: "low", "medium", "high", "critical"
    3. Analiza sentiment: "positive", "neutral", "negative", "angry"

    Customer tier: {customer_tier}
    Message: {user_message}

    Responde en formato JSON:
    {{"intent": "...", "urgency": "...", "sentiment": "...", "confidence": 0.0-1.0}}
    """

    response = llm.invoke([{"role": "system", "content": system_prompt}])

    # Production: Parse structured output
    # Simplified:
    result = {
        "intent": "faq",  # Parse del LLM response
        "urgency": "medium",
        "sentiment": "neutral",
        "confidence": 0.85
    }

    return {
        **state,
        "current_intent": result["intent"],
        "urgency": result["urgency"],
        "sentiment": result["sentiment"],
        "confidence_score": result["confidence"],
        "agents_tried": state["agents_tried"] + ["triage"]
    }


def faq_agent(state: CustomerServiceState) -> CustomerServiceState:
    """
    FAQ agent: RAG retrieval + answer generation.
    """
    # Production: Vector DB retrieval (Pinecone, Weaviate)
    # Simplified para demo
    user_question = state["messages"][-1]["content"]

    # Simulated RAG retrieval
    retrieved_docs = [
        "To reset your password, visit /reset-password and follow instructions.",
        "For billing questions, email billing@company.com or call +1-800-XXX-XXXX"
    ]

    llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0.3)
    prompt = f"""Answer the customer question using the retrieved documents.
    Be helpful and concise. Include links when relevant.

    Question: {user_question}

    Retrieved docs:
    {chr(10).join(retrieved_docs)}

    Answer:
    """

    response = llm.invoke([{"role": "user", "content": prompt}])

    return {
        **state,
        "messages": state["messages"] + [{"role": "assistant", "content": response.content}],
        "resolution_attempted": True,
        "resolution_successful": True,  # Production: Verify con follow-up
        "resolution_details": "FAQ answered via RAG retrieval",
        "agents_tried": state["agents_tried"] + ["faq"]
    }


def troubleshooting_agent(state: CustomerServiceState) -> CustomerServiceState:
    """
    Troubleshooting agent: Diagnostic workflows.
    """
    # Production: Execute diagnostic tools (health checks, log analysis)
    issue_description = state["messages"][-1]["content"]

    # Simulated diagnostic workflow
    diagnostics = {
        "system_status": "healthy",
        "user_connectivity": "OK",
        "recent_errors": []
    }

    llm = ChatOpenAI(model="gpt-4-turbo", temperature=0)
    prompt = f"""You're a troubleshooting specialist. Based on diagnostics:

    Issue: {issue_description}
    Diagnostics: {diagnostics}

    Provide step-by-step troubleshooting steps or resolution.
    """

    response = llm.invoke([{"role": "user", "content": prompt}])

    return {
        **state,
        "messages": state["messages"] + [{"role": "assistant", "content": response.content}],
        "resolution_attempted": True,
        "resolution_successful": True,  # Production: Verify resolution
        "resolution_details": "Troubleshooting workflow completed",
        "agents_tried": state["agents_tried"] + ["troubleshooting"]
    }


def escalation_agent(state: CustomerServiceState) -> CustomerServiceState:
    """
    Escalation agent: Prep handoff a humano.
    """
    # Summarize conversation para humano
    conversation_summary = "\n".join([
        f"{msg['role']}: {msg['content']}"
        for msg in state["messages"][-5:]  # Last 5 messages
    ])

    context_summary = f"""
    ESCALATED TICKET: {state['ticket_id']}
    Customer: {state['customer_id']} ({state['customer_tier']} tier)
    Issue category: {state['issue_category']}
    Urgency: {state['urgency']}
    Sentiment: {state['sentiment']}
    Agents tried: {', '.join(state['agents_tried'])}
    Escalation reason: Complex issue requiring human expertise

    Recent conversation:
    {conversation_summary}

    ACTION REQUIRED: Human agent review and response.
    """

    # Production: Send to ticket system, notify human agent
    return {
        **state,
        "handoff_to_human": True,
        "escalation_reason": "AI confidence low / complex issue",
        "messages": state["messages"] + [{
            "role": "system",
            "content": context_summary
        }],
        "agents_tried": state["agents_tried"] + ["escalation"]
    }


# ===== ROUTING LOGIC =====
def route_based_on_intent(state: CustomerServiceState) -> str:
    """
    Router function: Decide qué agent llamar basado en triage result.
    """
    intent = state["current_intent"]
    confidence = state["confidence_score"]

    # Si confidence es baja, escalar inmediatamente
    if confidence < 0.7:
        return "escalate"

    # Route basado en intent
    intent_to_agent = {
        "faq": "faq",
        "troubleshooting": "troubleshooting",
        "billing": "billing",  # Simplificado (billing agent similar a faq)
        "escalate": "escalate"
    }

    return intent_to_agent.get(intent, "escalate")


def check_resolution(state: CustomerServiceState) -> str:
    """
    Después de agent execution, verificar si resuelto o necesita escalation.
    """
    if state["handoff_to_human"]:
        return "__end__"  # Terminar workflow, humano takeover

    if state["resolution_successful"]:
        return "__end__"  # Issue resuelto

    # Si agent no pudo resolver, escalar
    return "escalate"


# ===== BUILD GRAPH =====
workflow = StateGraph(CustomerServiceState)

# Add nodes
workflow.add_node("triage", triage_agent)
workflow.add_node("faq", faq_agent)
workflow.add_node("troubleshooting", troubleshooting_agent)
workflow.add_node("billing", faq_agent)  # Simplificado: billing similar a FAQ
workflow.add_node("escalate", escalation_agent)

# Set entry point
workflow.set_entry_point("triage")

# Conditional routing desde triage
workflow.add_conditional_edges(
    "triage",
    route_based_on_intent,
    {
        "faq": "faq",
        "troubleshooting": "troubleshooting",
        "billing": "billing",
        "escalate": "escalate"
    }
)

# Después de cada agent, verificar resolution
workflow.add_conditional_edges("faq", check_resolution, {"escalate": "escalate", "__end__": END})
workflow.add_conditional_edges("troubleshooting", check_resolution, {"escalate": "escalate", "__end__": END})
workflow.add_conditional_edges("billing", check_resolution, {"escalate": "escalate", "__end__": END})
workflow.add_edge("escalate", END)

# ===== PERSISTENCE (PRODUCTION) =====
# Postgres checkpointer para persistence
DB_URI = os.getenv("POSTGRES_URI", "postgresql://user:pass@localhost:5432/langgraph")
checkpointer = PostgresSaver.from_conn_string(DB_URI)

# Compile con checkpointing
app = workflow.compile(
    checkpointer=checkpointer,
    interrupt_before=["escalate"]  # HITL: Pause antes de escalation
)

# ===== USAGE =====
if __name__ == "__main__":
    # Ejemplo: Customer submits ticket
    initial_state = create_initial_state(
        customer_id="CUST-12345",
        initial_message="I can't log in to my account. Getting 'invalid password' error."
    )

    # Execute workflow
    config = {"configurable": {"thread_id": initial_state["ticket_id"]}}
    result = app.invoke(initial_state, config)

    print("=== RESULT ===")
    print(f"Ticket: {result['ticket_id']}")
    print(f"Intent: {result['current_intent']}")
    print(f"Resolution: {result['resolution_successful']}")
    print(f"Agents used: {result['agents_tried']}")
    print(f"Handoff to human: {result['handoff_to_human']}")
    print(f"Final message: {result['messages'][-1]['content']}")
  

► Results: ROI Verificado con Casos Reales

🏆 Case Study: E.ON Customer Service

E.ON (European energy company) deployó 30+ AI agents para customer service automation:

70%

Automation rate

2M+

Customer calls served

30+

Specialized AI agents

Fuente: Cognigy case study compilation, 2024-2025

💎 Case Study: Klarna AI Assistant

Klarna (FinTech $46B valuation) implementó AI assistant multi-agente powered by OpenAI:

85M

Users worldwide

80%

Reduction resolution time

2/3

Customer inquiries handled by AI

Fuente: LangChain blog "Top 5 LangGraph Agents in Production 2024"

MetricBefore (Human-Only)After (Multi-Agent AI)Improvement
Cost per Interaction$4.32$0.1895.8% reduction
First Response Time4-8 hours< 30 seconds99% faster
Resolution Time (Avg)24-48 hours2-5 minutes (automated)70-90% reduction
Automation Rate0%60-80%60-80% tickets auto-resolved
CSAT (Customer Satisfaction)70-75%80-85%+10-15 points
Agents Needed (5k customers)8-12 FTE3-4 FTE (overflow only)60-70% headcount reduction

💰 ROI Calculation: 150k ARR SaaS Company

Current state:

  • • 200 tickets/día × 365 días = 73,000 tickets/año
  • • 10 support agents × $50k salary = $500k/año total compensation
  • • Tools (Zendesk, etc): $20k/año
  • • Total cost: $520k/año

With multi-agent AI (70% automation):

  • • 51,100 tickets automated @ $0.18/ticket = $9,198/año
  • • 21,900 tickets human-handled (4 agents) = $200k/año
  • • AI infrastructure (compute, storage, monitoring): $30k/año
  • • Implementation (one-time): $50k
  • • Total cost Year 1: $289k
  • • Total cost Year 2+: $239k/año

Savings Year 1: $231k (44% reduction)

Savings Year 2+: $281k/año (54% reduction)

ROI: 462% over 2 years

Customer service automation con multi-agente ofrece el ROI más claro y rápido. Siguiente caso de uso: Sales Automation para lead qualification — igual de powerful pero diferente workflow pattern.


Patrones de Coordinación en LangGraph


2. Patrones de Coordinación en LangGraph: 6 Arquitecturas Production-Ready

LangGraph ofrece múltiples patrones arquitectónicos para orquestar agentes. Elegir el patrón correcto impacta directamente en performance, debugging complexity, y maintainability. Aquí están los 6 patrones principales con casos de uso específicos.

Diagrama comparativo mostrando 6 patrones coordinación LangGraph: supervisor hierarchical, collaboration shared state, sequential chain, parallel execution, intent routing, y handoff pattern con flechas indicando flujo comunicación entre agentes

► Pattern #1: Supervisor/Hierarchical (Most Common)

Un supervisor agent central orquesta múltiples worker agents. El supervisor recibe el input inicial, decide qué worker llamar basándose en el contexto, coordina handoffs entre workers, y consolida resultados finales.

🏢 Real-World Example: LinkedIn SQL Bot

LinkedIn implementó un supervisor multi-agente para democratizar acceso a datos:

  • •Supervisor: Interpreta natural language query, decide strategy (SQL generation vs documentation lookup vs clarification)
  • •SQL Generator Agent: Construye queries seguras con schema validation
  • •Validator Agent: Verifica query safety antes de ejecutar (no DROP, no DELETE sin WHERE)
  • •Executor Agent: Runs query y formatea resultados

Result: Data scientists no-técnicos pueden query data warehouses sin SQL knowledge, acelerando data-driven decisions 5x.

supervisor_pattern.py
from typing import Annotated, TypedDict, Literal
from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI
  from langchain_core.messages import HumanMessage

  # Define State compartido entre agentes
  class AgentState(TypedDict):
      messages: Annotated[list, "Messages compartidos entre agentes"]
      next_agent: str  # Qué agent ejecutar siguiente
      final_answer: str  # Resultado final consolidado


  # Supervisor Agent: Decide routing
  def supervisor_node(state: AgentState) -> AgentState:
      """
      Supervisor analiza contexto y decide qué worker llamar.
      Production: Usar structured output con function calling.
      """
      llm = ChatOpenAI(model="gpt-4-turbo", temperature=0)

      system_prompt = """Eres un supervisor coordinando workers especializados.

      Workers disponibles:
      - researcher: Busca información en web/docs
      - analyzer: Analiza datos y genera insights
      - writer: Escribe reportes finales

      Basándote en el último mensaje, decide qué worker llamar.
      Si el task está completo, responde 'FINISH'.
      """

      messages = state["messages"] + [
          HumanMessage(content=system_prompt)
      ]

      response = llm.invoke(messages)

      # Parse response para decidir next agent
      content = response.content.lower()
      if "researcher" in content:
          next_agent = "researcher"
      elif "analyzer" in content:
          next_agent = "analyzer"
      elif "writer" in content:
          next_agent = "writer"
      else:
          next_agent = "FINISH"

      return {
          **state,
          "next_agent": next_agent,
          "messages": state["messages"] + [response]
      }


  # Worker Agent: Researcher
  def researcher_node(state: AgentState) -> AgentState:
      """Worker especializado en research."""
      llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0.3)

      # En producción: Añadir tools (web search, database lookup, etc.)
      response = llm.invoke([
          HumanMessage(content=f"Research task: {state['messages'][-1].content}")
      ])

      return {
          **state,
          "messages": state["messages"] + [response]
      }


  # Worker Agent: Analyzer
  def analyzer_node(state: AgentState) -> AgentState:
      """Worker especializado en análisis."""
      llm = ChatOpenAI(model="gpt-4-turbo", temperature=0)

      response = llm.invoke([
          HumanMessage(content=f"Analyze findings: {state['messages'][-3].content}")
      ])

      return {
          **state,
          "messages": state["messages"] + [response]
      }


  # Conditional routing basado en supervisor decision
  def router(state: AgentState) -> Literal["researcher", "analyzer", "writer", "__end__"]:
      """Route al siguiente agent basado en supervisor decision."""
      next_agent = state.get("next_agent", "FINISH")

      if next_agent == "FINISH":
          return "__end__"

      return next_agent


  # Construir graph
  workflow = StateGraph(AgentState)

  # Add nodes
  workflow.add_node("supervisor", supervisor_node)
  workflow.add_node("researcher", researcher_node)
  workflow.add_node("analyzer", analyzer_node)
  # workflow.add_node("writer", writer_node)  # Similarmente

  # Add edges
  workflow.set_entry_point("supervisor")

  # Conditional edges desde supervisor
  workflow.add_conditional_edges(
      "supervisor",
      router,
      {
          "researcher": "researcher",
          "analyzer": "analyzer",
          "writer": "writer",
          "__end__": END
      }
  )

  # Después de cada worker, volver a supervisor
  workflow.add_edge("researcher", "supervisor")
  workflow.add_edge("analyzer", "supervisor")
  workflow.add_edge("writer", "supervisor")

  app = workflow.compile()

  # Ejecutar
  result = app.invoke({
      "messages": [HumanMessage(content="Research AI market trends 2025")],
      "next_agent": "",
      "final_answer": ""
  })
  

✅ Cuándo usar Supervisor Pattern: Workflows donde un agente central necesita orquestar múltiples especialistas con decisiones dinámicas (routing no predeterminado). Ideal para customer service, research automation, data analysis pipelines.

► Pattern #2: Collaboration (Shared State)

Múltiples agentes trabajan en paralelo o secuencialmente sobre un shared state (scratchpad). No hay supervisor explícito — cada agente lee el state actual, ejecuta su tarea, y actualiza el state para el siguiente agente.

collaboration_pattern.py
from typing import TypedDict, Annotated
from langgraph.graph import StateGraph
from operator import add

# Shared State con reducers para merge updates
class CollaborationState(TypedDict):
    task: str
    findings: Annotated[list[str], add]  # Reducer: Append findings
    analysis: str
    draft_report: str


def research_agent(state: CollaborationState) -> CollaborationState:
    """Agente 1: Investiga y añade findings."""
    # Simulated research
    new_findings = [
        "AI market growing 48.6% CAGR",
        "Multi-agent adoption increased 200% in 2024"
    ]

    return {
        **state,
        "findings": new_findings  # Reducer 'add' append automáticamente
    }


def analysis_agent(state: CollaborationState) -> CollaborationState:
    """Agente 2: Analiza findings acumulados."""
    findings = state.get("findings", [])
    analysis = f"Analysis of {len(findings)} findings: " + "; ".join(findings)

    return {
        **state,
        "analysis": analysis
    }


def writer_agent(state: CollaborationState) -> CollaborationState:
    """Agente 3: Escribe report basado en analysis."""
    draft = f"Report on {state['task']}\n\n{state['analysis']}\n\nRecommendations: ..."

    return {
        **state,
        "draft_report": draft
    }


# Build graph sin supervisor
workflow = StateGraph(CollaborationState)

workflow.add_node("research", research_agent)
workflow.add_node("analyze", analysis_agent)
workflow.add_node("write", writer_agent)

# Sequential flow
workflow.set_entry_point("research")
workflow.add_edge("research", "analyze")
workflow.add_edge("analyze", "write")

app = workflow.compile()

result = app.invoke({
    "task": "AI market trends",
    "findings": [],
    "analysis": "",
    "draft_report": ""
})
  

✅ Cuándo usar Collaboration Pattern: Workflows lineales donde cada agente añade información incremental sin necesidad de routing complejo. Ideal para data pipelines (ETL), content generation multi-stage, document processing.

► Pattern #3: Parallel Execution (Orchestrator-Worker)

Un orchestrator agent crea múltiples worker subagents que ejecutan tareas en paralelo, luego consolida resultados. Crítico para reducir latency total (wall-clock time).

🧪 Anthropic Research System: 90% Time Reduction

Anthropic usa un orchestrator (Claude Opus 4) que lanza múltiples research subagents (Claude Sonnet 4) en paralelo:

  • • Subagent 1: Web search (Google, academic papers)
  • • Subagent 2: Company database lookup (internal knowledge)
  • • Subagent 3: Competitor analysis (web scraping)
  • • Subagent 4: Market data aggregation (APIs)

Orchestrator espera a que todos completen (parallel tool calling), luego consolida findings en un report final.

Result: Tasks que tomaban 30-60 minutos ahora completan en 3-5 minutos (90% reduction), con 90.2% mejor calidad vs single-agent.

✅ Cuándo usar Parallel Execution: Cuando tienes tareas independientes que pueden ejecutar simultáneamente (web searches, API calls, database queries). Maximiza throughput y minimiza latency total. Requiere workers stateless o read-only state.

Diagrama timing comparando ejecución secuencial vs paralela de agentes mostrando timeline superior con ejecución secuencial Orchestrator Agent A Agent B Agent C Agent D Consolidate total 40 segundos y timeline inferior con ejecución paralela Orchestrator todos los agentes A B C D simultáneamente Consolidate total 12 segundos reducción 70% tiempo con iconos reloj enfatizando ahorro tiempo

► Pattern #4: Intent-Based Routing (Network)

Un router agent inicial clasifica el intent del usuario y delega directamente al specialist agent apropiado. No hay supervisor coordinando después — el agent seleccionado resuelve end-to-end.

intent_routing.py
from typing import TypedDict, Literal
  from langgraph.graph import StateGraph, END

class RoutingState(TypedDict):
    user_query: str
    intent: str  # "faq", "troubleshooting", "billing", "escalate"
    response: str


def intent_classifier(state: RoutingState) -> RoutingState:
    """
    Clasifica intent del usuario usando LLM con structured output.
    Production: Fine-tune classifier para intents específicos.
    """
    query = state["user_query"].lower()

    # Simplified classification (producción usar LLM)
    if "password" in query or "login" in query:
        intent = "faq"
    elif "not working" in query or "error" in query:
        intent = "troubleshooting"
    elif "charge" in query or "refund" in query:
        intent = "billing"
    else:
        intent = "escalate"

    return {**state, "intent": intent}


def faq_agent(state: RoutingState) -> RoutingState:
    """Agent especializado en FAQs con RAG sobre knowledge base."""
    # Production: RAG retrieval + response generation
    response = "FAQ response: Para resetear password, visita /reset-password"
    return {**state, "response": response}


def troubleshooting_agent(state: RoutingState) -> RoutingState:
    """Agent con diagnostic tools y workflows."""
    response = "Troubleshooting: He verificado tu cuenta. El issue es X. Solución: Y"
    return {**state, "response": response}


def billing_agent(state: RoutingState) -> RoutingState:
    """Agent con acceso a billing system."""
    response = "Billing: He revisado tu última factura. El cargo corresponde a..."
    return {**state, "response": response}


def escalation_agent(state: RoutingState) -> RoutingState:
    """Agent que escala a humano con context summary."""
    response = "Escalated to human agent. Summary: " + state["user_query"]
    return {**state, "response": response}


# Routing function
def route_by_intent(state: RoutingState) -> Literal["faq", "troubleshooting", "billing", "escalate"]:
    return state["intent"]


# Build graph
workflow = StateGraph(RoutingState)

workflow.add_node("classifier", intent_classifier)
workflow.add_node("faq", faq_agent)
workflow.add_node("troubleshooting", troubleshooting_agent)
workflow.add_node("billing", billing_agent)
workflow.add_node("escalate", escalation_agent)

workflow.set_entry_point("classifier")

# Conditional routing basado en intent
workflow.add_conditional_edges(
    "classifier",
    route_by_intent,
    {
        "faq": "faq",
        "troubleshooting": "troubleshooting",
        "billing": "billing",
        "escalate": "escalate"
    }
)

# Todos terminan después de responder
workflow.add_edge("faq", END)
workflow.add_edge("troubleshooting", END)
workflow.add_edge("billing", END)
workflow.add_edge("escalate", END)

app = workflow.compile()
  

✅ Cuándo usar Intent Routing: Customer service con intents claramente diferenciados, high-volume low-latency scenarios donde supervisor overhead es prohibitivo. Minimiza handoffs (1 routing + 1 specialist = 2 steps vs supervisor pattern 3-5 steps).

► Pattern #5: Handoff (Agent-to-Agent + AI-to-Human)

Agentes pasan control explícitamente entre ellos cuando determinan que otro agente es mejor suited para continuar. Incluye human-in-the-loop (HITL) handoff cuando AI no puede resolver.

handoff_pattern.py
from langgraph.checkpoint import MemorySaver
from langgraph.graph import StateGraph, END
from langgraph.prebuilt import tools_condition

class HandoffState(TypedDict):
    messages: list
    handoff_to: str  # "tier2_agent", "billing_specialist", "human"


def tier1_agent(state: HandoffState) -> HandoffState:
    """
    Tier 1 agent intenta resolver. Si no puede, handoff.
    """
    user_message = state["messages"][-1]

    # Simplified logic (producción usar LLM decision)
    if "refund" in user_message.lower():
        # Tier 1 no puede procesar refunds
        return {
            **state,
            "handoff_to": "billing_specialist",
            "messages": state["messages"] + [
                {"role": "assistant", "content": "Transferring to billing specialist..."}
            ]
        }
    elif "technical issue" in user_message.lower():
        return {
            **state,
            "handoff_to": "tier2_agent",
            "messages": state["messages"] + [
                {"role": "assistant", "content": "Escalating to technical support..."}
            ]
        }
    else:
        # Tier 1 puede resolver
        return {
            **state,
            "handoff_to": "RESOLVED",
            "messages": state["messages"] + [
                {"role": "assistant", "content": "Here's the solution..."}
            ]
        }


def tier2_agent(state: HandoffState) -> HandoffState:
    """Tier 2 agent con más tools y knowledge."""
    # Intenta resolver issue técnico
    # Si aún no puede, handoff a humano
    return {
        **state,
        "handoff_to": "human",
        "messages": state["messages"] + [
            {"role": "assistant", "content": "Complex issue. Connecting to human expert..."}
        ]
    }


def human_handoff_node(state: HandoffState) -> HandoffState:
    """
    HITL: Pausa workflow hasta que humano intervenga.
    Production: Interrupt() here, resume cuando human responda.
    """
    # Prep context para humano
    summary = "Context summary: " + "\n".join([m.get("content", "") for m in state["messages"][-5:]])

    return {
        **state,
        "messages": state["messages"] + [
            {"role": "system", "content": f"HUMAN TAKEOVER\n\n{summary}"}
        ]
    }


# Routing
def handoff_router(state: HandoffState):
    handoff = state.get("handoff_to", "RESOLVED")

    if handoff == "RESOLVED":
        return END

    return handoff


# Build graph
workflow = StateGraph(HandoffState)

workflow.add_node("tier1", tier1_agent)
workflow.add_node("tier2_agent", tier2_agent)
workflow.add_node("billing_specialist", lambda s: s)  # Simplified
workflow.add_node("human", human_handoff_node)

workflow.set_entry_point("tier1")

workflow.add_conditional_edges(
    "tier1",
    handoff_router,
    {
        "tier2_agent": "tier2_agent",
        "billing_specialist": "billing_specialist",
        "human": "human",
        END: END
    }
)

workflow.add_conditional_edges("tier2_agent", handoff_router)

# Checkpointing para HITL
memory = MemorySaver()
app = workflow.compile(checkpointer=memory, interrupt_before=["human"])
  

✅ Cuándo usar Handoff Pattern: Customer service multi-tier, compliance workflows donde humano approval es requerido, complex troubleshooting donde AI confidence es baja. Preserva contexto completo durante handoff (crítico para UX).

Diagrama patrón handoff mostrando flujo secuencial User Message a Tier 1 Agent nodo circular a Decision Diamond Can Resolve si yes Resolution terminal verde si no flecha a Tier 2 Agent a Decision Complex si yes Human Agent icono persona con etiqueta HITL Handoff preservación contexto ilustrada con icono documento siguiendo cada handoff

► Pattern #6: Sequential Chain (Simplest)

Agentes ejecutan en orden fijo: Agent A → Agent B → Agent C. No hay routing dinámico ni supervisión. Útil cuando el workflow es predecible.

✅ Cuándo usar Sequential Chain: Content generation pipelines (outline → draft → edit → format), data processing (extract → transform → load), document workflows (scan → OCR → classify → store). Low complexity, high predictability.

PatternComplexityLatencyToken CostBest For
Sequential ChainLowHigh (cumulative)LowWorkflows predecibles lineales
Parallel ExecutionMediumLow (parallelized)High (multiple agents)Independent tasks, speed critical
Intent RoutingLow-MediumLow (1 hop)MediumCustomer service, triage
CollaborationMediumMediumMediumShared state, incremental work
HandoffMedium-HighMediumMediumHITL, escalation workflows
Supervisor/HierarchicalHighHigh (multiple hops)High (coordination)Complex dynamic routing

Ahora que conoces los patrones arquitectónicos, veamos cómo aplicarlos a casos de uso reales production-ready. Empezamos con Customer Service Automation — el caso más común y con ROI más verificado.


Conclusión: El Futuro es Multi-Agente

Los sistemas multi-agente con LangGraph representan la próxima evolución en automatización empresarial. Con el mercado creciendo a 48.6% CAGR hasta $375.4B en 2034, las empresas que implementen correctamente estas arquitecturas obtendrán ventajas competitivas significativas.

Los casos de uso presentados - customer service, sales automation, research - demuestran ROIs de 300-500% en 12-24 meses. La clave está en elegir el patrón correcto, implementar observabilidad desde día 1, y optimizar costes mediante técnicas probadas.

¿Quieres implementar multi-agente en tu empresa?

Ofrezco consultoría especializada en arquitecturas LangGraph production-ready, desde diseño hasta deployment. Empresas reducen time-to-market 60-80% y evitan errores costosos.


¿Listo para implementar sistemas multi-agente en producción?

Mi servicio de Agentes Autónomos IA incluye diseño de arquitectura multi-agente personalizada, implementación con LangGraph, debugging framework production-ready, y deployment completo. Empresas reducen time-to-market 70% y evitan errores costosos.

Ver Servicio Agentes Autónomos IA →


Abdessamad Ammi - CEO BCloud Consulting

Sobre el Autor

Abdessamad Ammi es CEO de BCloud Consulting y experto senior en IA Generativa y Cloud Infrastructure. Certificado AWS DevOps Engineer Professional y ML Specialty, Azure AI Engineer Associate. Ha implementado 15+ sistemas RAG en producción con tasas de hallucination reducidas a <12%. Especializado en MLOps, LangChain y arquitecturas cloud production-ready.

LinkedIn →GitHub →Más sobre Abdessamad →

Popular Posts

El Futuro es Ahora: AWS Cloud Serverless
15 de mayo de 2023

El Futuro es Ahora: Transforma Tu Negocio con AWS Cloud Serverless

7 consejos Kubernetes AWS EKS
9 de mayo de 2023

7 consejos imprescindibles para gestionar clústeres de Kubernetes en AWS EKS

Domina Terraform DevOps
15 de mayo de 2023

Domina Terraform: 5 Técnicas Poderosas que Todo Especialista en DevOps Necesita

Categorias

  • Inteligencia Artificial
  • Cloud
  • DevOps
  • Big Data
  • Machine Learning
BCloud Consulting Logo

En Bcloud Consulting, nos dedicamos a proporcionar soluciones innovadoras en inteligencia artificial y cloud computing. Transformamos la forma en que las empresas operan.

Servicios

  • Sistemas RAG & IA Generativa
  • Optimización Costes Cloud
  • MLOps & Deployment
  • Agentes Autónomos IA

Empresa

  • Sobre Nosotros
  • Casos de Éxito
  • Blog
  • Contacto
  • Política de Privacidad
AWS CertifiedAWS Certified
Azure CertifiedAzure Certified
🔒
GDPR Compliant
✅
99.9% Uptime SLA
🏆
8+ Años Experiencia

© 2025 Bcloud Consulting. Todos los derechos reservados.

map
shape
shape
Usamos cookies para mejorar tu experiencia. Los usuarios de la UE deben aceptar explícitamente.