MCPs vs custom workflows: Eligiendo cuánta libertad darle a tus agentes

La distinción fundamental

Enfoque MCP:

Entrada del usuario → Agente decide qué herramientas usar → Agente ejecuta → Salida

Enfoque de workflow personalizado:

Entrada del usuario → Orquestador decide qué ocurre → Agente ejecuta dentro de límites → Salida

Misma entrada, misma salida. Modelo de control completamente diferente.

Cuándo MCP gana

Los MCPs son perfectos para tareas rutinarias de terceros:

• Enviar un mensaje de Slack
• Crear un evento de Google Calendar
• Consultar una base de datos
• Obtener una página web
• Subir a S3

Estas son operaciones sin estado, reversibles, de bajo riesgo. Si el agente decide enviar un mensaje de Slack cuando no debería, lo borras. Sin daño al negocio.

// Estilo MCP: Agente con autonomía total
const tools = [
  slack_send_message,
  google_calendar_create,
  notion_create_page
];

const response = await agent.run({
  prompt: userMessage,
  tools: tools  // Agente decide cuál usar, cuándo, cómo
});

El agente razona sobre qué herramienta encaja. Esto funciona porque:

1. Las herramientas son intercambiables — elección incorrecta = inconveniente menor
2. Las operaciones son idempotentes — pueden reintentarse de forma segura
3. El contexto es autocontenido — la herramienta no necesita estado de negocio

Cuándo los workflows personalizados ganan

Mi sistema de producción maneja sesiones de coaching de IA. Un mensaje de usuario puede necesitar:

1. Validación de seguridad
2. Recuperación de contexto de 30 días de historial
3. Decisión de compresión basada en significancia del mensaje
4. Enrutamiento de tipo de agente (coaching vs. ventas vs. soporte)
5. Generación de respuesta con nivel de intensidad específico
6. Actualización de estado para la siguiente interacción
7. Deducción de créditos basada en tier del usuario

Esto es lógica de negocio. Equivocarse en el paso 4 no solo envía un mal mensaje — rompe el viaje de coaching del usuario.

Así se ve una traza de ejecución real:

{
  "processes_executed": [
    {"name": "001 Main",              "nesting_level": 0},
    {"name": "  003 Extract message", "nesting_level": 1},
    {"name": "  014 Process security", "nesting_level": 1},
    {"name": "  005 Process command", "nesting_level": 1},
    {"name": "  301 Selling process", "nesting_level": 1},
    {"name": "  202 Agent - Coaching", "nesting_level": 1},
    {"name": "    101 AI Execute LLM", "nesting_level": 2},
    {"name": "    021 Send message",  "nesting_level": 2},
    {"name": "      022 Record exchange", "nesting_level": 3},
    {"name": "  901 Cleanup User Lock", "nesting_level": 1}
  ]
}

10 pasos, 3 niveles de anidamiento. El orquestador decidió esta ruta, no el agente. La ejecución del LLM (101 AI Execute LLM) ocurre dentro de un contexto acotado—el Agente de Coaching (202)—después de que la seguridad, el enrutamiento y la lógica de negocio ya se han manejado de forma determinista. El agente solo controló lo que ocurrió dentro de ese nodo: el contenido de la respuesta de coaching.

El espectro de autonomía

MCP Total                                      Orquestación Total
    │                                                      │
    ▼                                                      ▼
┌────────┐    ┌────────┐    ┌────────┐    ┌────────┐    ┌────────┐
│ Agente │    │ Agente │    │ Agente │    │ Agente │    │ Agente │
│elige  │    │elige  │    │elige  │    │elige  │    │ejecuta│
│herram. │    │herram. │    │ de    │    │ dentro │    │  solo  │
│  y     │    │  pero  │    │subconj│    │  del   │    │        │
│paráms. │    │barreras│    │aprobado│   │  flujo │    │        │
└────────┘    └────────┘    └────────┘    └────────┘    └────────┘
   ▲                                                        ▲
   │                                                        │
Chatbots                                           Crítico-negocio
Asistentes                                         Flujos multi-paso

La mayoría de sistemas de producción necesitan algo en el centro-derecha. El hype de MCP empuja a todos hacia la izquierda.

Ejemplo real: por qué no uso MCP para enrutamiento

Imagina darle a un agente MCP estas herramientas:

const tools = [
  route_to_coaching_agent,
  route_to_sales_agent,
  route_to_support_agent,
  send_direct_response
];

El agente necesitaría entender:

• Estado actual del usuario en su viaje
• Reglas de negocio sobre cuándo hacer upsell vs. soporte
• Contexto de 30 días de interacciones
• Prioridades de compresión para la respuesta
• Implicaciones de créditos de cada ruta

Podrías poner todo esto en el prompt. Ahora tu prompt tiene 15,000 tokens y el agente aún toma decisiones de enrutamiento incorrectas el 5% del tiempo. A escala, 5% de rutas incorrectas = experiencias de usuario rotas = churn.

Mi enfoque:

// Paso 1: Agente identifica intención (acotado por prompt específico)
const intent = await routerAgent.execute({
  message: userMessage,
  context: minimalContext,
  // Prompt restringe salida a categorías de intención específicas
  // Sin acceso a herramientas, sin efectos secundarios, solo clasificación
});

// Paso 2: Workflow ramifica determinísticamente basado en intención
// Esto es lógica hardcodeada, no decisión del agente
switch (intent.category) {
  case 'coaching':
    return coachingWorkflow.execute(preparedContext);
  case 'sales':
    return salesWorkflow.execute(preparedContext);
  case 'support':
    return supportWorkflow.execute(preparedContext);
}

El agente router tiene autonomía estrecha: interpretar el mensaje en categorías predefinidas. El workflow tiene autonomía cero: dada la categoría X, siempre ejecutar workflow X.

Esto es autonomía acotada por capas — los agentes operan libremente dentro de su capa, pero no pueden escapar a otras capas.

Contexto y estado: donde MCP falla

Los MCPs son sin estado por diseño. Cada llamada de herramienta es independiente.

La lógica de negocio tiene estado por naturaleza:

{
  "context_management": {
    "user_input": {
      "compression_score": 0.1,
      "compression_priority": "preserve_full",
      "significant_moment_detected": true
    },
    "agent_output": {
      "compression_score": 0.15,
      "context_utilization": "high"
    }
  }
}

Esta decisión de compresión depende de:

• Lo que dijo el usuario (significancia semántica)
• Lo que dijeron la semana pasada (trayectoria de conversación)
• Lo que el agente está por decir (importancia de salida)
• Qué tan cerca estamos de los límites de ventana de contexto

Una herramienta MCP no puede tomar esta decisión. No tiene el estado. Necesitarías pasar el historial completo de conversación a cada llamada de herramienta, luego confiar en que el agente razone sobre la compresión correctamente.

O construyes un workflow que gestiona el estado explícitamente y le da al agente solo lo que necesita.

El patrón híbrido

En la práctica, uso ambos:

┌─────────────────────────────────────────────────────────┐
│                    ORQUESTADOR                           │
│                 (Workflows Personalizados)               │
│                                                          │
│   ┌─────────┐   ┌─────────┐   ┌─────────┐              │
│   │Seguridad│──▶│Enrutam. │──▶│Contexto │              │
│   │ Check   │   │Decisión │   │  Prep   │              │
│   └─────────┘   └─────────┘   └─────────┘              │
│                                     │                    │
│                                     ▼                    │
│                              ┌─────────────┐            │
│                              │   AGENTE    │            │
│                              │  (Acotado)  │            │
│                              │             │            │
│                              │  ┌───────┐  │            │
│                              │  │  MCP  │  │            │
│                              │  │ Tools │  │            │
│                              │  └───────┘  │            │
│                              └─────────────┘            │
│                                     │                    │
│   ┌─────────┐   ┌─────────┐   ┌─────────┐              │
│   │ Estado  │◀──│Registrar│◀──│Respuesta│              │
│   │Actualiz.│   │Exchange │   │  Enviar │              │
│   └─────────┘   └─────────┘   └─────────┘              │
└─────────────────────────────────────────────────────────┘

El orquestador maneja:

• Control de flujo
• Gestión de estado
• Aplicación de reglas de negocio
• Preparación de contexto
• Registro de auditoría

El agente maneja:

• Comprensión de lenguaje natural
• Generación de respuestas
• Uso de herramientas MCP para servicios externos (cuando el orquestador lo permite)

Los MCPs viven dentro de agentes acotados, no como la capa de control.

Así encajan todas las piezas:

• Un sistema multi-agente es un equipo—múltiples especialistas coordinados para lograr objetivos complejos (usando n8n, LangGraph, o similares para interconectar)
• Un Agente es un trabajador especializado dentro de ese equipo
• El LLM es el cerebro bruto—capacidad cognitiva sin dirección
• Técnicas de optimización (prompting, fine-tuning) son la especialización—lo que convierte un cerebro genérico en un coach experto, router, o analista
• CAG (Cache-Augmented Generation) es memoria a largo plazo—conocimiento precargado, siempre disponible
• Workflows internos son los procedimientos de cada trabajador—cómo procesan, validan y reintentan (usando n8n, LangGraph, o frameworks similares)
• RAG (Retrieval-Augmented Generation) son libros de referencia—conocimiento que el agente puede consultar cuando lo necesite
• MCPs son interfaces a herramientas externas compartidas—Slack, APIs, bases de datos que cualquier agente puede usar

Por qué importan los flujos deterministas

El argumento para la orquestación determinista no se trata de desconfianza en los LLMs. Se trata de garantías.

En mi sistema, si la validación de seguridad no se ejecuta, un usuario malicioso podría inyectar prompts. Si el estado no persiste, la siguiente interacción pierde 30 días de contexto. Si el enrutamiento falla, un usuario en crisis recibe un pitch de ventas.

Estos no son escenarios de "ups, reintentar". Son invariantes críticas para el negocio.

Para tareas externas (enviar email, crear evento de calendario), 98% está bien. Para invariantes de negocio, solo 100% es aceptable.

Esto es cierto independientemente de qué herramienta uses para construir el workflow.

Herramientas de workflow: n8n vs LangGraph

Yo uso n8n. Pero LangGraph es igualmente válido para orquestación determinista. Diferentes compromisos:

n8n

Fortalezas:

• Editor visual — miembros no técnicos del equipo pueden entender y modificar flujos
• 400+ integraciones pre-construidas — Telegram, Stripe, bases de datos, APIs listas para usar
• Prototipado rápido — construye flujos complejos en horas, no días
• Self-hosted — control total, sin vendor lock-in, costos predecibles
• CI/CD simplificado — activar workflow = desplegar (CI y CD colapsados en un paso)
• n8n 2.0 — versionado nativo de workflows ahora disponible
• Backups vía API — un workflow puede respaldar todos los demás workflows usando la API de la instancia self-hosted
• Human-in-the-loop fácil — nodos de Telegram/Slack con "esperar respuesta" pausan ejecución hasta que humano responde, opciones de menú incluidas, cero código personalizado
• Depuración visual con modularidad — cuando los workflows están modularizados (sub-workflows), puedes inspeccionar la ejecución de cada módulo independientemente, ver exactamente qué nodo falló, qué datos entraron/salieron, sin leer stack traces

Limitaciones:

• Testing es semi-manual — anclar salidas de nodos, revisar logs de ejecución, pero no suites de tests automatizadas en deploy
• Staging requiere workarounds — duplicar workflows con tags, no ambientes nativos
• Revisión de código es diff visual — no línea por línea como Git

Mejor para: Equipos con miembros técnicos/no técnicos mezclados, MVPs rápidos, workflows pesados en integraciones donde la velocidad de despliegue importa más que la ceremonia CI/CD tradicional.

LangGraph

Fortalezas:

• Python nativo — CI/CD completo, pytest, type checking, revisión de código
• Checkpointing integrado — pausar/reanudar flujos de larga duración programáticamente
• Patrones human-in-the-loop — pasos de aprobación tipados, definidos en código (más control, más setup)
• Gestión de estado — explícita, tipada, versionada
• Testing — unit test de cada nodo, mockear llamadas LLM

Limitaciones:

• Solo código — miembros no técnicos del equipo no pueden participar
• Curva de aprendizaje más pronunciada — conceptos de StateGraph toman tiempo
• Menos integraciones pre-construidas — construyes o usas las de LangChain
• Depuración — stack traces, no inspección visual de flujo

Mejor para: Equipos pesados en ingeniería, máquinas de estado complejas, sistemas que requieren rigor CI/CD.

La evaluación honesta

Mi implementación de n8n funciona en producción. El despliegue es instantáneo — activar y está live. El versionado de n8n 2.0 ayuda con rollbacks. El testing es semi-manual: anclo salidas de nodos, reviso logs de ejecución, ejecuto escenarios. No es pytest, pero tampoco a ciegas. Cuando algo se rompe a las 3am, depuro visualmente — lo cual es en realidad más rápido para problemas de workflow que leer stack traces.

Por qué elegí n8n y aún lo elijo: puedo construir una prueba de concepto funcional en horas, validarla con usuarios reales, luego incrementalmente agregar complejidad hasta que cumpla requisitos de producción. La misma herramienta escala de "experimento rápido" a "sistema crítico de negocio" sin reescribir. Esa velocidad de prototipado se compone con el tiempo.

Si estuviera empezando hoy con un equipo puro de ingeniería demandando suites de tests automatizadas y deploys basados en PR, consideraría seriamente LangGraph.

Si estuviera construyendo con un equipo que incluye no ingenieros que necesitan modificar flujos, o necesitara 50 integraciones funcionando en la semana uno, o valorara iteración rápida de prototipo a producción, n8n sigue siendo la mejor elección.

El costo oculto: economía de tokens

Hay un aspecto de las arquitecturas MCP-first del que nadie habla:consumo de tokens incontrolado.

Cuando le das a un agente autonomía total con 20 herramientas:

Razonamiento del agente: "Déjame pensar qué herramienta usar..."
  → 500 tokens de razonamiento
Agente llama herramienta 1, obtiene resultado
  → 200 tokens procesando resultado
Razonamiento del agente: "Ahora necesito decidir qué sigue..."
  → 400 tokens de razonamiento
Agente llama herramienta 2, obtiene resultado
  → 300 tokens procesando
Razonamiento del agente: "Tal vez también debería verificar..."
  → 600 tokens de razonamiento
... continúa hasta que el agente decide que terminó

Cada paso de razonamiento quema tokens. Cada llamada de herramienta agrega contexto. El agente decide cuándo parar. Recibes la factura al final del mes.

Workflows deterministas: costos predecibles

En mi arquitectura de workflow:

Paso 1: Agente router (prompt acotado, ~2K tokens máx)
Paso 2: Preparación de contexto (código, 0 tokens)
Paso 3: Agente de coaching (prompt acotado, ~8K tokens máx)
Paso 4: Validación de respuesta (código, 0 tokens)
Paso 5: Reintentar si es inválido (máx 2 reintentos, controlado)

Conozco el costo máximo de tokens antes de que comience la ejecución. Puedo establecer límites duros por paso. Si el paso 3 falla la validación, reintento con un prompt modificado—no con "agente, intenta de nuevo como quieras."

Control de cadena de pensamiento

Los MCPs dejan que el agente controle su propia cadena de razonamiento. Los workflows te dejan controlarlo a ti:

Puedes implementar Cadena de Pensamiento semi-estructurada: "Paso 1 produce X, validado por schema Y, pasado a Paso 2 con contexto Z." El razonamiento es guiado, no de forma libre.

Números reales

De mi sistema en producción:

Costo promedio por interacción de coaching: $0.06
Costo máximo (peor caso con reintentos): $0.15
Costo mensual predecible con 10K interacciones: ~$600-800

Si le diera al agente de coaching autonomía total con MCPs para "buscar base de conocimiento", "verificar historial de usuario", "evaluar calidad de respuesta", "reintentar si es necesario"—la misma interacción podría costar $0.30-0.80 dependiendo de cuánto "explore" el agente.

Para ser justos: un agente MCP bien diseñado puede tener límites de tokens, validación de salida y reintentos controlados también. El problema no es MCP técnicamente—es que el ecosistema, tutoriales y patrones por defecto no te empujan hacia restricciones. El camino de menor resistencia es autonomía sin límites. Los workflows te fuerzan a pensar en límites desde el principio.

Marco de decisión

Usa MCP-first cuando:

• Las tareas son rutinarias y reversibles
• Integración de servicios externos (Slack, Calendar, APIs)
• Los errores del agente tienen bajo impacto en el negocio
• Operaciones sin estado
• Quieres prototipado rápido

Usa Workflows Personalizados cuando:

• La lógica de negocio determina el flujo
• El estado debe persistir entre interacciones
• Las decisiones incorrectas tienen consecuencias reales
• Procesos de múltiples pasos con dependencias
• Necesitas registros de auditoría y observabilidad
• La gestión de contexto no es trivial

Usa Híbrido cuando:

• El flujo central es crítico para el negocio (workflow)
• Pero los agentes necesitan acceso a herramientas externas (MCP dentro de alcance acotado)

El error de la industria

La narrativa actual: "Los MCPs dan manos a los agentes de IA. Más herramientas = agentes más capaces."

Los tutoriales de YouTube dicen: "Solo agrega MCPs y tu agente puede hacer todo." Y funciona—en demos, con un usuario, en la máquina del creador.

Luego despliegas a producción con 1,000 usuarios concurrentes.

Los costos de tokens explotan. La latencia se dispara. Los errores se propagan en cascada porque el Agente #847 llamó herramientas en un orden inesperado. No puedes depurar porque cada ruta de ejecución es emergente. No puedes predecir costos porque el razonamiento del agente no tiene límites.

El enfoque de tutorial es arquitectura a escala privada presentada como lista para producción.

Anthropic, OpenAI, Google—están construyendo infraestructura de agentes de propósito general. Su incentivo es adopción, no tu economía unitaria. Tu trabajo es restringirlo para tu negocio específico.

Un agente de coaching con 50 herramientas MCP y autonomía total eventualmente:

• Enrutará usuarios a ventas cuando necesiten soporte
• Sobre-comprimirá contexto crítico
• Saltará verificaciones de cumplimiento requeridas
• Quemará $2 en tokens en una consulta que debería costar $0.06
• Tomará decisiones que optimizan para "completar tarea" sobre bienestar del usuario

No porque el LLM sea malo. Porque le diste libertad sin límites, siguiendo tutoriales diseñados para demos, no para producción.

Los contraargumentos más fuertes

Déjame abordar lo que dirían los defensores de MCP:

"Los LLMs se volverán más inteligentes—eventualmente tomarán decisiones óptimas"

Cierto, pero esto confunde capacidad cognitiva con alineación de reglas de negocio. Un LLM más inteligente entenderá mejor tu contexto, pero aún no sabrá que tu política interna dice "nunca ofrecer descuentos a usuarios de prueba durante los primeros 3 días." Eso no es inteligencia—es conocimiento propietario que cambia cada trimestre.

Además, "más inteligente" no elimina varianza. Pasas de 95% a 98% de decisiones correctas, pero para invariantes de negocio necesitas 100%. La brecha entre 98% y 100% no se cierra con más parámetros.

Y está la economía: GPT-5 será más inteligente pero también más costoso. El problema de consumo de tokens no desaparece—empeora.

"Puedes crear agentes especializados con solo 1-3 herramientas MCP cada uno"

Este es el contraargumento más fuerte porque describe exactamente el patrón híbrido que estoy defendiendo—solo con MCP como la capa de comunicación.

Y aquí MCP tiene una ventaja real: portabilidad. Si mañana migras de Claude a GPT-5 a Gemini, tus interfaces MCP siguen funcionando.

La respuesta honesta: si tu orquestador llama agentes especializados (cada uno con 1-3 herramientas MCP), estás haciendo exactamente lo que este artículo propone—solo usando MCP como protocolo en lugar de llamadas directas. Eso es válido y posiblemente mejor para flexibilidad a largo plazo.

Lo que este artículo no está criticando

Esto no es una crítica de MCP como estándar. El valor de MCP es real: interfaces portables que funcionan a través de proveedores de LLM, definiciones de herramientas estandarizadas, cambio de integración más fácil.

Si estás usando workflows orquestados que llaman agentes especializados, cada uno con 1-3 herramientas MCP, estás haciendo exactamente lo que este artículo recomienda—solo usando MCP como protocolo de comunicación en lugar de llamadas directas. Eso no solo es válido; podría ser lo mejor de ambos mundos.

Lo que estoy criticando es MCP como la arquitectura de control—el patrón de "un agente, 20 herramientas, que lo resuelva." Ahí es donde obtienes consumo de tokens sin límites, rutas de ejecución impredecibles, y la tasa de error del 5% que mata flujos críticos de negocio.

La distinción importa:

El compromiso que estoy haciendo

En interés de la honestidad, hay un costo de los workflows deterministas que no he mencionado:carga de mantenimiento.

Cada cambio de lógica de negocio requiere modificar el orquestador. ¿Nueva regla de enrutamiento? Editar el workflow. ¿Nuevo tier de usuario con comportamiento diferente? Agregar ramas. ¿Cambio de política desde legal? Actualizar nodos.

Con agentes autónomos bien diseñados (apropiadamente acotados), algunos cambios se absorben sin código nuevo. "Ser más conservador con descuentos" podría necesitar solo un ajuste de prompt, no reestructurar el workflow.

Acepto este compromiso porque:

1. Mi lógica de negocio cambia menos frecuentemente de lo que se ejecuta. Modificar un workflow una vez para manejar 10,000 ejecuciones correctas vale la pena.
2. Cuando la lógica cambia, quiero control explícito. Un ajuste de prompt que "absorbe" un cambio de política podría también absorberlo incorrectamente en casos extremos que no consideré.
3. Depurar lógica explícita es más fácil que depurar comportamiento emergente. Cuando algo se rompe después de un cambio de prompt, descubrir qué cambió es más difícil que revisar un diff de nodos.

Pero si tu lógica de negocio cambia diariamente y tienes frameworks de evaluación fuertes para detectar regresiones de prompt, el cálculo podría ser diferente. Esto es un compromiso, no una verdad universal.

Cuándo migrar: n8n → LangGraph

Ya que recomendé ambas herramientas, la pregunta natural es: ¿cuándo deberías cambiar?

Quédate con n8n si:

• Tu equipo incluye no ingenieros que modifican workflows
• Aún estás iterando en lógica de negocio semanalmente
• La depuración visual te ahorra más tiempo del que ahorrarían tests automatizados
• Tus integraciones son mayormente pre-construidas (Telegram, Slack, bases de datos)

Considera migrar a LangGraph cuando:

• Tus workflows son estables y raramente cambian de estructura
• Necesitas revisiones basadas en PR por razones de cumplimiento/auditoría
• Tu equipo es 100% ingenieros cómodos con Python
• Estás alcanzando los límites de n8n en gestión de estado compleja
• Quieres hacer open-source de tu lógica de agente

Enfoque híbrido:

Puedes usar ambos. n8n para orquestación pesada en integraciones (webhooks, APIs, notificaciones), LangGraph para internos complejos de agentes (máquinas de estado, lógica de reintento sofisticada). No son mutuamente excluyentes.

Conclusión

Los MCPs son una herramienta, no una arquitectura. Son excelentes para lo que están diseñados: conectar LLMs a servicios externos.

Son terribles para lo que implica el hype: reemplazar la orquestación cuidadosa de workflows críticos para el negocio.

Dale manos a tus agentes. Pero mantenlos con correa.