🏢 Org graph × work graph

Two graphs coexist in the same agent system, and they are not the same graph. The org graph is the lasting structure: long-lived agents with named roles —researcher, writer, validator, publisher—each owning a domain, with accumulated memory and stable edges that change only when you redeploys the system.

Think of it as the company org chart, except each box is an agent running its own loop. The org graph answers “who exists and what each one does” — not “what are we doing now?” That second question belongs to another graph, which you’ll see in the next topic.

What to look at: the dotted divider in the middle doesn’t separate two systems—it separates two perspectives of the same system. Notice that “researcher” and “validator” appear on both sides: they’re the same agents. On the left, you see all the possible relationships between them (the org chart). On the right, you see only the narrow path that today’s task actually followed—a subset assembled on the fly.

O work graph is ephemeral: assembled for a specific task and discarded afterward. It changes with each run—today it calls for a researcher and validator, tomorrow just the writer, then all four in a row. There’s no “the” work graph for the system; there’s a new work graph for every incoming request.

Zone defense is the pattern that makes an org graph worthwhile: each agent owns a domain, with persistent context. The security agent handles authentication, permissions, and audit logs. The data agent handles schemas, migrations, and query standards. The API agent handles endpoints, rate limits, and contracts. The frontend agent handles components, state, and interface standards.

Each one runs its own loop within the zone. A request from one zone to another goes through the work graph—never directly. No agent leaks into another’s context. That’s what makes a long-lived agent accumulate real value: a security agent that has already reviewed 300 changes implicitly knows that code’s threat model, without needing anything re-explained with each request.

Fan-out is to open a task into N branches that run at the same time. Fan-in is to bring the N results back together into one. It’s something a loop simply doesn’t do, since a loop is sequential by nature—it processes one thing at a time, always.

The join is where the danger lies. A faulty merge silently swallows a branch, and the result looks complete even when something is missing. That’s why every join needs to check cardinality: did I receive the N I dispatched?

What to look at: four pulsing branches arrive cleanly at the join; the fifth, marked with a red X, never arrives. If the join doesn’t count how many branches it dispatched versus how many it received, it will accept “I received 4 of 5” as if it were a complete result. This is the merge that swallows a source — the result looks ready, and no one notices a piece is missing.

With conditional routing, the edge chooses the destination based on the previous node's result. It's the mechanism that lets the work graph “decide” without an agent having to interpret everything again at each step. The classic example is customer support.

Low complexity goes to the canned response base (FAQ). Medium complexity goes to the AI agent. High or risky complexity escalates directly to a human. There is also a "not resolved" edge (returns to the next level) and a learning edge (returns to the classifier with feedback).

Model routing what one if resolve is expensive, slow, and nondeterministic. The division that works: code controls predictable routing; the model handles steps that require interpretation or judgment. Every edge you can turn into a written rule is an edge that stops costing tokens and varying between runs.

// 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"