Orquestração multi-agent: cinco padrões e quando um vence

Uma empresa portuguesa escreve sobre a fatura FT-2026-0918. O e-mail diz que o IVA parece errado e anexa a fatura: líquido EUR 248,00, IVA cobrado a 21 %, EUR 52,08, total EUR 300,08.

Os fatos necessários para responder estão em três lugares, e só um deles está no e-mail:

Junte os três e a fatura está errada: com reverse charge aplicado, o IVA deveria ter sido zero, e é devida uma nota de crédito de EUR 52,08. Olhe só para a fatura e ela está aritmeticamente perfeita — 248,00 mais 52,08 é 300,08 — e você dirá isso.

O e-mail de fato afirma "somos uma empresa portuguesa". Isso é uma alegação, não um registro, e nenhum sistema de faturamento emite uma nota de crédito com base em uma alegação. A armadilha não é um truque: é o formato comum do trabalho de negócios, em que a decisão precisa de um fato que ninguém pensou em buscar.

Tudo acima roda contra um provedor roteirizado no estilo do Capítulo 23, com exatamente uma regra:

Uma resposta só pode usar um fato que esteja em seu prompt.

O "modelo" pede cada ferramenta que tem, uma vez, na ordem do catálogo, e então aplica uma regra fixa ao texto que consegue ver. Nada é roteirizado por arranjo, então as diferenças naquela tabela de abertura não são afirmações sobre inteligência do modelo: são roteamento de informação, medido. Um modelo real acrescenta suas próprias falhas por cima; ele não remove estas.

Os cinco nomes abaixo são da Anthropic, de Building effective agents, que foi onde esse vocabulário se estabilizou.¹ Nenhuma das cinco ideias é nova, e dizer qual casa deu nome a quê — e qual ideia é mais antiga — é metade do valor de conhecê-las.

/* 1. Prompt chaining: a fixed pipeline. The control flow is yours. */
export async function chain(steps: Step[], first: string) {
  let carry = first, all = first;
  for (const s of steps) {
    const r = await step(s.role, s.system, s.accumulate ? all : carry);   
    carry = r.text;
    all = `${all}\n${r.text}`;
  }
  return carry;
}

/* 2. Routing: one cheap call picks the branch. The fallback is not a model. */
export async function route<T>(input: string, classify: Classifier,
                               routes: Record<string, Branch<T>>, fallback: Branch<T>) {
  let label: string | undefined;
  try { label = await classify(input); } catch { label = undefined; }
  return ((label && routes[label]) || fallback)(input);                    
}

/* 3. Parallelisation. The pattern IS this line. */
export const parallel = <T>(workers: Branch<T>[], input: string) =>
  Promise.all(workers.map((w) => w(input)));                              

/* 4. Orchestrator-workers: an agent behind a tool. Chapter 18's interface, unchanged. */
export function agentTool(o: WorkerSpec): Tool {
  return {
    name: o.name, description: o.description, readOnly: true,
    parameters: { type: "object", properties: { question: { type: "string" } } },
    async run(args: { question: string }) {
      const child = newRun(o.system, args.question);          // its own window
      await runTracked(child, o.tools, o.usage);              // its own limits
      const conclusion = child.output ?? "no result";
      if (!o.carryFindings) return conclusion;                             
      return `${conclusion}\nFINDINGS ${evidence(child)}`;                 
    },
  };
}

/* 5. Evaluator-optimiser: make, judge, remake. Rounds are calls. */
export async function refine(make: Make, judge: Judge, maxRounds: number) {
  let draft = "", feedback: string | undefined;
  for (let r = 1; r <= maxRounds; r++) {
    draft = (await make(feedback)).text;
    const j = await judge(draft);
    if (j.ok) return { draft, rounds: r };
    feedback = j.note;
  }
  return { draft, rounds: maxRounds };
}

Esse é o kit inteiro: cinco funções, nenhum framework, e a paralela é uma única linha — esse é justamente o motivo de escrevê-la em vez de desenhá-la. Agora, uma por uma, com sua ancestralidade, seu preço e o caso em que está errada.

Prompt chaining "decompõe uma tarefa em uma sequência de etapas, em que cada chamada ao LLM processa o output da anterior".¹ A ideia é anterior aos modelos de linguagem: é um pipeline, com a troca do pipeline — clareza em troca de um fluxo de controle fixado antes de os dados chegarem.

Quatro etapas para nossa tarefa: extrair os campos da fatura, verificar a aritmética, decidir o que é devido, escrever a resposta. Aqui ele falha de duas formas diferentes, o que ensina mais do que falhar uma vez.

--- relay: each step sees only the previous step's output
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 vat_amount=52.08 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=unknown reason=no_invoice_in_context
draft:   "we are looking into invoice FT-2026-0918 and will come back to you."

--- accumulating: each step sees the email and everything produced so far
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=invoice_correct reason=net_248.00_plus_21pct_vat_52.08_equals_300.08
draft:   "we have checked FT-2026-0918 and it is correct... Nothing is owed back."

A cadeia de repasse custou $0.001940 e perdeu os campos da fatura entre as etapas dois e três, porque a etapa três recebeu uma frase sobre aritmética e nada mais. Produziu uma mensagem de espera: inútil, e visivelmente inútil.

A cadeia acumuladora — a linha da tabela de abertura — custou $0.003780, o que é 95 % a mais para quatro chamadas idênticas, porque cada etapa agora carrega tudo que veio antes. Ela produziu o output perigoso. Fluente, citando sua aritmética, correto em todos os números que menciona e dizendo a um cliente que nada é devido quando EUR 52,08 é devido.

A diferença entre as duas é um ternário. Uma cadeia que carrega menos produz respostas obviamente incompletas; uma cadeia que carrega tudo produz respostas confiantemente erradas — e só o segundo tipo é enviado.

Nenhuma das duas é a falha real. A falha real é que o pipeline decidiu, antes de ler qualquer coisa, que essa tarefa tem quatro etapas sobre o conteúdo de um e-mail. Em nenhum lugar dessa estrutura há um espaço para dizer "o país de registro não está neste e-mail; vá buscá-lo". Chaining é correto quando a decomposição é conhecida de antemão e estável. Aqui ela era um palpite, e o palpite foi para produção.

Routing "classifica um input e o direciona para uma tarefa de acompanhamento especializada".¹ O nome é novo; o mecanismo é o dispatcher, mais antigo do que quase todo o resto deste livro. A novidade é que o classificador pode ser um modelo — e é isso que o faz falhar de formas que um switch nunca falhou.

const answer = await route(email,
  (q) => classifyWithSmallModel(q),          // cheap model, one call
  { billing: billingAgent, tax: taxAgent, dunning: dunningAgent },
  taxAgent,                                  // deterministic, chosen in advance
);

Duas coisas sobre esse último argumento. Não é tratamento de erro; é o padrão. Um router baseado em modelo tem um modo de falha que um dispatcher não tem: ele pode retornar um rótulo que não existe, dar timeout ou — o caro — retornar um rótulo plausível e errado sem nenhum sinal de que está errado. Os três precisam aterrissar em algum lugar, e esse lugar não pode ser outra chamada ao modelo, porque você já está no ramo em que chamadas ao modelo falharam.

A segunda coisa é que o prompt do próprio router não é gratuito. Para escolher um modelo, um router precisa de um catálogo de modelos para escolher, e cada entrada nele é input que o router paga antes de ter lido a pergunta do usuário. Na tarifa de input com que este curso precifica, um catálogo de cerca de 3.800 tokens já custa tanto quanto a execução inteira do agent de cinco chamadas na tabela de abertura. Na prática, a chamada de roteamento roda em um modelo barato, e essa é justamente a razão pela qual o roteamento se paga; mas vale a pena fazer a aritmética nessa direção em vez de presumir. O roteamento está errado exatamente quando a tarefa roteada é mais barata do que a decisão de roteamento.

A Anthropic divide isto em dois: sectioning — "dividir uma tarefa em subtarefas independentes executadas em paralelo" — e voting — "executar a mesma tarefa várias vezes para obter outputs diversos".¹ Eles compartilham um diagrama e quase nada mais.

Sectioning é o ganho barato, e é a linha de patterns.ts: três especialistas — billing, fiscal, políticas — cada um com sua própria janela e ferramentas, sobre o mesmo e-mail, uma chamada de síntese no fim. Trabalho idêntico, ordenado de duas formas:

Mesmo token por token, 1,8 vez mais rápido. É por isso que o padrão ganha nome próprio: é o único dos cinco que melhora algo sem custar nada. O detalhe é que as seções precisam ser genuinamente independentes — dê à seção B um fato que a seção A produz e Promise.all executa as duas contra um estado que ainda não existe. O loop for escondia esse bug; a linha única o expõe.

Voting é outro bicho usando a mesma imagem. Rodar a mesma pergunta k vezes e pegar a maioria é self-consistency, publicado por Wang et al. em março de 2022 como uma estratégia de decoding, quase três anos antes de alguém chamá-lo de padrão de orquestração. Seu resumo é preciso sobre o mecanismo — "primeiro amostra um conjunto diverso de caminhos de raciocínio em vez de tomar apenas o greedy, e então seleciona a resposta mais consistente marginalizando os caminhos de raciocínio amostrados" — e sobre o ganho: +17,9 pontos no GSM8K.²

Duas coisas decorrem disso que a imagem esconde. Primeiro, voting exige o sampling do Capítulo 17: com temperature zero, todas as k amostras são a mesma amostra, e a maioria é uma resposta paga k vezes. Segundo, ele só funciona onde uma maioria faz sentido — na resposta da fatura acima não há nada para contar, porque cinco rascunhos são cinco frases diferentes. Voting é para tarefas com uma resposta curta e comparável, exatamente os benchmarks de Wang e quase nada que um agent voltado ao cliente faz.

Medido aqui em 20 problemas de enunciado em três etapas cujas respostas são computadas, não julgadas, com o modelo local do Capítulo 23 raciocinando passo a passo:

Cinco vezes as chamadas, cinco vezes os tokens, exatamente cinco vezes a conta, e nem uma resposta correta a mais. Voting é uma aposta, não uma melhoria, e esta execução perdeu.

Duas ressalvas, antes que alguém cite isso como refutação de Wang. Vinte testes não distinguem 45 % de 60 % — o intervalo tem a largura da afirmação, que é a disciplina do Capítulo 4 aplicada ao meu próprio resultado. E os ganhos publicados vêm de modelos ordens de magnitude maiores, nos quais os caminhos de raciocínio diversos que o voting marginaliza são de fato diversos. O que se transfere não é o número: é que o multiplicador é exato e conhecido de antemão, enquanto o ganho não é.

No workflow orquestrador-workers, "um LLM central divide tarefas dinamicamente, delega-as a LLMs workers e sintetiza seus resultados", e a diferença em relação ao sectioning é que "as subtarefas não são predefinidas, mas determinadas pelo orquestrador".¹ A ancestralidade aqui não vem de modelos de linguagem: isso é master-worker, e a versão em que workers escrevem descobertas em um espaço compartilhado que um controlador lê é a arquitetura blackboard, da pesquisa de compreensão de fala nos anos 1970. O que é novo em 2026 é que o controlador é um modelo e, portanto, a decomposição pode ser decidida por input — que é a flexibilidade e o custo em uma frase.

Custou 12 chamadas ao modelo contra 5 do agent único, e chegou ao mesmo veredito. Então fez algo que vale observar de perto:

orchestrator final: VERDICT=credit_note_due amount=52.08 source=worker_unverified
                  | PO_MISMATCH=yes source=worker_unverified
single agent:       VERDICT=credit_note_due amount=52.08 reason=reverse_charge_should_have_applied
                  | PO_MISMATCH=yes invoice_says=PO-4417 order_says=PO-4471

Ambos estão certos. Só um sabe por quê. O worker fiscal tinha a fatura, o pedido e a tabela tributária em sua própria janela, chegou à conclusão e também percebeu — ninguém perguntou — que o número do pedido de compra na fatura não corresponde ao do pedido. Então retornou um resumo. O orquestrador consegue repetir as duas afirmações e não consegue verificar nenhuma, porque a evidência ficou em uma janela que ele nunca viu. A pergunta final do Capítulo 24, respondida: o pai consegue examinar o que quer que o filho tenha escolhido escrever.

A correção é uma flag, e ela tem um preço:

Doze por cento mais input tokens, 8,3 % mais dinheiro, e a frase source=worker_unverified desaparece da resposta. Essa é a troca em todo sistema multi-agent e ela quase nunca é declarada: vale a pena ter a janela limpa do filho, vale a pena pagar pela capacidade do pai de auditá-la, e você não pode ter as duas de graça.

Então quando orquestrador-workers está errado? Aqui, nesta tarefa. Ele comprou uma resposta correta que um agent com as mesmas quatro ferramentas também alcançou, por 1,66 vez o custo e 2,3 vezes o tempo de parede, e tornou essa resposta mais difícil de defender. A própria orientação da Anthropic diz isso antes de os padrões começarem: encontrar "a solução mais simples possível, e só aumentar a complexidade quando necessário", porque "agentic systems frequentemente trocam latência e custo por melhor desempenho na tarefa".¹ As tabelas acima são essa frase com números embaixo.

Uma chamada gera, outra avalia, e o loop se repete até a avaliação passar.¹ Os ancestrais publicados são Self-Refine — o mesmo modelo como "gerador, refinador e provedor de feedback", relatando cerca de 20 pontos de melhoria absoluta em média sobre sete tarefas³ — e Reflexion, que armazena a crítica em um buffer episódico entre tentativas e relata 91 % pass@1 no HumanEval, onde o baseline chegou a 80 %.⁴

O modelo de custo é o mais simples dos cinco: duas chamadas por rodada, e a contagem de rodadas não é sua. Três rodadas de refinamento em uma tarefa que levou uma chamada são seis chamadas, então o piso do padrão é 6× e o teto é qualquer limite que você definir — o que torna a saída por orçamento do Capítulo 23 obrigatória, não apenas elegante.

O teto é mais sutil, e é mensurável. Nos mesmos 20 problemas, o modelo local respondeu 9 corretamente. Então mostramos cada uma dessas respostas a ele e perguntamos se estava certa — sem dizer que a resposta era dele, o que remove o confundidor da bajulação e deixa o da capacidade:

É um juiz melhor do que o título da seção sugere, e dizer isso é o objetivo de medir em vez de afirmar: ele não bloqueou nada correto e capturou 8 de 11 erros. Como filtro, vale suas chamadas.

Como regra de parada, que é para o que um loop evaluator-optimiser realmente o usa, essas três aprovações são a história inteira: elas encerram o loop com uma resposta errada em mãos, e nenhuma quantidade de rodadas extras jamais chega nelas. Um loop de refinamento não pode ficar mais correto do que seu juiz. Comprar mais rodadas compra tentativas nos erros que o juiz consegue ver, a preço cheio, e absolutamente nada contra os que ele não consegue.

Daí a regra: um evaluator só merece suas chamadas quando tem algo que o gerador não tem. Um compilador, uma suíte de testes, um schema validator, um modelo diferente, um humano. Os próprios resultados do Self-Refine são medidos contra preferência humana e métricas de tarefa, nunca contra a opinião do modelo sobre si mesmo. Se a única vantagem do seu evaluator é um prompt diferente, você está pagando o dobro por concordância. O Capítulo 29 constrói a versão com uma vantagem real: um golden set com as respostas escritas de antemão.

Os cinco acima são formatos para o seu código. Abaixo deles fica uma segunda família que muitas vezes é listada junto e não deveria ser: ReAct, Reflexion, plan-and-execute e tree of thoughts são loops de raciocínio, e seu custo está em requisições.

O Capítulo 12 tratou de raciocínio dentro do modelo, que você paga em output tokens em uma chamada. Este é o outro tipo. A diferença importa quando a conta chega: uma cadeia de pensamento mais longa torna uma chamada mais cara, e um loop de raciocínio transforma uma tarefa em muitas chamadas, cada uma reenviando tudo que veio antes — o quadrático que o Capítulo 23 mediu em sua tabela de runaway.

O artigo de tree-of-thoughts publica sua própria tabela de custos, o que é mais raro do que deveria. No Game of 24 com GPT-4: input/output prompting best-of-100 resolveu 33 % a $0.13 por caso, chain of thought best-of-100 resolveu 49 % a $0.47, e tree of thoughts resolveu 74 % a $0.74, com os autores observando que ele "poderia exigir 5–100 vezes mais tokens gerados do que CoT".⁷

Quase seis vezes o preço do método barato para um pouco mais que o dobro da taxa de sucesso. Se isso é uma barganha depende de quanto custa para você um caso fracassado — a pergunta a fazer antes de adotar qualquer um desses quatro.

Este curso não os reimplementa. Todos os quatro têm implementações de referência pelos próprios autores, em Python, e seu valor é serem a fonte, não uma tradução: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm e AGI-Edgerunners/Plan-and-Solve-Prompting. Leia os prompts nesses repositórios; os prompts são os artigos.

Agora o multi-agent propriamente dito, onde mora a maior parte da confusão. Há duas formas de um agent envolver outro, elas não são variantes, e a diferença é quem fica no comando depois.

Agent como ferramenta. O pai o chama, recebe uma resposta e continua. É a interface de ferramenta do Capítulo 18 com um agent inteiro por trás, e o pai nunca perde o controle. É isso que o orquestrador acima faz.

Handoff. O pai transfere a conversa e não a recebe de volta. O guia da OpenAI é a declaração publicada mais clara: handoffs são "uma transferência unidirecional que permite a um agent delegar a outro agent... Se um agent chama uma função de handoff, imediatamente iniciamos a execução naquele novo agent ao qual foi feito o handoff, enquanto também transferimos o estado mais recente da conversa".⁸

Um alerta de vocabulário, porque isso confunde as pessoas o tempo todo: "handoff" é a palavra de um SDK, não um padrão. É terminologia do OpenAI Agents SDK e daquele guia, que também chama os dois arranjos de "manager" e "decentralized" e observa que, no padrão manager, "as arestas representam chamadas de ferramenta, enquanto no padrão decentralized, as arestas representam handoffs".⁸ Há sim um padrão aberto nesse espaço — A2A, na versão 1.0.0, sob copyright da Linux Foundation, com histórico de versões e uma lista documentada de breaking changes, cujo princípio declarado é execução opaca: agents "colaboram com base em capacidades declaradas e informações trocadas, sem precisar compartilhar seus pensamentos internos, planos ou implementações de ferramentas".⁹ Isso não é um handoff, e a comparação pertence ao Capítulo 26. O que importa aqui é que uma das duas palavras é a API de uma biblioteca e a outra é uma especificação com governança.

A distinção é uma estrutura de dados, não um diagrama:

export type EdgeKind = "tool" | "handoff";
export interface AgentEdge { from: string; to: string; kind: EdgeKind }
export interface AgentGraph { root: string; agents: Record<string, AgentSpec>; edges: AgentEdge[] }

/** One agent may not be both a tool of X and a handoff target of X. */
export function conflicts(g: AgentGraph): AgentEdge[] {
  const seen = new Map<string, EdgeKind>();
  const bad: AgentEdge[] = [];
  for (const e of g.edges) {
    const key = `${e.from}->${e.to}`;
    const other = seen.get(key);
    if (other && other !== e.kind) bad.push(e);                            
    else seen.set(key, e.kind);
  }
  return bad;
}

/** Every agent reachable from the root, and at what depth. */
export function reachable(g: AgentGraph): Map<string, number> {
  const depth = new Map([[g.root, 0]]);
  const queue = [g.root];
  while (queue.length) {
    const id = queue.shift()!;
    for (const e of g.edges.filter((x) => x.from === id)) {
      if (depth.has(e.to)) continue;
      depth.set(e.to, depth.get(id)! + 1);
      queue.push(e.to);
    }
  }
  return depth;
}

Vinte linhas, dois bugs que você só encontraria em produção. reachable encontra o agent que ninguém consegue alcançar — configurado, pago, nunca chamado. conflicts recusa a aresta que é dos dois tipos ao mesmo tempo, o que soa pedante até você ler em voz alta: o pai tanto mantém o controle quanto o entrega. Rode isso em um sistema de cinco agents com um órfão e uma aresta dupla:

reachable: lead@0 billing@1 tax@1 dunning@1
orphans:   ghost
conflicts: lead->tax

Agora a medição para a qual esta seção existe, e a única do capítulo feita contra um modelo real em vez de um roteirizado.

Um cliente declara uma restrição em sua primeira mensagem — nossa conta está registrada em Portugal, não na Espanha; tudo relacionado a impostos precisa usar Portugal — conversa sobre outra coisa, depois faz uma pergunta que billing precisa responder. O caso é transferido. Vinte e quatro testes, um país e uma empresa diferentes a cada vez, quatro payloads de transferência, e o agent receptor então recebe uma pergunta: em que país a conta deste cliente está registrada?

A terceira linha é um controle e se comporta como tal: o fato não está ali, então não pode ser lembrado. As outras três são o achado.

A transcrição completa tem 173 tokens e funciona 83 % das vezes, com suas quatro falhas sendo assunto do Capítulo 24, não deste. O registro tipado tem 69 tokens — sete a mais que o resumo — e funciona todas as vezes, porque a restrição fica em um campo nomeado, não em uma frase.

E o resumo é a linha para encarar. Ele falhou 24 vezes em 24, e o motivo não é que o leitor não a viu. A restrição apareceu em apenas 1 dos 24 resumos. O agent receptor não foi descuidado; recebeu um texto que não continha a resposta. Um resumo é uma compactação que você não escreveu, produzida por um modelo cuja janela você não consegue ver, otimizada para soar como um resumo — e "o cliente diz que nossos registros têm o país errado" é exatamente o tipo de oração que um sumarizador descarta como ruído procedural.

Um limite honesto desse número: o sumarizador é um modelo de meio bilhão de parâmetros, e um maior manteria mais. O que não melhora com tamanho é o formato do risco — o agent remetente decide, a cada handoff, a cada formulação, de forma inobservável, quais fatos sobrevivem. O registro tipado não depende desse julgamento, e é por isso que vence por construção, não por inteligência. Tudo que precisa sobreviver a uma transferência deve ser um campo, não uma frase.

O mesmo raciocínio se aplica na outra direção, à topologia de agent-como-ferramenta, e a tabela anterior já colocou preço nisso: o que volta de um worker também é um resumo, e pagar 8,3 % a mais para receber a evidência junto é a mesma correção vista do lado do pai.

Três fatos finais, todos das tabelas acima.

Um sistema multi-agent multiplica chamadas, e chamadas são quadráticas em context. O orquestrador fez 12 chamadas ao modelo onde um agent fez 5, e cada uma carrega sua própria transcrição crescente — 3.628 input tokens contra 2.697, uma diferença que aumenta com a duração da tarefa.

Toda fronteira é um canal com perdas. Dois agents significam um resumo. Quatro agents em cadeia significam três, compostos, cada um escrito por um modelo que otimiza para algo diferente da sua decisão.

O agent único encontrou algo que ninguém pediu. A divergência do pedido de compra veio à tona porque uma janela continha a fatura e o pedido ao mesmo tempo. Dividir trabalho entre especialistas também divide a capacidade de notar que dois fatos discordam.

Nada disso argumenta contra os frameworks multi-agent publicados, que vale ler como fontes primárias em vez de por tutoriais.¹⁰ Argumenta a favor de fazer o segundo agent merecer seu lugar.

Então, um teste em vez de uma preferência. Adicione um segundo agent quando pelo menos uma destas coisas for verdadeira: a subtarefa precisa de uma janela limpa que o pai não deve herdar (Capítulo 24); as subtarefas são genuinamente independentes e o tempo de parede importa, que é o 1,8× acima; a subtarefa precisa de permissões diferentes ou de um modelo diferente, o que o Capítulo 30 transforma em argumento de segurança; ou a subtarefa é de outra pessoa, que é onde um protocolo real começa a importar. Se a resposta for "para cada agent ter um prompt mais claro", dê ao agent único um prompt mais claro. É de graça.

Agora você sabe nomear os cinco padrões, precificá-los uns contra os outros em uma tarefa, diferenciar um orquestrador de um sectioner e uma chamada de ferramenta de um handoff, e defender um agent único com uma tabela em vez de uma preferência.

Todo arranjo aqui compartilhou uma conveniência que não sobreviverá ao contato com nada real: todas as ferramentas pertenciam a nós. Fatura, pedido, tabela tributária, os workers por trás do orquestrador — mesmo repositório, mesmo deploy, mesmos tipos, mesmas pessoas.

Agora coloque uma delas do outro lado de uma fronteira de empresa. A tabela tributária pertence a um fornecedor contábil, o registro do pedido a um sistema de armazém, e nenhum dos dois leu sua interface Tool. Você precisa de uma forma para um modelo que você não escreveu descobrir, descrever e chamar uma capacidade que outra pessoa opera — com autenticação (que é a metade do Capítulo 27), versionamento e a garantia de que um servidor não consegue ler o resto da sua conversa. Isso é um problema de protocolo, tem uma especificação com schema normativo, e quase tudo indexado sobre ele descreve uma revisão que já não existe.

O Capítulo 26 lê essa especificação em vez de resumi-la, e começa digitando JSON-RPC em um terminal à mão.

Todo custo e contagem de tokens acima veio do provedor roteirizado descrito na segunda seção, em Node 22 sobre uma interface loopback, contando com a codificação o200k_base e precificado nas tarifas que o Capítulo 16 leu em 6 de setembro de 2026 — $2.00 por milhão de input tokens e $12.00 por milhão de output. Os números de tempo de parede vêm das mesmas execuções com a latência do provedor definida em 400 ms por chamada e as ferramentas em 50 ms, então medem o arranjo, não qualquer provedor. As duas medições com modelo real — a tabela de handoff e a tabela de voting e julgamento — usaram Qwen/Qwen2.5-0.5B-Instruct em float32 na CPU atrás de um endpoint do mesmo formato, greedy exceto onde uma temperature é declarada, com intervalos computados pelo método de Wilson do Capítulo 4. Nenhuma requisição neste capítulo foi para um endpoint pago, e nenhum número nele foi estimado.