🏢 Grafo organizacional × grafo de trabajo

Dos grafos conviven en el mismo sistema de agentes, y no son el mismo grafo. El org graph y es la estructura que permanece: agentes de larga duración con roles definidos —investigador, escritor, validador, publicador—, cada uno a cargo de un dominio, con memoria acumulada y aristas estables que solo cambian cuando tú vuelve a desplegar el sistema.

Piensa en él como el organigrama de la empresa, solo que cada cuadro es un agente que ejecuta su propio loop. El org graph responde «quién existe y qué hace cada uno», no «qué estamos haciendo ahora». Esa segunda pregunta corresponde a otro grafo, que verás en el próximo tema.

Qué observar: la línea divisoria punteada del medio no separa dos sistemas: separa dos perspectivas del mismo sistema. Fíjate en que «investigador» y «validador» aparecen en ambos lados: son los mismos agentes. A la izquierda, ves todas las relaciones posibles entre ellos (el organigrama). A la derecha, ves solo el recorrido específico que esta tarea de hoy realmente siguió: un subconjunto, armado en el momento.

O work graph y es efímero: se arma para una tarea específica y se descarta después. Cambia con cada ejecución: hoy pide investigador y validador, mañana solo pide al escritor y después pide a los cuatro en fila. No existe «el» work graph del sistema; existe un work graph nuevo para cada solicitud que llega.

Zone defense y es el patrón que hace que el org graph valga la pena: cada agente está a cargo de un dominio, con contexto persistente. El de seguridad se ocupa de la autenticación, los permisos y los registros de auditoría. El de datos se ocupa del esquema, las migraciones y los patrones de consulta. El de API se ocupa de los endpoints, los límites de tasa y los contratos. El de frontend se ocupa de los componentes, el estado y los patrones de interfaz.

Cada uno ejecuta su propio loop dentro de la zona. Una solicitud de una zona a otra pasa por el work graph — nunca directamente. Ningún agente se filtra al contexto del otro. Eso es lo que hace que el agente de larga duración acumule valor de verdad: un agente de seguridad que ya revisó 300 cambios conoce implícitamente el modelo de amenazas de ese código, sin necesidad de volver a explicarlo en cada solicitud.

Fan-out y abrir una tarea en N ramas que se ejecutan al mismo tiempo. Fan-in y reunir los N resultados en uno solo. Es algo que un loop simplemente no hace, porque su forma es secuencial: un loop procesa una cosa a la vez, siempre.

La unión es donde reside el peligro. Una fusión mal hecha se traga una rama en silencio, y el resultado parece completo aunque le falte una parte. Por eso, toda unión necesita comprobar cardinalidad: ¿recibí los N que despaché?

Qué observar: cuatro ramas pulsantes llegan limpias a la unión; la quinta, marcada con una X roja, nunca llega. Si la unión no cuenta cuántas ramas se enviaron y cuántas se recibieron, aceptará «recibí 4 de 5» como si fuera un resultado completo. Eso es la combinación que se traga una fuente — el resultado parece listo y nadie se da cuenta de que falta una parte.

En el enrutamiento por condición, la arista elige el destino según el resultado del nodo anterior. Es el mecanismo que hace que el work graph «decida» sin que un agente tenga que interpretar todo de nuevo en cada paso. El ejemplo clásico es el soporte al cliente.

La complejidad baja va a la base de respuestas preparadas (FAQ). La complejidad media va al agente de IA. La complejidad alta o arriesgada se escala directamente al humano. También están la arista «no lo resolvió» (devuelve al siguiente nivel) y la arista de aprendizaje (vuelve al clasificador con los comentarios).

El modelo enruta lo que un if resolverlo es caro, lento y no determinista. La división que funciona: el código controla el enrutamiento predecible; el modelo se encarga de los pasos que requieren interpretación o criterio. Cada arista que puedas convertir en una regla escrita es una arista que deja de costar tokens y de variar entre ejecuciones.

// 1) O grafo de roteamento: cada aresta tem uma condicao explicita
const roteador = {
  "classificacao": [
    { "para": "faq",         "quando": "complexidade == 'baixa'" },
    { "para": "agente_ia",   "quando": "complexidade == 'media'" },
    { "para": "humano",      "quando": "complexidade == 'alta' || risco == 'alto'" }
  ],
  "faq":        [ { "para": "agente_ia", "quando": "resolvido == false" } ],
  "agente_ia":  [ { "para": "humano",    "quando": "resolvido == false" } ],
  "humano":     [ { "para": "classificacao", "quando": "feedback_dado == true", "tipo": "aprendizado" } ]
};

// 2) Juncao com checagem de cardinalidade (fan-in de N tickets em lote)
function fanIn(despachados, recebidos) {
  if (recebidos.length !== despachados.length) {
    throw new Error(`cardinalidade nao bate: recebi ${recebidos.length} de ${despachados.length}`);
  }
  return recebidos;
}

// 3) Rota um ticket de exemplo
function roteia(no, ctx) {
  const arestas = roteador[no] || [];
  for (const a of arestas) {
    // avaliacao simplificada da condicao 'quando' contra o contexto
    if (eval(a.quando.replace(/complexidade/g, `'${ctx.complexidade}'`).replace(/risco/g, `'${ctx.risco}'`).replace(/resolvido/g, ctx.resolvido).replace(/feedback_dado/g, ctx.feedback_dado))) {
      return a.para;
    }
  }
  return null; // nenhuma condicao casou -- pedido some, ver "como verificar"
}

console.log(roteia("classificacao", { complexidade: "media", risco: "baixo" })); // "agente_ia"