(2/3) Tres arquitectures de loops agèntics, i què costa realment cadascuna
Pregunta a cinc proveïdors què fa el seu «sistema multi-agent» i quatre et descriuran un loop únic amb millor marxandatge.
No és una crítica al marxandatge —és el símptoma d'un buit real en com es parla d'això. La primera part d'aquesta sèrie defensava que un loop només és agèntic quan té un trigger i un objectiu que algú diferent del model pugui verificar. Això és el mínim. No diu res sobre quants models fan el raonament, si corren en seqüència o en paral·lel, ni si hi ha un supervisor llegint la seva feina abans que surti. Això són decisions d'arquitectura, i la suposició habitual —més agents, més avançat, estrictament millor— és errònia d'una manera concreta i mesurable: l'arquitectura és una corba de cost, no una escala de maduresa. Triar-ne la equivocada, o et crema un múltiple del pressupost de tokens sense guanyar capacitat, o et deixa capacitat real sobre la taula per estalviar-te quatre cèntims.
El loop únic: un sol model, un sol fil, sense peatge de coordinació
L'arquitectura més senzilla és exactament el que descrivia la primera part: un sol model, fent cicles de percebre-raonar-planificar-actuar-observar contra un únic objectiu, sense res més corrent al costat. És el que formalitza el patró ReAct de Yao et al., i és el valor per defecte correcte per a qualsevol tasca prou acotada perquè un sol fil de raonament pugui mantenir tota la tasca a la vista —arreglar un test concret que falla, respondre una pregunta que requereix un parell de consultes, treballar una migració acotada fitxer per fitxer. No hi ha peatge de coordinació perquè no hi ha res a coordinar. El punt de fallada no és el cost; és l'abast. Passada una certa mida de tasca, un sol fil comença a perdre el fil de decisions anteriors, a rededuir coses que ja havia esbrinat, o a no adonar-se que dos passos separats per diversos torns ara es contradiuen.
Planificar i executar: separar decidir què fer de fer-ho
La següent arquitectura trenca l'assumpció central del loop únic —que raonar i actuar s'han d'intercalar pas a pas— avançant el raonament a un pla explícit, i després executant els passos d'aquest pla, en paral·lel allà on no depenen els uns dels altres. LLMCompiler, de Kim et al. (ICML 2024), és el cas publicat més clar de per què val la pena assumir aquesta complexitat afegida: planificant les crides a eines com un graf de dependències per endavant, i executant les branques independents de manera concurrent en lloc d'esperar cadascuna abans de decidir la següent, reporten millores de latència de fins a 3,7 vegades i reduccions de cost de fins a 6,7 vegades respecte a un baseline seqüencial a l'estil ReAct en el seu conjunt de benchmarks —amb una millora de precisió afegida, no un intercanvi en contra, perquè un pas ja no ha d'endevinar què retornarà un pas anterior abans de poder començar. El mecanisme és concret: la feina paral·lelitzable no necessita raonament seqüencial entre cada peça, i un sol loop intercalat paga un cost de raonament per una serialització que no li calia.
El cost d'aquesta arquitectura és la qualitat de la planificació prèvia. Si el pla és erroni —una dependència que el planificador s'ha saltat, un pas que en realitat necessitava la sortida d'un altre— ara estàs depurant un graf en lloc d'un rastre lineal, un punt de fallada més difícil de llegir que el d'un loop únic, encara que és més rar de trobar.
Orquestració multi-agent: especialització comprada amb una factura de tokens real
L'arquitectura més allunyada del loop únic reparteix trossos d'una tasca entre diferents agents —normalment un agent principal que planifica i delega, i subagents que fan cadascun el seu propi cicle de percebre-raonar-planificar-actuar-observar sobre una porció del problema, en paral·lel, i informen l'agent principal. Anthropic va publicar xifres exactes sobre el cost d'aquest patró al seu post d'enginyeria del juny de 2025 sobre el sistema multi-agent que hi ha darrere de la capacitat de recerca de Claude: «els agents fan servir normalment uns 4 cops més tokens que les interaccions de xat, i els sistemes multi-agent en fan servir uns 15 cops més que un xat». No és una diferència d'arrodoniment —és un ordre de magnitud, i ve d'un mecanisme llegible: cada subagent re-deriva el seu propi context i escriu el seu propi rastre de raonament, i l'agent principal ha de llegir-ho i reconciliar-ho tot, així que el mateix terreny es cobreix diverses vegades en lloc d'un cop.
El mateix post reporta l'altra cara de l'intercanvi: un sistema orchestrator-worker corrent Claude Opus 4 com a agent principal amb subagents Claude Sonnet 4 va superar un baseline d'un sol agent Opus 4 en un 90,2% en la seva avaluació interna de recerca —i, en un detall que val la pena aturar-s'hi, l'ús de tokens per si sol explicava el 80% de la variància en com de bé funcionava una execució, més que la tria de model o les eines disponibles. L'exploració en paral·lel d'un espai de problema ampli és una capacitat genuïna que l'orquestració multi-agent compra i que un loop únic estructuralment no pot oferir, perquè un sol fil només pot seguir una línia de raonament alhora. Té un preu de 15 cops, i la xifra del 80% és la pista: el guany de capacitat es compra sobretot amb tokens, no amb enginy.
Un quart eix, ortogonal als altres tres: com d'a fons s'esforça un sol pas abans de respondre
L'arquitectura respon «quants agents, disposats de quina manera». Una pregunta separada és quant es qüestiona a si mateix un sol agent el seu propi resultat abans de donar un pas per acabat, i això és el que va formalitzar Reflexion, de Shinn et al. (NeurIPS 2023): en lloc d'actualitzar els pesos del model, l'agent escriu una autoreflexió verbal sobre per què un intent ha fallat, la desa en una memòria episòdica, i torna a intentar-ho amb aquesta reflexió al context. A HumanEval, això va pujar el pass@1 d'un baseline de GPT-4 en zero-shot del 80% al 91%, sense tocar el model en si. Aquesta capa és ortogonal a les tres arquitectures d'abans: pots afegir un pas d'autocrítica a un loop únic, a cada worker d'un sistema multi-agent, o a l'etapa d'execució d'un pipeline de planificar-i-executar. Compra precisió al preu de més iteracions per tasca, una factura diferent del peatge de coordinació d'afegir agents.
El 90,2% és real; el 15 també —i només una forma de tasca es guanya els dos
Aquí hi ha la concessió que els pitch decks es salten: el guany de l'orquestració multi-agent és real, però condicionat al fet que la feina sigui paral·lela de debò. Un supervisor coordinant tres subagents que només podrien haver corregut en seqüència de totes maneres paga el múltiple sencer de 15 cops en tokens i el sobrecost de coordinació —la reconciliació, la re-derivació de context— sense cap benefici, perquè mai hi va haver un espai de problema ampli per explorar de manera concurrent. La xifra del 90,2% venia d'una tasca de recerca pensada per a l'amplitud: moltes línies d'indagació independents, explorades en paral·lel, reconciliades al final. Una tasca estreta i seqüencial —del tipus que un loop únic gestiona bé— no té aquesta estructura per explotar, així que l'orquestració multi-agent hi multiplica el cost sense multiplicar res més.
Com triaria jo, en ordre
- Pot un sol fil de raonament continu mantenir tota la tasca a la vista? Si sí, comença amb un loop únic. És l'arquitectura més barata i la més fàcil de depurar, i la majoria de tasques que reben el tractament «multi-agent» no ho necessitaven.
- És la feina un conjunt de passos amb una estructura de dependències clara i majoritàriament independent? Si sí, planificar-i-executar és la següent opció —tens el paral·lelisme sense el peatge de coordinació sencer, al preu d'encertar el pla per endavant.
- La tasca requereix explorar un espai de problema ampli i desconnex que cap fil únic podria mantenir alhora? Només aleshores el múltiple de 15 compra alguna cosa que una arquitectura més barata estructuralment no pot. Si no pots anomenar l'exploració paral·lela, no estàs pagant per capacitat —estàs pagant només el peatge de coordinació.
- Per separat: importa més la correcció que la latència en aquesta tasca? Si sí, afegeix una capa d'autocrítica com la de Reflexion sobre l'arquitectura que hagis triat, i pressuposta les iteracions extra que costa.
Res de tot això sobreviu el contacte amb producció sense guardrails
Una arquitectura ben triada encara se't pot descontrolar si res limita fins on arriba, quant es gasta, o què pot fer sense que un humà hi hagi mirat primer —que és on agafa el fil la tercera part d'aquesta sèrie.
Si estàs valorant quina d'aquestes encaixa amb un sistema que estàs construint, contacta'ns.
