Orquestració multi-agent: cinc patrons i quan en guanya un

Una empresa portuguesa escriu sobre la factura FT-2026-0918. El correu diu que l’IVA sembla incorrecte, i adjunta la factura: base imposable de 248,00 EUR, IVA carregat al 21 %, 52,08 EUR, total 300,08 EUR.

Els fets necessaris per respondre viuen en tres llocs, i només un és al correu:

Ajunta’ls tots tres i la factura és incorrecta: s’aplica inversió del subjecte passiu, l’IVA hauria d’haver estat zero, i es deu una nota d’abonament de 52,08 EUR. Mira només la factura i és aritmèticament perfecta —248,00 més 52,08 són 300,08— i això és el que diràs.

El correu sí que afirma «som una empresa portuguesa». Això és una afirmació, no un registre, i cap sistema de facturació emet una nota d’abonament a partir d’una afirmació. La trampa no és cap truc: és la forma ordinària del treball empresarial, on la decisió necessita un fet que ningú havia pensat a anar a buscar.

Tot el que hi ha a sobre s’executa contra un proveïdor amb script a l’estil del capítol 23, amb exactament una regla:

Una resposta només pot usar un fet que sigui dins del seu prompt.

El «model» demana cada eina que té, una vegada, en l’ordre del catàleg, i després aplica una regla fixa al text que pot veure. No hi ha res escrit per a cada disposició, així que les diferències de la taula inicial no són afirmacions sobre intel·ligència del model: són routing d’informació, mesurat. Un model real hi afegeix els seus propis errors; no els elimina.

Els cinc noms següents són d’Anthropic, de Building effective agents, que és on aquest vocabulari es va assentar.¹ Cap de les cinc idees és nova, i dir quina casa va posar quin nom —i quina idea és més antiga— és la meitat del valor de conèixer-les.

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

Això és tot el conjunt d’eines: cinc funcions, cap framework, i la paral·lela és una sola línia —que és justament el motiu d’escriure-la en comptes de dibuixar-la. Ara, una per una, amb el seu llinatge, el seu preu i el cas en què s’equivoca.

El prompt chaining «descompon una tasca en una seqüència de passos, on cada crida a l’LLM processa la sortida de l’anterior».¹ La idea és anterior als models de llenguatge: és una pipeline, amb l’intercanvi propi de la pipeline —claredat a canvi d’un flux de control fixat abans que arribin les dades.

Quatre passos per a la nostra tasca: extreure els camps de la factura, comprovar l’aritmètica, decidir què es deu, escriure la resposta. Aquí falla de dues maneres diferents, cosa que ensenya més que fallar només una vegada.

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

La cadena de relleu va costar $0.001940 i va perdre els camps de la factura entre els passos dos i tres, perquè al tercer pas se li va donar una frase sobre aritmètica i res més. Va produir un missatge d’espera: inútil, i visiblement inútil.

La cadena acumulativa —la fila de la taula inicial— va costar $0.003780, que és un 95 % més per quatre crides idèntiques, perquè ara cada pas carrega tot el que hi havia abans. Va produir la sortida perillosa. Fluida, citant la seva aritmètica, correcta en cada número que menciona, i dient a un client que no se li deu res quan se li deuen 52,08 EUR.

La diferència entre totes dues és un ternari. Una cadena que carrega menys produeix respostes òbviament incompletes; una cadena que ho carrega tot produeix respostes segures i incorrectes —i només la segona mena s’envia.

Cap de les dues és el veritable fracàs. El veritable fracàs és que la pipeline va decidir, abans de llegir res, que aquesta tasca són quatre passos sobre el contingut d’un correu. Enlloc d’aquesta estructura hi ha un lloc per dir «el país de registre no és en aquest correu; ves-lo a buscar». El chaining és correcte quan la descomposició es coneix per endavant i és estable. Aquí era una suposició, i la suposició va sortir a producció.

El routing «classifica una entrada i la dirigeix a una tasca de seguiment especialitzada».¹ El nom és nou; el mecanisme és el despatxador, més antic que gairebé tot el que surt en aquest llibre. El que és nou és que el classificador pot ser un model —i això és el que fa que falli de maneres que un switch no havia fallat mai.

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

Dues coses sobre aquest últim argument. No és gestió d’errors; és el patró. Un router basat en model té un mode de fallada que un despatxador no té: pot tornar una etiqueta que no existeix, esgotar el temps, o —el cas car— tornar una etiqueta plausible però incorrecta sense cap senyal que ho sigui. Totes tres han d’aterrar en algun lloc, i aquest lloc no pot ser una altra crida al model, perquè ja ets a la branca on les crides al model han fallat.

La segona cosa és que el prompt del mateix router no és gratis. Per triar un model, un router necessita un catàleg de models on triar, i cada element que conté és entrada que el router paga abans d’haver llegit la pregunta de l’usuari. A la tarifa d’entrada amb què aquest curs posa preus, un catàleg d’uns 3.800 tokens ja costa tant com tota l’execució de l’agent de cinc crides de la taula inicial. A la pràctica, la crida de routing s’executa en un model barat, que és justament el motiu pel qual el routing es paga sol; però val la pena fer l’aritmètica en aquesta direcció en comptes de donar-ho per fet. El routing és incorrecte precisament quan la tasca encaminada és més barata que la decisió d’encaminament.

Anthropic divideix aquest patró en dos: seccionament —«dividir una tasca en subtasques independents executades en paral·lel»— i votació —«executar la mateixa tasca diverses vegades per obtenir sortides diverses».¹ Comparteixen diagrama i gairebé res més.

El seccionament és la victòria barata, i és la línia de patterns.ts: tres especialistes —facturació, fiscalitat, política— cadascun amb la seva finestra i eines, sobre el mateix correu, i una crida de síntesi al final. Feina idèntica, ordenada de dues maneres:

El mateix token per token, 1,8 vegades més ràpid. Per això el patró es guanya un nom propi: és l’únic dels cinc que millora alguna cosa sense costar res. El problema és que les seccions han de ser realment independents: dona a la secció B un fet que produeix la secció A i Promise.all les executa totes dues contra un estat que encara no existeix. El bucle for amagava aquest bug; la línia única l’exposa.

La votació és un altre animal que porta el mateix dibuix. Executar la mateixa pregunta k vegades i prendre la majoria és self-consistency, publicada per Wang et al. el març de 2022 com a estratègia de decodificació, gairebé tres anys abans que ningú en digués patró d’orquestració. El seu resum és precís sobre el mecanisme —«primer mostra un conjunt divers de camins de raonament en comptes de prendre només el greedy, i després selecciona la resposta més consistent marginalitzant els camins de raonament mostrejats»— i sobre el guany: +17,9 punts a GSM8K.²

D’aquí se’n deriven dues coses que el dibuix amaga. Primer, la votació requereix el mostreig del capítol 17: a temperatura zero totes les k mostres són la mateixa mostra, i la majoria és una resposta pagada k vegades. Segon, només funciona quan una majoria té sentit: a la resposta de factura de sobre no hi ha res a comptar, perquè cinc esborranys són cinc frases diferents. La votació és per a tasques amb una resposta curta i comparable, que és exactament el cas dels benchmarks de Wang i gairebé res del que fa un agent orientat al client.

Mesurat aquí en 20 problemes verbals de tres passos les respostes dels quals es calculen en comptes de jutjar-se, amb el model local del capítol 23 raonant pas a pas:

Cinc vegades les crides, cinc vegades els tokens, exactament cinc vegades la factura, i ni una sola resposta correcta addicional. La votació és una aposta, no una millora, i aquesta execució la va perdre.

Dues cauteles, abans que algú citi això com una refutació de Wang. Vint proves no poden distingir el 45 % del 60 %: l’interval té l’amplada de l’afirmació, que és la disciplina del capítol 4 aplicada al meu propi resultat. I els guanys publicats venen de models ordres de magnitud més grans, on els camins de raonament diversos sobre els quals la votació marginalitza són realment diversos. El que es transfereix no és la xifra: és que el multiplicador és exacte i conegut per endavant, mentre que el guany no ho és.

En el flux de treball orquestrador-treballadors «un LLM central descompon dinàmicament les tasques, les delega a LLMs treballadors i en sintetitza els resultats», i la diferència respecte del seccionament és que «les subtasques no estan predefinides, sinó determinades per l’orquestrador».¹ El llinatge aquí no ve gens dels models de llenguatge: això és master-worker, i la versió en què els treballadors escriuen troballes en un espai compartit que un controlador llegeix és l’arquitectura blackboard, de la recerca en reconeixement de parla dels anys setanta. El que és nou el 2026 és que el controlador és un model i, per tant, la descomposició es pot decidir per entrada: la flexibilitat i el cost, en una sola frase.

Va costar 12 crides al model contra les 5 de l’agent únic, i va arribar al mateix veredicte. Després va fer una cosa que val la pena mirar de prop:

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

Totes dues són correctes. Només una sap per què. El treballador fiscal tenia la factura, la comanda i la taula fiscal a la seva pròpia finestra, va arribar a la conclusió, i també va adonar-se —ningú l’hi havia demanat— que el número de comanda de compra de la factura no coincideix amb el de la comanda. Després va tornar un resum. L’orquestrador pot repetir totes dues afirmacions i no comprovar-ne cap, perquè l’evidència es va quedar en una finestra que no va veure mai. Aquesta és la pregunta final del capítol 24, resposta: el pare pot mirar el que el fill hagi triat escriure.

La solució és un flag, i té un preu:

Dotze per cent més de tokens d’entrada, 8,3 % més diners, i la frase source=worker_unverified desapareix de la resposta. Aquest és l’intercanvi en tot sistema multi-agent i gairebé mai s’explicita: la finestra neta del fill val la pena, la capacitat del pare d’auditar-la val la pena pagar-la, i no pots tenir totes dues coses gratis.

Així doncs, quan s’equivoca orquestrador-treballadors? Aquí, en aquesta tasca. Va comprar una resposta correcta a la qual un agent amb les mateixes quatre eines també va arribar, per 1,66 vegades el cost i 2,3 vegades el temps real, i va fer que aquesta resposta fos més difícil de defensar. La pròpia guia d’Anthropic ho diu abans de començar amb els patrons: cal trobar «la solució més simple possible, i només augmentar la complexitat quan calgui», perquè «els sistemes agentic sovint intercanvien latència i cost per un millor rendiment de la tasca».¹ Les taules de sobre són aquesta frase amb números a sota.

Una crida genera, una altra avalua, i el bucle es repeteix fins que l’avaluació passa.¹ Els antecedents publicats són Self-Refine —el mateix model com a «generador, refinador i proveïdor de feedback», amb una millora reportada d’uns 20 punts absoluts de mitjana en set tasques³— i Reflexion, que desa la crítica en un buffer episòdic entre intents i reporta un 91 % pass@1 a HumanEval quan la línia base arribava al 80 %.⁴

El model de costos és el més simple dels cinc: dues crides per ronda, i el nombre de rondes no és teu. Tres rondes de refinament en una tasca que trigava una crida són sis crides, així que el sòl del patró és 6× i el sostre és el límit que hi posis: això fa que la sortida per pressupost del capítol 23 sigui obligatòria, no decorativa.

El sostre és més subtil, i és mesurable. En els mateixos 20 problemes, el model local en va respondre 9 correctament. Després se li va mostrar cadascuna d’aquelles respostes i se li va demanar si era correcta —sense dir-li que la resposta era seva, cosa que elimina el confusor de l’adulació i deixa el de la capacitat:

És un jutge millor del que implica el títol de la secció, i dir-ho és el sentit de mesurar en comptes d’afirmar: no va bloquejar res correcte i va caçar 8 d’11 errors. Com a filtre, val les seves crides.

Com a regla d’aturada, que és per a què realment fa servir això un bucle avaluador-optimitzador, aquestes tres aprovacions són tota la història: acaben el bucle amb una resposta incorrecta a la mà, i cap nombre de rondes addicionals hi arriba mai. Un bucle de refinament no pot arribar a ser més correcte que el seu jutge. Comprar més rondes compra intents sobre els errors que el jutge pot veure, a preu complet, i res de res contra els que no pot veure.

D’aquí la regla: un avaluador es guanya les crides només quan té alguna cosa que el generador no té. Un compilador, una suite de tests, un validador d’esquema, un model diferent, un humà. Els resultats de Self-Refine es mesuren contra preferència humana i mètriques de tasca, mai contra l’opinió del model sobre si mateix. Si l’únic avantatge del teu avaluador és un prompt diferent, estàs pagant el doble per acord. El capítol 29 construeix la versió amb un avantatge real: un conjunt daurat amb les respostes escrites per endavant.

Els cinc de sobre són formes per al teu codi. A sota hi ha una segona família que sovint es llista al costat i no s’hauria de fer: ReAct, Reflexion, plan-and-execute i tree of thoughts són bucles de raonament, i el seu cost és en sol·licituds.

El capítol 12 tractava del raonament dins del model, que pagues en tokens de sortida en una crida. Aquest és l’altre tipus. La diferència importa quan arriba la factura: una chain of thought més llarga fa una crida més cara, i un bucle de raonament converteix una tasca en moltes crides, cadascuna de les quals reenvia tot el que hi havia abans: el quadràtic que el capítol 23 va mesurar a la seva taula desbocada.

L’article de tree-of-thoughts publica la seva pròpia taula de costos, cosa més rara del que hauria de ser. A Game of 24 amb GPT-4: input/output prompting best-of-100 va resoldre el 33 % a $0.13 per cas, chain of thought best-of-100 va resoldre el 49 % a $0.47, i tree of thoughts va resoldre el 74 % a $0.74, amb els autors assenyalant que «podria requerir 5-100 vegades més tokens generats que CoT».⁷

Gairebé sis vegades el preu del mètode barat per una mica més del doble de taxa d’èxit. Que sigui una ganga depèn de què et costi un cas fallit: la pregunta que cal fer abans d’adoptar qualsevol d’aquests quatre.

Aquest curs no els reimplementa. Tots quatre tenen implementacions de referència dels seus propis autors, en Python, i el seu valor és ser la font en comptes d’una traducció: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm i AGI-Edgerunners/Plan-and-Solve-Prompting. Llegeix els prompts d’aquests repositoris; els prompts són els articles.

Ara sí, multi-agent pròpiament dit, on viu la major part de la confusió. Hi ha dues maneres perquè un agent n’impliqui un altre, no són variants, i la diferència és qui mana després.

Agent com a eina. El pare el crida, rep una resposta i continua. És la interfície d’eina del capítol 18 amb un agent sencer al darrere, i el pare no perd mai el control. Això és el que fa l’orquestrador de sobre.

Handoff. El pare traspassa la conversa i no la recupera. La guia d’OpenAI és la declaració publicada més clara: els handoffs són «una transferència en un sol sentit que permet a un agent delegar en un altre agent... Si un agent crida una funció de handoff, immediatament comencem l’execució en aquell nou agent al qual s’ha fet el handoff, alhora que transferim l’últim estat de la conversa».⁸

Un avís de vocabulari, perquè això fa ensopegar la gent constantment: «handoff» és la paraula d’un SDK, no un estàndard. És terminologia de l’OpenAI Agents SDK i d’aquella guia, que també anomena les dues disposicions «manager» i «decentralized» i assenyala que en el patró manager «les arestes representen crides a eines mentre que en el patró decentralized, les arestes representen handoffs».⁸ En aquest espai hi ha un estàndard obert —A2A, a la versió 1.0.0, sota copyright de la Linux Foundation, amb un historial de versions i una llista documentada de canvis incompatibles, el principi declarat del qual és execució opaca: els agents «col·laboren basant-se en capacitats declarades i informació intercanviada, sense necessitat de compartir els seus pensaments interns, plans o implementacions d’eines».⁹ Això no és un handoff, i la comparació pertany al capítol 26. El que importa aquí és que una de les dues paraules és l’API d’una biblioteca i l’altra és una especificació amb governança.

La distinció és una estructura de dades, no un 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;
}

Vint línies, dos bugs que altrament trobaries a producció. reachable troba l’agent al qual ningú pot arribar: configurat, pagat, mai cridat. conflicts rebutja l’aresta que és de tots dos tipus alhora, cosa que sona pedant fins que ho llegeixes en veu alta: el pare alhora conserva el control i el cedeix. Executa-ho en un sistema de cinc agents amb un orfe i una aresta doble:

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

Ara la mesura per la qual existeix aquesta secció, i l’única del capítol presa contra un model real en comptes d’un amb script.

Un client indica una restricció en el seu primer missatge —el nostre compte està registrat a Portugal, no a Espanya; tot el que sigui fiscal ha d’usar Portugal— xerra d’una altra cosa, i després fa una pregunta que facturació ha de respondre. El cas es transfereix. Vint-i-quatre proves, un país i una empresa diferents cada vegada, quatre payloads de transferència, i després es fa una pregunta a l’agent receptor: a quin país està registrat el compte d’aquest client?

La tercera fila és un control i es comporta com a tal: el fet no hi és, així que no es pot recordar. Les altres tres són la troballa.

La transcripció completa té 173 tokens i funciona el 83 % de les vegades, amb quatre fallades que són el tema del capítol 24 més que no pas d’aquest. El registre tipat té 69 tokens —set més que el resum— i funciona cada vegada, perquè la restricció és en un camp amb nom en comptes d’una frase.

I el resum és la fila que cal mirar fixament. Va fallar 24 vegades de 24, i el motiu no és que el lector se’l perdés. La restricció només apareixia en 1 dels 24 resums. L’agent receptor no va ser descuidat; li van donar un text que no contenia la resposta. Un resum és una compactació que tu no has escrit, produïda per un model la finestra del qual no pots veure, optimitzada perquè llegeixi com un resum —i «el client diu que els nostres registres tenen el país equivocat» és exactament el tipus de clàusula que un resumidor descarta com a soroll procedimental.

Un límit honest sobre aquesta xifra: el resumidor és un model de mig miler de milions de paràmetres i un de més gran en conservaria més. El que no millora amb la mida és la forma del risc: l’agent emissor decideix, per handoff, per formulació, de manera no observable, quins fets sobreviuen. El registre tipat no depèn gens d’aquest judici, i per això guanya per construcció en comptes de per intel·ligència. Tot el que hagi de sobreviure a una transferència hauria de ser un camp, no una frase.

El mateix raonament s’aplica en l’altra direcció, a la topologia agent-com-a-eina, i la taula anterior ja n’ha posat preu: el que torna d’un treballador també és un resum, i pagar un 8,3 % més per rebre’n l’evidència és la mateixa solució vista des del costat del pare.

Tres fets finals, tots de les taules anteriors.

Un sistema multi-agent multiplica les crides, i les crides són quadràtiques en el context. L’orquestrador va fer 12 crides al model on un agent en va fer 5, i cadascuna carrega la seva pròpia transcripció creixent: 3.628 tokens d’entrada contra 2.697, una diferència que s’eixampla amb la llargada de la tasca.

Cada frontera és un canal amb pèrdua. Dos agents vol dir un resum. Quatre agents en una cadena vol dir tres, compostos, cadascun escrit per un model optimitzant per alguna cosa que no és la teva decisió.

L’agent únic va trobar una cosa que ningú havia demanat. La discrepància de la comanda de compra va aparèixer perquè una finestra contenia alhora la factura i la comanda. Dividir la feina entre especialistes també divideix la capacitat d’adonar-se que dos fets discrepen.

Res d’això argumenta contra els frameworks multi-agent publicats, que val la pena llegir com a fonts primàries i no a través de tutorials.¹⁰ Argumenta a favor de fer que el segon agent es guanyi el seu lloc.

Així doncs, una prova en comptes d’una preferència. Afegeix un segon agent quan almenys una d’aquestes coses sigui certa: la subtasca necessita una finestra neta que el pare no ha d’heretar (capítol 24); les subtasques són realment independents i el temps real importa, que és l’1,8× de sobre; la subtasca necessita permisos diferents o un model diferent, cosa que el capítol 30 converteix en un argument de seguretat; o la subtasca és propietat d’algú altre, que és on un protocol real comença a importar. Si la resposta és «perquè cada agent tingui un prompt més clar», dona a l’agent únic un prompt més clar. És gratis.

Ara pots anomenar els cinc patrons, posar-los preu els uns contra els altres en una tasca, distingir un orquestrador d’un seccionador i una crida d’eina d’un handoff, i defensar un agent únic amb una taula en comptes d’una preferència.

Totes les disposicions d’aquí compartien una comoditat que no sobreviurà al contacte amb res real: totes les eines eren nostres. Factura, comanda, taula fiscal, els treballadors darrere de l’orquestrador: mateix repositori, mateix deploy, mateixos tipus, mateixa gent.

Ara posa’n una a l’altra banda d’una frontera d’empresa. La taula fiscal pertany a un proveïdor comptable, el registre de comanda a un sistema de magatzem, i cap dels dos ha llegit la teva interfície Tool. Necessites una manera perquè un model que no has escrit descobreixi, descrigui i cridi una capacitat que opera algú altre, amb autenticació (que és la meitat del capítol 27), versionat, i la garantia que un servidor no pot llegir la resta de la teva conversa. Això és un problema de protocol, té una especificació amb un esquema normatiu, i gairebé tot el que hi ha indexat sobre ell descriu una revisió que ja no existeix.

El capítol 26 llegeix aquesta especificació en comptes de resumir-la, i comença escrivint JSON-RPC a mà en un terminal.

Cada cost i recompte de tokens de sobre prové del proveïdor amb script descrit a la segona secció, sobre Node 22 a través d’una interfície loopback, comptant amb la codificació o200k_base i amb preus segons les tarifes que el capítol 16 va llegir el 6 de setembre de 2026: $2.00 per milió de tokens d’entrada i $12.00 per milió de sortida. Les xifres de temps real provenen de les mateixes execucions amb la latència del proveïdor fixada a 400 ms per crida i les eines a 50 ms, així que mesuren la disposició més que cap proveïdor. Les dues mesures amb model real —la taula de handoff i la taula de votació-i-judici— van usar Qwen/Qwen2.5-0.5B-Instruct en float32 a la CPU darrere d’un endpoint amb la mateixa forma, greedy excepte quan s’indica una temperatura, amb intervals calculats pel mètode de Wilson del capítol 4. Cap sol·licitud d’aquest capítol va anar a un endpoint de pagament, i cap xifra que hi surt es va estimar.