«Graph engineering» per a agents d’IA: què és i què exagera el vídeo
Els grafs poden coordinar agents en paral·lel, però 100 agents no garanteixen qualitat ni baix cost. Verifiquem Claude Code, LangGraph i els càlculs.
En resum
El vídeo de Caleb Writes Code presenta la graph engineering —enginyeria de grafs— com una nova etapa en el desenvolupament d’agents d’intel·ligència artificial. La idea consisteix a representar un treball complex com un conjunt de nodes connectats: cada node executa una tasca o un agent, i les arestes determinen com circulen les dades i quan s’activa el pas següent.
La intuïció és útil. Quan un problema es pot dividir en investigacions independents, diversos agents poden treballar en paral·lel, cadascun amb el seu context, i un coordinador pot sintetitzar-ne els resultats. Anthropic utilitza precisament un patró d’orquestrador i treballadors en el seu sistema de recerca multiagent.
Tanmateix, el vídeo converteix aquesta tendència en una narrativa massa lineal:
- els grafs i els sistemes multiagent no són nous;
- no hi ha una definició industrial única de «graph engineering»;
- Claude Code admet subagents i equips, però la documentació no diu que una consulta de recerca generi sempre, de manera automàtica, un programa JavaScript de 427 línies i més de cent agents;
- més paral·lelisme no implica necessàriament menys temps, menys cost o més qualitat;
- el càlcul de costos només funciona sota hipòtesis concretes de tokens i memòria cau;
- els nodes actuals són més capaços, però continuen cometent errors i la coordinació també pot amplificar-los.
La conclusió pràctica és menys espectacular però més útil: un graf és una eina d’orquestració, no una garantia de fiabilitat.
Què és un graf en aquest context
Un graf està format per nodes i arestes. El vídeo recupera el problema dels set ponts de Königsberg, resolt per Leonhard Euler el 1736: en abstraure masses de terra com a nodes i ponts com a arestes, Euler va demostrar que no era possible creuar tots set ponts exactament una vegada.
En un sistema d’IA, un node pot ser:
- una funció determinista;
- una consulta a un model;
- una cerca web;
- una validació;
- una intervenció humana;
- o una execució completa d’un agent amb eines.
Les arestes expressen dependències i transicions. Poden dir «després de planificar, llança tres cerques», «si la validació falla, torna a redactar» o «no continuïs fins que una persona ho aprovi».
Un DAG és un graf dirigit acíclic: les connexions tenen direcció i no hi ha cap camí que torni a un node anterior. Un pipeline que va de planificació a cerca, verificació i síntesi pot ser un DAG. Però LangChain recorda que molts agents de producció necessiten cicles per repetir una eina, corregir un error, demanar informació o revisar una resposta. Per això, graf no és sinònim de DAG.
La «graph engineering» és real, però el nom és nou
El terme ha guanyat visibilitat el 2026, però descriu decisions conegudes d’orquestració, màquines d’estats, workflows i sistemes distribuïts. La mateixa entrada de LangChain titulada «3 Years of Graph Engineering with LangGraph» qualifica l’etiqueta de paraula de moda, tot i defensar que identifica problemes reals.
La cronologia ajuda a evitar la impressió que tot acaba d’aparèixer:
- Microsoft va publicar AutoGen el setembre de 2023 com a marc obert per construir aplicacions mitjançant converses entre diversos agents.
- LangChain va anunciar públicament LangGraph a principis de 2024 per introduir cicles en els runtimes d’agents; l’empresa afirma que el treball previ es remunta a tres anys enrere.
- Anthropic va descriure patrons com encadenament de prompts, encaminament, paral·lelització, orquestrador-treballadors i avaluador-optimitzador el 2024.
- El 2025, Anthropic va explicar l’arquitectura multiagent del seu producte Research i va publicar dades internes de rendiment i consum.
- Claude Code ofereix avui subagents i equips d’agents, però els equips continuen documentats com una funció experimental i desactivada per defecte.
El que ha canviat no és l’existència dels grafs. Han millorat els models, els entorns d’eines, la persistència, els sistemes de permisos i els agents de programació. Això permet que un node contingui una feina més llarga i autònoma que una simple crida al model.
Què mostra exactament la demostració
El vídeo ensenya un flux de recerca generat en JavaScript. Segons l’autor, inclou aproximadament:
- un agent per delimitar la petició;
- cinc agents per localitzar fonts;
- vint-i-cinc agents per recuperar informació;
- setanta-cinc agents per verificar i votar la credibilitat;
- un agent final per redactar l’informe.
Aquests passos sumen 107 treballadors; amb un possible orquestrador separat, el total seria 108. El vídeo diu que Claude Code crea un workflow nou per a cada petició i que, en l’exemple, el runtime té 427 línies.
La demostració pot ser autèntica dins de la configuració de l’autor, però no permet establir que sigui el comportament general de Claude Code. La documentació oficial confirma que:
- els subagents tenen context i instruccions propis;
- es poden executar en primer pla o en paral·lel;
- els equips coordinen sessions independents mitjançant una llista de tasques i missatges;
- els equips afegeixen cost de coordinació i molts més tokens;
- la funció d’equips és experimental i s’ha d’activar.
Per tant, la formulació rigorosa és: Claude Code pot formar part d’un sistema dinàmic multiagent, però la quantitat d’agents, les fases i el codi generat que es veuen al vídeo corresponen a una implementació concreta, no a una propietat universal demostrada.
Verificació de les afirmacions principals
| Afirmació del vídeo | Veredicte | Matís necessari |
|---|---|---|
| Els grafs tenen l’origen clàssic en el problema de Königsberg | Correcta | Euler va convertir terres i ponts en una abstracció de nodes i arestes. |
| El flux lineal mostrat és un DAG | Correcta | Ho és si cap transició torna enrere; molts agents reals, però, necessiten cicles. |
| Claude Code genera més de 100 agents per a una recerca | No generalitzable | Pot ser la demo o un harness propi; la documentació oficial no estableix aquest comportament per defecte. |
| Els agents separats tenen context propi | Correcta | Aporta especialització, però també duplica instruccions i fragmenta informació. |
| Anthropic mesura 4× i 15× més tokens | Correcta amb context | Són dades internes: agents contra xats i sistemes multiagent contra xats, no una llei universal. |
| 108 agents amb 20.000 tokens costen prop de 10 $ d’entrada | Coherent | Amb Opus 5 serien 2,16 milions de tokens, és a dir, 10,80 $ a tarifa base. |
| Amb memòria cau el cost baixa prop d’1 $ | Possible en un cas ideal | Exigeix que gairebé tot sigui reutilitzable com a cache hit; no inclou escriptures de memòria cau, sortides, eines ni prompts variables. |
| AutoGen va popularitzar fluxos multiagent el 2023 | Correcta | Microsoft el va publicar el setembre de 2023. |
| LangGraph ja operava amb grafs el 2023 | Imprecisa | El projecte deriva de feina anterior, però l’anunci públic de LangGraph és de 2024. |
| El coll d’ampolla s’ha mogut dels nodes a les arestes | Tesi plausible, no fet universal | La qualitat del model, les eines i el context continuen sent colls d’ampolla. |
Quan el paral·lelisme ajuda
Anthropic explica que el seu sistema Research utilitza un agent principal que planifica, crea subagents per explorar direccions diferents i després en resumeix els resultats. En una avaluació interna, la configuració multiagent va superar en un 90,2% un agent únic en una prova de recerca. La dada és rellevant, però correspon a un benchmark i una arquitectura concrets.
Els grafs són especialment adequats quan:
- hi ha moltes branques realment independents;
- cal cobrir fonts o hipòtesis diverses;
- la informació total no cap còmodament en un sol context;
- cada branca té una especialitat clara;
- el valor del resultat justifica més consum;
- es pot validar i combinar cada sortida.
Per exemple, una investigació sobre vint empreses es pot repartir per empreses. Una revisió de seguretat pot separar autenticació, dependències i infraestructura. Un procés editorial pot combinar recopilació, contrast, redacció i control final.
Quan un graf empitjora el sistema
No tota tasca es divideix bé. Anthropic adverteix que molts treballs de programació tenen menys paral·lelisme real que la recerca i que els agents encara no coordinen ni deleguen perfectament en temps real.
Un graf pot ser contraproduent quan:
- les tasques depenen fortament les unes de les altres;
- tots els agents necessiten la mateixa informació actualitzada;
- diversos agents editen el mateix fitxer o registre;
- la feina és tan petita que l’orquestració costa més que l’execució;
- no hi ha un criteri objectiu per reconciliar respostes;
- una errada inicial es replica a desenes de branques;
- el límit de peticions o el pressupost anul·len l’avantatge de temps.
Cent agents no equivalen a cent perspectives independents si tots comparteixen el mateix model, el mateix prompt i les mateixes fonts. El «vot» de setanta-cinc verificadors tampoc converteix una afirmació en certa: els errors poden estar correlacionats i una majoria pot repetir la mateixa al·lucinació.
El cost: què demostra el càlcul i què omet
La pàgina oficial de preus d’Anthropic situa Claude Opus 5 en 5 dòlars per milió de tokens d’entrada, 25 dòlars per milió de sortida i 0,50 dòlars per milió d’entrades recuperades de la memòria cau.
Amb les hipòtesis del vídeo:
- 108 agents × 20.000 tokens = 2.160.000 tokens d’entrada;
- a 5 $/milió, l’entrada base seria de 10,80 $;
- si els 2,16 milions fossin encerts de memòria cau, serien 1,08 $.
La primera operació és correcta. La segona és un límit ideal, no una factura probable sense dades d’ús. La memòria cau només abarateix prefixos idèntics que ja s’han escrit; els objectius, resultats previs i contextos de cada agent poden variar. A més, s’han de comptar:
- el cost inicial d’escriure la memòria cau;
- els tokens de sortida;
- les cerques i altres eines facturables;
- reintents i errors;
- el coordinador i la síntesi final;
- prompts que creixen amb els resultats;
- possibles tarifes regionals o del proveïdor.
La manera correcta de pressupostar és instrumentar cada execució i mesurar tokens d’entrada, cache writes, cache reads, sortida, eines, latència i taxa d’èxit.
Separar context és útil, però no gratuït
El vídeo defensa que cada agent pot concentrar el context en un objectiu petit. És cert: una branca que només verifica dates no necessita carregar tota la redacció. La separació també evita que cerques sorolloses saturin el fil principal.
Però apareixen altres problemes:
- cal decidir quina informació rep cada agent;
- els descobriments d’una branca poden no arribar a les altres;
- resumir implica pèrdua de detall;
- duplicar instruccions consumeix tokens;
- el coordinador necessita procedència per resoldre contradiccions.
Per això, una arquitectura sòlida no passa només text lliure. Cada node hauria de retornar dades estructurades: afirmació, font, fragment de suport, data, confiança, estat de verificació i errors.
Nodes més capaços, arestes més importants
La millor part de la tesi és que els nodes moderns poden executar una feina completa: llegir fitxers, utilitzar eines, escriure codi, provar-lo i informar. Això fa viable incrustar un agent de programació dins d’un flux més ampli.
Però dir que els nodes ja són «fiables» és excessiu. Continuen existint errors de raonament, ús incorrecte d’eines, instruccions mal interpretades i vulnerabilitat a contingut hostil. Les arestes també són més que fletxes en un diagrama: inclouen contractes de dades, permisos, condicions, límits, reintents, idempotència i regles de cancel·lació.
La graph engineering madura consisteix a decidir:
- què ha de ser determinista i què pot decidir un model;
- quines branques es poden llançar i amb quin màxim;
- quines dades travessen cada connexió;
- com es detecten duplicats i contradiccions;
- quan s’atura un bucle;
- què passa si un node falla;
- on és obligatòria l’aprovació humana.
El patrocini de Zo Computer
El vídeo interromp l’explicació per presentar Zo Computer i identifica explícitament la marca com a patrocinadora. La documentació oficial confirma que Zo ofereix un entorn personal al núvol, fitxers, webs allotjades, automatitzacions i interacció per text o correu. Els plans de pagament mantenen el còmput actiu i inclouen més recursos.
La presentació de «més propietat» necessita context. Zo diu que l’usuari conserva la titularitat del contingut i que els fitxers utilitzen formats portables, però el servei continua depenent d’infraestructura i proveïdors externs. La seva pàgina de seguretat enumera Modal, Neon, Upstash, Cloudflare i diversos proveïdors d’inferència; també reconeix que fragments o fitxers complets poden enviar-se al model seleccionat.
La mateixa documentació adverteix que donar a una IA accés ampli a un ordinador al núvol comporta riscos. Abans de connectar contactes, fitxers o dominis, convé revisar permisos, secrets, còpies de seguretat, retenció de missatges, proveïdors de models i la possibilitat de limitar accions.
Checklist per portar un graf d’agents a producció
- Comença amb un agent. Afegeix branques només quan una mètrica mostri que resolen un límit real.
- Defineix el contracte de cada node. Entrada, sortida, eines, permisos, temps màxim i error esperat.
- Limita el fan-out. Estableix màxim d’agents, tokens, cost, durada i profunditat.
- Reserva el paral·lelisme per a feina independent. Les dependències fortes han d’anar en seqüència.
- Exigeix procedència. Cada afirmació ha d’arribar amb la font i el fragment que la sosté.
- No utilitzis vot simple com a veritat. Diversifica mètodes i valida contra dades externes.
- Implementa reintents idempotents. Repetir un node no ha de duplicar correus, pagaments o canvis.
- Afegeix punts humans. Especialment abans d’accions irreversibles o d’alt impacte.
- Traça cada transició. Model, prompt, versió, tokens, eines, latència, resultat i error.
- Avalua el sistema complet. Qualitat, cobertura, cost i temps contra una línia base d’un sol agent.
Conclusió
La graph engineering és una etiqueta recent per a una disciplina antiga que ara adquireix més importància: orquestrar components probabilístics i agents amb eines. El vídeo explica bé els nodes, les arestes, els DAG i els avantatges de separar context i paral·lelitzar recerca.
El que exagera és el grau d’automatisme i maduresa. La demo de més de cent agents no representa necessàriament Claude Code per defecte; els costos reals necessiten telemetria; i les mateixes fonts citades reconeixen que coordinar agents continua sent difícil.
La pregunta adequada no és «quants agents podem generar?», sinó quin és el graf més petit que millora de manera mesurable el resultat sense perdre control, traçabilitat ni pressupost.
Contrast i context
Fonts consultades
-
01
Caleb Writes Code Graph Engineering explained in 8min..
- 02
-
03
LangChain LangGraph overview
-
04
LangChain Introducing LangGraph
- 05
-
06
Anthropic Building effective agents
-
07
Claude Code Docs Create custom subagents
-
08
Claude Code Docs Orchestrate teams of Claude Code sessions
-
09
Claude Platform Docs Pricing
-
10
Microsoft Research AutoGen: Enabling next-generation large language model applications
-
11
Zo Computer Introduction
-
12
Zo Computer Security
-
13
Zo Computer Subscription
Font de treball
Transcripció amb marques de temps
Consulta la transcripció
-
0:00
, obre el vídeo en una pestanya nova
When we ask Claudecode to do a deep research about a specific topic, behind the scenes, it's not just one agent that handles the entire research, but many agents are spawned to handle our research needs. Claudecode actually generates a dynamic workflow that looks something like this, where you have over 100 agents broken into various phases. And this entire workflow is generated on the fly by Claudecode in JavaScript code, like you can see here. That's 427 lines of code, and this very code acts as a runtime environment that will spawn over 100 agents. And every new request that I send, Claudecode will generate a fresh new workflow, and each workflow will spawn different numbers of agents. So, given our example here of JavaScript file, where Claudecode essentially converted my research plan into a workflow as a runtime, Claudecode will then start launching many agents in five different phases. And each phase of the workflow will more or less work in parallel, and each agent has its own context window and its own system prompt. Pretty neat, right? Now, building on this workflow that you can see here, the concept for graphs has been resurfacing lately, as if it's a next natural progression in our agentic engineering. So, we asked the natural question, what exactly is graph engineering? The idea of graphs dates all the way back to 1736, when a Swiss polymath, Leonhard Euler, was considering solving the strange question in a city called Königsberg. They have two mainlands and two islands and seven bridges connecting them. And the question was simple, is there a route through the city that crosses every single bridge, but only exactly once? Now, you might try and hypothesize a way by process of elimination. Maybe you can start here and try to cross the bridge this way, or maybe you just start on the island instead and start out and see if there's another way possible, and you'll soon realize that this is not possible. Euler agreed, but it's not just that this wasn't possible, but how Euler simplified the problem into a simple concept shown in this diagram. Circles are nodes, which in this case were land, and the black lines are edges, which are bridges in this case, and these two constitute a graph. So, this middle island here has five edges, or bridges in this case, connecting to other areas, and so on. And given this representation, Euler concluded with a proof that this kind of route in Königsberg is impossible. Now, the exact proof that Euler proposed is sort of irrelevant to this video, but Euler's graph theory is now applied to agents and graph engineering today. Here's another way to visualize the workflow that Claude code generated for my deep research from earlier. This consists of five phases. One agent for scoping the requirement, five agents to gather credible websites to research for each subtopics, 25 agents to then actually fetch the information and pass it to the next, and 75 agents to verify the facts and vote on the credibility, and finally, one agent that generates the full report in the end. And this workflow you're seeing here is a form of a graph. In this case, because execution only flows from left to right, with no node going backwards, which would form a loop, this is called DAG, or directed acyclic graph. Now, we could technically do this with a single agent instead of hundreds of agents in a graph like we just saw earlier. But this would be a bit silly because using a dynamic workflow for this kind of work is better for many reasons. The most obvious one being time. By parallelizing task into sub-agents that have their own small objective, this helps save a large amount of time by the simple fact that multiple agents are working at the same time. Another benefit is separation of concerns. The fact that each agent has its own context window helps focus its own context window towards its goal. Whereas a single agent might need to keep reusing its own context to store some of it for the goal, some of it for the current task and keep summarizing back and forth. But graphs aren't
-
3:57
, obre el vídeo en una pestanya nova
without its drawbacks either. Anthropic made a post that talked about their multi-agent research system that said a single agent tends to use four times more tokens than a regular chat and a multi-agent system tends to use 15 times more tokens in comparison. So going back to our example, each agent ran on Opus 5 with their own system prompt and each agent used about 20,000 tokens by default to start. So by the time you extrapolate this to 108 agents that it eventually used, the input cost alone would be closer to $10 given Opus 5's pricing. But since we have prompt caching, realistically, this number will look closer to a dollar which helps scale our agent from a single agent to a parallel agents like you can see here. So given the benefits and the drawbacks when it comes to graphs, why are everyone talking about graph and graph engineering as if it's the next evolution when it comes to agentic engineering? But first, a quick word from Zoe sponsoring this video. It's pretty obvious that more and more parts of our lives are being integrated with AI and often our interactions are scattered across Claude, ChatGPT, Codex and Menace. So how can we have more ownership while having a 24/7 agent? Zoe gives you a dedicated computer on the cloud that's yours, meaning your agent is on standby for anything that you give. And part of being 24/7 is the ability to message your agent through text. You can directly message Zoe to have normal conversations through iMessage or ask about files that you have stored on your computer in the cloud and better yet, build an e-commerce website for vintage watches and host directly on Zoe using their AI agent natively through text. What's cool about Zoe is that you can write code and launch sites that are actually useful because you can integrate all your contacts into Zoe and run automations. Custom domains are also included at paid plan and all your sites are hosted on your Zoe's cloud computer. Plus they got some neat tricks like the selector tool to edit exact areas to improve things or even add automations that plug into your website, like a text anytime someone fills out a form. Try Zo today. I'll have the link in the description below. The concept behind agent communicating with another agent is not anything new. We can look back to open-source ideas like AutoGen in 2023 from Microsoft talking about agents communicating with another agent. Companies like LangChain also started messing with cyclic graph in 2023, which led to LangGraph, which became a framework for orchestrating agents. Anthropic also released various ways that agents can work together around the same time, like prompt chaining where LLMs are chained sequentially one after another, routing, which is similar to sub-agents, but from the perspective of the main agent, parallelization, which is similar to our deep research workflow, orchestrator, also similar to what we saw earlier, and evaluator optimizer, where two LLMs adversarially go at each other until a condition is met. But, none of these were materially useful back then because the problem wasn't so much in the graph itself, but what the node inside of the graph can actually do. In LangChain's blog post talking about graph engineering, they said that what changed wasn't the graph, but more in what the node can do. Back then, it was just an LLM call, nothing close to a full agent that we interact with every day like Claude Code or CodeX CLI. These agents are immensely better given their myriads of tools and harness environment. So, with the emergence of coding like Cursor, Kline, Rue, and Winster, which were one of the few early players back then when it comes to agents, they focus more on single agents in improving that very agent instead of extending them to various edges that form a graph of agents actually working together. And over time, these agents individually started to incorporate better methodologies, going from prompt engineering to context engineering, better harnessing, and now the bottleneck started to shift away from what the node can do, but into a graph and the edges that connect the nodes together. And now, no pun intended,
-
7:51
, obre el vídeo en una pestanya nova
we're coming full circle back to graphs. Because the nodes are reliable and more capable, we can now scale our agents from a single agent to a workflow or a graph to target a much wider set of problems like we saw in deep research, which would have been really difficult for a single agent to solve. So, going back to Euler's case, his challenge was to determine the feasibility of crossing all seven bridges exactly once, which led to the birth of graph theory. In our case, our adaptation of graph theory into agents is determining how a task can be divided in a way that a highly capable node now should structurally be configured to solve a much more complicated task that we give our agents to solve.
