🏢 Org graph × work graph

Dois grafos convivem no mesmo sistema de agentes, e eles nao sao o mesmo grafo. O org graph e a estrutura que fica: agentes de vida longa com papeis nomeados — pesquisador, escritor, validador, publicador — cada um dono de um dominio, com memoria acumulada e arestas estaveis que so mudam quando voce redeploya o sistema.

Pense nele como o organograma da empresa, so que cada caixa e um agente rodando o proprio loop. O org graph responde "quem existe e o que cada um faz" — nao "o que estamos fazendo agora". Essa segunda pergunta e outro grafo, que voce ve no proximo topico.

O que olhar: a divisoria pontilhada no meio nao separa dois sistemas — separa duas perspectivas do mesmo sistema. Repare que "pesquisador" e "validador" aparecem dos dois lados: sao os mesmos agentes. A esquerda, voce ve todas as relacoes possiveis entre eles (o organograma). A direita, voce ve so o caminho fino que esta tarefa de hoje realmente percorreu — um subconjunto, montado na hora.

O work graph e efemero: montado pra uma tarefa especifica e descartado depois. Ele muda a cada execucao — hoje pede pesquisador e validador, amanha pede so o escritor, depois pede os quatro em fila. Nao existe "o" work graph do sistema; existe um work graph novo pra cada pedido que chega.

Zone defense e o padrao que faz o org graph valer a pena: cada agente dono de um dominio, com contexto persistente. O de seguranca cuida de autenticacao, permissoes e logs de auditoria. O de dados cuida de esquema, migracoes e padroes de query. O de API cuida de endpoints, limites de taxa e contratos. O de frontend cuida de componentes, estado e padroes de interface.

Cada um roda o proprio loop dentro da zona. Um pedido de uma zona pra outra passa pelo work graph — nunca direto. Nenhum agente vaza pro contexto do outro. E isso que faz o agente de vida longa acumular valor de verdade: um agente de seguranca que ja revisou 300 mudancas conhece o modelo de ameaca daquele codigo de forma implicita, sem precisar reexplicar nada a cada pedido.

Fan-out e abrir uma tarefa em N ramos que rodam ao mesmo tempo. Fan-in e juntar os N resultados de volta num so. E o movimento que um loop simplesmente nao faz, por ser sequencial de forma — um loop processa uma coisa de cada vez, sempre.

A juncao e onde mora o perigo. Um merge malfeito engole um ramo em silencio, e o resultado parece completo mesmo faltando pedaco. Por isso toda juncao precisa conferir cardinalidade: recebi os N que despachei?

O que olhar: quatro ramos pulsando chegam limpos na juncao; o quinto, marcado com X vermelho, nunca chega. Se a juncao nao contar quantos ramos despachou versus quantos recebeu, ela vai aceitar "recebi 4 de 5" como se fosse um resultado completo. Isso e o merge que engole uma fonte — o resultado parece pronto e ninguem percebe que faltou um pedaco.

No roteamento por condicao, a aresta escolhe o destino a partir do resultado do no anterior. E o mecanismo que faz o work graph "decidir" sem um agente ter que interpretar tudo de novo a cada passo. O exemplo classico e o suporte ao cliente.

Complexidade baixa vai pra base de respostas prontas (FAQ). Complexidade media vai pro agente de IA. Complexidade alta ou arriscada escalona direto pro humano. Existem ainda a aresta de "nao resolveu" (devolve pro proximo nivel) e a aresta de aprendizado (volta pro classificador com o feedback).

Modelo roteando o que um if resolve e caro, lento e nao determinístico. A divisao que funciona: codigo controla o roteamento previsivel; modelo cuida dos passos que exigem interpretacao ou julgamento. Cada aresta que voce consegue transformar em regra escrita e uma aresta que para de custar token e de variar entre execucoes.

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