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

Uma empresa portuguesa escreve sobre a fatura FT-2026-0918. O email diz que o IVA parece errado, e anexa a fatura: valor líquido EUR 248.00, IVA cobrado a 21 %, EUR 52.08, total EUR 300.08.

Os factos necessários para responder vivem em três sítios, e só um deles está no email:

Junte os três e a fatura está errada: aplica-se a autoliquidação, o IVA devia ter sido zero, é devida uma nota de crédito de EUR 52.08. Olhe apenas para a fatura e ela está aritmeticamente perfeita — 248.00 mais 52.08 é 300.08 — e é isso que dirá.

O email diz de facto "somos uma empresa portuguesa". Isso é uma afirmação, não um registo, e nenhum sistema de faturação emite uma nota de crédito com base numa afirmação. A armadilha não é um truque: é a forma normal do trabalho empresarial, em que a decisão precisa de um facto que ninguém se lembrou de ir buscar.

Tudo acima corre contra um fornecedor com script ao estilo do Capítulo 23, com exatamente uma regra:

Uma resposta só pode usar um facto que esteja no seu prompt.

O "modelo" pede cada tool que tem, uma vez, por ordem de catálogo, e depois aplica uma regra fixa ao texto que consegue ver. Nada é programado por configuração, por isso as diferenças na tabela inicial não são afirmações sobre inteligência do modelo: são encaminhamento de informação, medido. Um modelo real acrescenta as suas próprias falhas por cima; não remove estas.

Os cinco nomes abaixo são da Anthropic, de Building effective agents, que foi onde este vocabulário assentou.¹ Nenhuma das cinco ideias é nova, e dizer que casa deu que nome — e que ideia é mais antiga — é metade do valor de as conhecer.

/* 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 };
}

Este é o toolkit completo: cinco funções, sem framework, e a paralela é uma única linha — que é precisamente a razão para a escrever em vez de a desenhar. Agora cada uma por sua vez, com a sua ascendência, o seu preço e o caso em que está errada.

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

Quatro passos para a nossa tarefa: extrair os campos da fatura, verificar a aritmética, decidir o que é devido, escrever a resposta. Aqui 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 retransmissão custou $0.001940 e perdeu os campos da fatura entre os passos dois e três, porque ao passo três foi entregue uma frase sobre aritmética e nada mais. Produziu uma mensagem de espera: inútil, e visivelmente inútil.

A cadeia acumulativa — a linha da tabela inicial — custou $0.003780, ou seja, mais 95 % por quatro chamadas idênticas, porque cada passo agora carrega tudo o que veio antes. Produziu o output perigoso. Fluente, citando a sua aritmética, correto em todos os números que menciona, e a dizer a um cliente que nada é devido quando são devidos EUR 52.08.

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

Nenhuma delas é a verdadeira falha. A verdadeira falha é que a pipeline decidiu, antes de ler qualquer coisa, que esta tarefa são quatro passos sobre o conteúdo de um email. Em parte alguma dessa estrutura existe um lugar para dizer "o país de registo não está neste email; vai buscá-lo". Chaining é adequado quando a decomposição é conhecida antecipadamente e estável. Aqui foi um palpite, e o palpite foi enviado.

Routing "classifica um input e encaminha-o para uma tarefa de seguimento especializada".¹ O nome é novo; o mecanismo é o despachante, mais antigo do que quase tudo o resto neste livro. O que é novo é 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 erros; é o padrão. Um router baseado em modelo tem um modo de falha que um despachante não tem: pode devolver uma etiqueta que não existe, fazer timeout ou — a opção cara — devolver uma etiqueta plausível mas errada, sem qualquer sinal de que está errada. As três têm de cair em algum lado, e esse algum lado não pode ser outra chamada ao modelo, porque já está no ramo em que as chamadas ao modelo falharam.

A segunda coisa é que o prompt do próprio router não é grátis. Para escolher um modelo, um router precisa de um catálogo de modelos por onde escolher, e cada entrada nele é input que o router paga antes de ter lido a pergunta do utilizador. À taxa de input com que este curso calcula preços, um catálogo de cerca de 3,800 tokens já custa tanto como toda a execução de cinco chamadas do agent na tabela inicial. Na prática, a chamada de routing corre num modelo barato, que é a razão inteira pela qual routing se paga; mas a aritmética vale a pena ser feita nessa direção, em vez de assumida. Routing está errado precisamente quando a tarefa encaminhada é mais barata do que a decisão de routing.

A Anthropic divide este padrão 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".¹ Partilham um diagrama e quase nada mais.

Sectioning é a vitória barata, e é a linha de patterns.ts: três especialistas — faturação, fiscalidade, política — cada um com a sua própria window e tools, sobre o mesmo email, com uma chamada de síntese no fim. Trabalho idêntico, ordenado de duas formas:

Mesmo token por token, 1,8 vezes mais rápido. É por isso que o padrão merece nome próprio: é o único dos cinco que melhora alguma coisa sem custar nada. O senão é que as secções têm de ser genuinamente independentes — dê à secção B um facto que a secção A produz e Promise.all corre ambas contra um estado que ainda não existe. O ciclo for escondia esse bug; a linha única expõe-no.

Voting é um animal diferente a usar a mesma imagem. Executar a mesma pergunta k vezes e escolher a maioria é self-consistency, publicado por Wang et al. em março de 2022 como estratégia de descodificação, quase três anos antes de alguém lhe chamar um padrão de orquestração. O seu resumo é preciso quanto ao mecanismo — "primeiro amostra um conjunto diverso de caminhos de raciocínio em vez de escolher apenas o greedy, e depois seleciona a resposta mais consistente marginalizando os caminhos de raciocínio amostrados" — e quanto ao ganho: +17,9 pontos no GSM8K.²

Daqui seguem duas coisas que a imagem esconde. Primeiro, voting exige a amostragem do Capítulo 17: a temperatura zero, todas as k amostras são a mesma amostra, e a maioria é uma resposta paga k vezes. Segundo, só funciona onde uma maioria tem significado — na resposta à 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, que é exatamente o tipo de benchmark de Wang e quase nada do que um agent virado para clientes faz.

Medido aqui em 20 problemas de palavras com três passos, cujas respostas são calculadas em vez de julgadas, com o modelo local do Capítulo 23 a raciocinar passo a passo:

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

Duas ressalvas, antes que alguém cite isto como refutação de Wang. Vinte ensaios 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 grandeza maiores, onde os caminhos de raciocínio diversos que voting marginaliza são realmente diversos. O que se transfere não é o número: é que o multiplicador é exato e conhecido de antemão, enquanto o ganho não é nenhuma das duas coisas.

No workflow orchestrator-workers, "um LLM central decompõe tarefas dinamicamente, delega-as a LLMs trabalhadores e sintetiza os seus resultados", e a diferença face ao sectioning é que "as subtarefas não são pré-definidas, mas determinadas pelo orquestrador".¹ A ascendência aqui não vem de modelos de linguagem de todo: isto é master-worker, e a versão em que os trabalhadores escrevem conclusões num espaço partilhado que um controlador lê é a arquitetura blackboard, da investigação em compreensão de fala dos anos 1970. O que é novo em 2026 é que o controlador é um modelo e, por isso, a decomposição pode ser decidida por input — que é a flexibilidade e o custo numa só frase.

Custou 12 chamadas ao modelo contra as 5 do agent único, e chegou ao mesmo veredicto. Depois fez algo que vale a pena 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

Ambas estão certas. Só uma sabe porquê. O trabalhador fiscal tinha a fatura, a encomenda e a tabela fiscal na sua própria window, chegou à conclusão e também reparou — ninguém perguntou — que o número da ordem de compra na fatura não coincide com o da encomenda. Depois devolveu um resumo. O orquestrador consegue repetir ambas as afirmações e verificar nenhuma, porque a evidência ficou numa window que ele nunca viu. Esta é a pergunta final do Capítulo 24, respondida: o pai pode ver aquilo que o filho decidiu escrever.

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

Mais doze por cento de input tokens, mais 8,3 % de dinheiro, e a frase source=worker_unverified desaparece da resposta. Essa é a troca em todos os sistemas multi-agent e quase nunca é explicitada: vale a pena ter a window limpa do filho, vale a pena pagar pela capacidade de o pai a auditar, e não se pode ter as duas coisas grátis.

Então quando é que orchestrator-workers está errado? Aqui, nesta tarefa. Comprou uma resposta correta que um agent com as mesmas quatro tools também alcançou, por 1,66 vezes o custo e 2,3 vezes o tempo decorrido, 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 "os sistemas agentic muitas vezes trocam latência e custo por melhor desempenho na tarefa".¹ As tabelas acima são essa frase com números por baixo.

Uma chamada gera, outra avalia, e o ciclo repete-se até a avaliação passar.¹ Os antepassados publicados são Self-Refine — o mesmo modelo como "generator, refiner, and feedback provider", reportando cerca de 20 pontos de melhoria absoluta em média em sete tarefas³ — e Reflexion, que guarda a crítica num buffer episódico entre tentativas e reporta 91 % pass@1 no HumanEval quando a baseline chegou a 80 %.⁴

O modelo de custo é o mais simples dos cinco: duas chamadas por ronda, e a contagem de rondas não é sua. Três rondas de refinement numa tarefa que demorou uma chamada são seis chamadas, por isso o piso do padrão é 6× e o teto é qualquer limite que definir — o que torna a saída por orçamento do Capítulo 23 obrigatória em vez de elegante.

O teto é mais subtil, e é mensurável. Nos mesmos 20 problemas, o modelo local respondeu corretamente a 9. Depois foram-lhe mostradas cada uma dessas respostas e foi-lhe perguntado se estava certa — sem lhe dizer que a resposta era sua, o que remove o confundidor da bajulação e deixa o da capacidade:

É um juiz melhor do que o título da secção implica, e dizê-lo é o objetivo de medir em vez de afirmar: não bloqueou nada correto e apanhou 8 de 11 erros. Como filtro, vale as chamadas.

Como regra de paragem, que é aquilo para que um ciclo evaluator-optimiser realmente o usa, essas três aprovações são a história toda: terminam o ciclo com uma resposta errada na mão, e nenhuma quantidade de rondas extra alguma vez chega a elas. Um ciclo de refinement não pode tornar-se mais correto do que o seu juiz. Comprar mais rondas compra tentativas sobre os erros que o juiz consegue ver, a preço inteiro, e nada contra os que não consegue.

Daí a regra: um evaluator só merece as suas chamadas quando tem algo que o generator não tem. Um compilador, uma suite de testes, um validador de schema, 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 próprio. Se a única vantagem do seu evaluator é um prompt diferente, está a pagar 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 antecipadamente.

Os cinco acima são formas para o seu código. Por baixo deles existe uma segunda família que é muitas vezes listada ao lado e não devia ser: ReAct, Reflexion, plan-and-execute e tree of thoughts são ciclos de raciocínio, e o seu custo está em pedidos.

O Capítulo 12 foi sobre raciocínio dentro do modelo, pelo qual se paga em output tokens numa chamada. Este é o outro tipo. A diferença importa quando a conta chega: uma chain of thought mais longa torna uma chamada mais cara, e um ciclo de raciocínio transforma uma tarefa em muitas chamadas, cada uma reenviando tudo o que veio antes — a quadrática que o Capítulo 23 mediu na sua tabela de descontrolo.

O artigo tree-of-thoughts publica a sua própria tabela de custos, o que é mais raro do que devia ser. 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 a notar que "could require 5-100 times more generated tokens than CoT".⁷

Quase seis vezes o preço do método barato para pouco mais do dobro da taxa de sucesso. Se isso é um bom negócio depende do que custa um caso falhado — a pergunta a fazer antes de adotar qualquer um destes quatro.

Este curso não os reimplementa. Os quatro têm implementações de referência pelos próprios autores, em Python, e o seu valor é serem a fonte em vez de 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 vive a maior parte da confusão. Há duas formas de um agent envolver outro, não são variantes, e a diferença é quem fica no comando depois.

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

Transferência. 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 num só sentido que permite a um agent delegar noutro agent... Se um agent chama uma função de handoff, começamos imediatamente a execução nesse novo agent para o qual foi feito handoff, ao mesmo tempo que transferimos o estado mais recente da conversa."⁸

Um aviso de vocabulário, porque isto faz tropeçar muita gente: "handoff" é a palavra de um SDK, não uma norma. É terminologia do OpenAI Agents SDK e desse guia, que também dá às duas configurações os nomes "manager" e "decentralized" e nota que no padrão manager "edges represent tool calls whereas in the decentralized pattern, edges represent handoffs".⁸ Há sim uma norma aberta neste espaço — A2A, na versão 1.0.0, sob copyright da Linux Foundation, com histórico de releases versionado e uma lista documentada de breaking changes, cujo princípio declarado é opaque execution: agents "collaborate based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations".⁹ 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 governação.

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 de outro modo encontraria em produção. reachable encontra o agent a que ninguém consegue chegar — configurado, pago, nunca chamado. conflicts recusa a aresta que é dos dois tipos ao mesmo tempo, o que soa pedante até ser dito em voz alta: o pai tanto mantém o controlo como o entrega. Execute-o num 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 secção existe, e a única do capítulo feita contra um modelo real em vez de um com script.

Um cliente declara uma restrição na sua primeira mensagem — a nossa conta está registada em Portugal, não em Espanha; tudo o que for fiscal tem de usar Portugal — conversa sobre outra coisa, e depois faz uma pergunta a que a faturação deve responder. O caso é transferido. Vinte e quatro ensaios, um país e uma empresa diferentes de cada vez, quatro payloads de transferência, e ao agent recetor é então feita uma pergunta: em que país está registada a conta deste cliente?

A terceira linha é um controlo e comporta-se como tal: o facto não está lá, por isso não pode ser recordado. As outras três são o resultado.

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

E o resumo é a linha para encarar. Falhou 24 vezes em 24, e a razão não é que o leitor não a tenha visto. A restrição apareceu em apenas 1 dos 24 resumos. O agent recetor não foi descuidado; recebeu um texto que não continha a resposta. Um resumo é uma compactação que não escreveu, produzida por um modelo cuja window não consegue ver, otimizada para se ler como um resumo — e "o cliente diz que os nossos registos têm o país errado" é exatamente o tipo de cláusula que um resumidor deixa cair como ruído procedimental.

Um limite honesto sobre esse número: o resumidor é um modelo de meio bilião de parâmetros e um maior reteria mais. O que não melhora com o tamanho é a forma do risco — o agent remetente decide, por transferência, por formulação, de forma inobservável, que factos sobrevivem. O registo tipado não depende desse julgamento de todo, e é por isso que ganha por construção em vez de por inteligência. O que tiver de sobreviver a uma transferência deve ser um campo, não uma frase.

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

Três factos finais, todos das tabelas acima.

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

Cada fronteira é um canal com perdas. Dois agents significam um resumo. Quatro agents numa cadeia significam três, compostos, cada um escrito por um modelo a otimizar para algo diferente da sua decisão.

O agent único encontrou algo que ninguém pediu. A discrepância da ordem de compra apareceu porque uma window continha ao mesmo tempo a fatura e a encomenda. Dividir o trabalho por especialistas também divide a capacidade de notar que dois factos discordam.

Nada disto é um argumento contra as frameworks multi-agent publicadas, que vale a pena ler como fontes primárias em vez de através de tutoriais.¹⁰ É um argumento para obrigar o segundo agent a merecer o seu lugar.

Portanto, um teste em vez de uma preferência. Acrescente um segundo agent quando pelo menos uma destas condições for verdadeira: a subtarefa precisa de uma window limpa que o pai não deve herdar (Capítulo 24); as subtarefas são genuinamente independentes e o tempo decorrido 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 num argumento de segurança; ou a subtarefa é propriedade de outra pessoa, que é onde um protocolo real começa a importar. Se a resposta for "para que cada agent tenha um prompt mais claro", dê ao agent único um prompt mais claro. É grátis.

Agora consegue nomear os cinco padrões, compará-los em preço numa tarefa, distinguir um orquestrador de um sectioner e uma tool call de um handoff, e defender um agent único com uma tabela em vez de uma preferência.

Todas as configurações aqui partilharam uma conveniência que não sobreviverá ao contacto com algo real: todas as tools pertenciam-nos. Fatura, encomenda, tabela fiscal, os trabalhadores por trás do orquestrador — mesmo repositório, mesmo deploy, mesmos tipos, mesmas pessoas.

Agora ponha uma delas do outro lado de uma fronteira empresarial. A tabela fiscal pertence a um fornecedor de contabilidade, o registo da encomenda a um sistema de armazém, e nenhum leu a sua interface Tool. Precisa de uma forma de um modelo que não escreveu descobrir, descrever e chamar uma capacidade operada por outra pessoa — 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 um schema normativo, e quase tudo o que está indexado sobre ele descreve uma revisão que já não existe.

O Capítulo 26 lê essa especificação em vez de a resumir, e começa por escrever JSON-RPC num terminal à mão.

Todos os custos e contagens de tokens acima vieram do fornecedor com script descrito na segunda secção, em Node 22 sobre uma interface loopback, contando com a codificação o200k_base e calculados aos preços 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 valores de tempo decorrido vêm das mesmas execuções com a latência do fornecedor definida para 400 ms por chamada e as tools para 50 ms, por isso medem a configuração e não qualquer fornecedor. As duas medições com modelo real — a tabela de handoff e a tabela de voting-and-judging — usaram Qwen/Qwen2.5-0.5B-Instruct em float32 no CPU por trás de um endpoint da mesma forma, greedy exceto onde uma temperatura é indicada, com intervalos calculados pelo método de Wilson do Capítulo 4. Nenhum pedido neste capítulo foi para um endpoint pago, e nenhum número nele foi estimado.