Seis sistemas. Un agente. Cero punto a punto.

La empresa media tiene entre seis y ocho herramientas de software funcionando en paralelo. CRM, ERP, Slack o Teams, email, calendario, facturación. Cada una hace bien lo suyo. El problema es que ninguna le habla a las demás de forma fiable.

El resultado es el peor escenario posible para cualquier equipo técnico: N herramientas generan N×(N-1)/2 integraciones punto a punto. Con seis sistemas eso son quince webhooks distintos, quince credenciales que mantener y quince lugares donde algo puede fallar silenciosamente mientras todos creen que todo funciona.

Hay un patrón que resuelve esto. No con más webhooks. Con un agente orquestador.

El problema real de las integraciones punto a punto

El patrón típico empieza bien. Una notificación de pago llega desde Stripe y actualiza el CRM. El CRM dispara un webhook que actualiza el ERP. El ERP envía un email. Tres webhooks, todo funciona.

Seis meses después hay doce webhooks. El CRM cambió de versión y el campo customer_id se llama ahora contact_id. El webhook de Stripe lleva semanas fallando silenciosamente porque nadie monitoriza el endpoint de recepción. Y cuando alguien entra a depurar, el problema original es imposible de trazar: ¿en qué paso se rompió la cadena?

Por qué este patrón escala mal

El acoplamiento punto a punto tiene dos propiedades que lo hacen insostenible:

• Fragilidad compuesta: un cambio en cualquier sistema puede romper cualquier integración que depende de él
• Deuda de visibilidad: no hay ningún lugar donde ver qué eventos se procesaron, cuáles fallaron y por qué

No es un problema de tecnología. Es un problema de arquitectura.

El patrón orquestador: una sola entrada, toda la lógica

Un agente IA puede actuar como el middleware inteligente que une todos los sistemas. En lugar de quince integraciones bidireccionales, el diseño tiene tres componentes:

1. Bus de eventos tipados: cada sistema publica eventos con un esquema conocido
2. Agente orquestador: recibe el evento, razona qué acciones ejecutar, llama a las herramientas necesarias
3. Registro de ejecución: qué se ejecutó, con qué datos, cuándo y con qué resultado

La diferencia clave respecto a un middleware clásico (n8n, Zapier, Make) es que el agente puede razonar sobre la intención del evento. Si un contrato nuevo llega pero el cliente ya existe en el CRM con datos distintos, el agente puede decidir qué prevalece en lugar de sobrescribir ciegamente o fallar sin aviso.

Arquitectura mínima viable en TypeScript

// 1. Tipo base para todos los eventos del sistema
interface BusinessEvent {
  id: string;         // UUID — clave para idempotencia
  type: string;       // 'contract.signed' | 'invoice.paid' | 'lead.created'
  timestamp: string;  // ISO 8601
  source: string;     // 'crm' | 'erp' | 'stripe' | 'email'
  payload: Record<string, unknown>;
}

// 2. El agente recibe el evento y decide qué herramientas llamar
async function orchestrate(event: BusinessEvent): Promise<void> {
  const alreadyProcessed = await checkIdempotency(event.id);
  if (alreadyProcessed) return;

  const response = await callOrchestrator(event);

  for (const action of response.actions) {
    await executeWithRetry(action, { maxAttempts: 3 });
  }

  await markEventProcessed(event.id);
}

// 3. Herramientas tipadas — el LLM no llama APIs directamente
const tools = {
  crm:     { createContact, updateDeal, addNote },
  erp:     { createOrder, syncInventory },
  slack:   { notifyChannel, createTask },
  billing: { createInvoice, markPaid },
};

Tres principios hacen que esto no se rompa en producción:

Idempotencia por diseño. Cada evento tiene un id único. Antes de procesar, el agente verifica que no lo ha ejecutado ya. Los reintentos automáticos son seguros.

Herramientas tipadas, nunca APIs crudas. El LLM no llama endpoints directamente. Llama a funciones TypeScript con esquemas validados por Zod. El modelo no puede inventar un campo que no existe.

Estado observable. Cada acción queda registrada con su input, output y timestamp. Cuando algo falla, sabes exactamente dónde, con qué datos y por qué.

El loop de orquestación con Claude

import Anthropic from "@anthropic-ai/sdk";
import { z } from "zod";

const client = new Anthropic();

const CreateContactSchema = z.object({
  email: z.string().email(),
  name:  z.string().min(1),
  source: z.string(),
});

async function runOrchestrator(event: BusinessEvent) {
  const response = await client.messages.create({
    model: "claude-opus-5",
    max_tokens: 1024,
    system: `Eres el orquestador de integraciones de la empresa.
Recibes eventos de negocio y decides qué acciones ejecutar.
Prioridades: 1) no duplicar datos, 2) mantener consistencia, 3) alertar ante ambigüedad.`,
    messages: [{
      role: "user",
      content: `Evento:\n${JSON.stringify(event, null, 2)}\n\n¿Qué acciones ejecuto?`,
    }],
    tools: [{
      name: "create_contact",
      description: "Crea un contacto en el CRM si no existe aún",
      input_schema: {
        type: "object" as const,
        properties: {
          email:  { type: "string" },
          name:   { type: "string" },
          source: { type: "string" },
        },
        required: ["email", "name", "source"],
      },
    }],
  });

  for (const block of response.content) {
    if (block.type !== "tool_use") continue;

    const validated = CreateContactSchema.safeParse(block.input);
    if (!validated.success) {
      await logError(event.id, block.name, validated.error);
      continue;
    }
    await executeWithRetry(() => tools.crm.createContact(validated.data));
  }
}

Este enfoque encaja directamente con lo que explicamos en el artículo sobre tool calling en producción: validación de inputs antes de tocar cualquier API externa, manejo explícito de errores por herramienta y registro de cada llamada.

El error más común al implementarlo solo

El fallo habitual es tratar al agente como un webhook más inteligente. Lo conectan a un endpoint HTTP, procesan el evento, y si falla... no pasa nada. No hay registro, no hay reintento estructurado, no hay alerta.

La producción tiene una tendencia cruel a encontrar exactamente los casos que no probaste: un proveedor cambia el formato de sus eventos, un cliente tiene caracteres especiales en el nombre, el CRM tiene un rate limit que nadie documentó.

En los proyectos de integración IA que construimos en DAILYMP añadimos tres capas que la mayoría omite en la primera versión:

• Cola de eventos durable: si el agente falla, el evento no se pierde
• Registro de ejecución completo: input, output, duración, status por acción
• Alertas por anomalía: si un tipo de evento supera un umbral de fallos, alerta inmediata

Sin estas capas, el sistema funciona el 95% del tiempo y nadie sabe qué ocurre en el 5% restante — que es exactamente donde están los datos críticos que más importa no perder.

Cuándo usar un agente y cuándo un webhook simple

No todo necesita un agente. Un webhook que siempre ejecuta la misma acción sin variación es más barato y más predecible. No añadas complejidad innecesaria.

Usa un agente orquestador cuando:

• La acción que hay que tomar depende del contexto, no solo de los campos del evento
• Hay datos conflictivos que requieren criterio para resolverse
• El mismo evento puede generar distintas acciones según el estado actual del sistema
• Necesitas coordinar más de dos sistemas en una sola operación

Para todo lo demás, un worker simple con validación Zod es suficiente y más mantenible.

Conclusión

Seis sistemas sin integración orquestada son seis sistemas que trabajan en contra los unos de los otros. El patrón de agente orquestador no es sobreingeniería: es la arquitectura que elimina el acoplamiento punto a punto y añade razonamiento donde antes había reglas rígidas que alguien tiene que mantener a mano.

La diferencia entre construirlo bien desde el principio y construirlo rápido se nota a los tres meses, cuando el sistema entra en producción real y aparecen los casos edge que nadie anticipó.

Si estás diseñando la integración ahora y quieres que la arquitectura aguante, cuéntanos qué sistemas tienes y en qué punto estás.

Escríbeme por WhatsApp →