Graph Engineering: एक Crash Course
16 Concepts · एक loop की spine से लेकर हज़ार agents की shared graph तक
आपका loop काम करता है। वह हर सुबह 9 बजे fire होता है, harness उसे सीमाओं में रखता है और उसकी spine, एक progress.md file, कल सीखी बात आज तक पहुँचाती है। एक loop, एक memory file। इतना काफ़ी था।
अब देखें कि सफल होने के बाद क्या होता है। आप दूसरा loop जोड़ते हैं। फिर review loop। फिर किसी व्यस्त सप्ताह में 20 files का एक साथ audit करने के लिए 20 agents को fan out करते हैं। हर agent खाली context window से शुरू करता है। हर agent वही बात फिर खोजता है जो दूसरा agent एक घंटे पहले खोज चुका था। हर agent अपनी findings ऐसे transcript में लिखता है जिसे कोई दूसरा agent कभी नहीं पढ़ेगा। काम बढ़ गया, memory नहीं बढ़ी। आपने बिना shared brain वाली team बना दी।
इसी समस्या को graph engineering हल करती है। Idea एक sentence का है: agent भूलता है, graph नहीं भूलती। Agents की सीखी बातें उनके transcripts में छोड़ने के बजाय, आप उन्हें typed और connected records, यानी nodes और edges, के रूप में लिखवाते हैं जिन्हें कोई भी बाद का agent query कर सके। दो graphs यह काम करती हैं। Commit DAG काम याद रखती है: क्या try हुआ, क्या किससे निकला और क्या रखा गया। Knowledge graph facts याद रखती है: कौन-सी entities मौजूद हैं, वे कैसे जुड़ी हैं और हर claim को कौन-सा source साबित करता है। यह course दोनों सिखाता है और 2026 के सबसे साफ़ documented examples इस्तेमाल करता है: पहली के लिए Andrej Karpathy का autoresearch और AgentHub, दूसरी के लिए Anthropic की Knowledge Graph Construction Cookbook और Dynamic Workflows। और क्योंकि loops को भी wiring चाहिए, Part 5 तीसरी graph, governance graph, जोड़ता है: कौन किसे check करता है, किसका target किसके पास है और किन measurements से कोई loop बहस नहीं कर सकता।
पहले ये courses करें: Loop Engineering और Harness Engineering। Loop course ने beat, spine, maker–checker split और ratchet सिखाए। Harness course ने 5 verbs और typed output सिखाए। यह course मानकर चलता है कि आप यह सब जानते हैं। Spine एक loop की private memory थी। यह course दिखाता है कि कई agents को memory share करनी हो तो spine क्या बनती है। अगर ये शब्द नए हैं, तो पहले वे courses करें।
📚 Teaching Aid
पूरी presentation देखें: Graph Engineering: एक Crash Course
नीचे दिए 10 figures उसी क्रम में सिखाने के लिए बनाए गए हैं: हर figure केवल एक concept बताता है और slide पर अकेले समझ में आता है।
नीचे हर concept के साथ ऐसी script है जिसे केवल पढ़ना नहीं, execute करके देखना भी संभव है। इनके लिए bash, git, jq और python3 चाहिए, और कुछ नहीं: न API key, न pip install, न network।
git clone https://github.com/panaversity/agentfactory-labs.git
cd agentfactory-labs/crash-course/graph-eng
./verify.sh # runs all 17 demos and asserts each one
जब output में Everything in this course runs. आए, तो इस page के साथ folder खुला रखें। हर concept उस एक command पर खत्म होता है जो उसे दिखाती है: आप git reset को commit मिटाते, schema को malformed reply reject करते, checker को missing edge माँगते और pre-commit gate को schema violation block करते देखेंगे। Lab README हर concept को उसके demo से map करती है।
अगर इनमें से कुछ नया है, तो पहले Loop Engineering और Harness Engineering courses पढ़ें। यह course उन courses की बनाई machinery को जोड़ता है।
यहाँ नए हैं? जो पहले से पता होना चाहिए, उसका 2-minute recap
progress.md, जिसे loop पहले पढ़ता और अंत में लिखता है, ताकि अगला beat जान सके कि क्या हुआ।main तक नहीं पहुँचती।
Key words, आसान भाषा में
ये शब्द पूरे course में मिलेंगे। यह list अभी एक बार पढ़ें, फिर जब कोई term साफ़ न लगे तो यहाँ लौटें।
| Term | आसान अर्थ |
|---|---|
| Graph | Arrows (edges) से जुड़े points (nodes) का set। Arrows की direction होती है और direction meaning रखती है। |
| Node | Graph का एक point: entity, claim, commit, source या agent run। |
| Edge | दो nodes के बीच label वाला arrow: supports, parent_of, produced, works_for। |
| DAG | Directed acyclic graph: arrows कभी घूमकर अपने पास वापस नहीं आते। Git history एक DAG है। |
| Commit DAG | काम की graph: commits nodes हैं, parent links edges हैं। यह बताती है, "क्या try हुआ और क्या किससे निकला?" |
| Knowledge graph | Facts की graph: entities nodes हैं, typed relations edges हैं। यह बताती है, "क्या मौजूद है और कैसे connected है?" |
| Entity | ऐसी चीज़ जिसे graph track करती है: person, company, file, vendor या incident। |
| Relation / triple | Subject–predicate–object के रूप में एक fact: (Vendor X, supplied, Component Z)। |
| Surface form | कोई नाम ठीक उसी तरह जैसे document में दिखता है: "Edwin Aldrin", "Buzz", "Col. Aldrin"। 3 surface forms, एक person। |
| Entity resolution | यह तय करना कि कौन-से surface forms वही real thing हैं, और original names खोए बिना उन्हें एक canonical node में merge करना। |
| Provenance | Claim के साथ लगी receipt: किस source ने कहा, किस run ने extract किया और extraction कितनी confident थी। |
| Claim | ऐसा statement जिसे graph संभवतः true मानकर store करती है, हमेशा provenance के साथ, कभी bare truth की तरह नहीं। |
| Subgraph | एक task के लिए graph का छोटा, relevant slice। Agents को subgraphs दें, पूरी graph कभी नहीं। |
| Grounding | Answer या verdict को अपने impression के बजाय graph की real edges की ओर point करने के लिए मजबूर करना। |
| Swarm | बहुत-से agents एक ही समय पर explore, implement या evaluate करते हैं। |
| Structured output | Schema, जैसे Pydantic model, से constrained model response, ताकि code भरोसा करने से पहले उसे validate कर सके। |
| MCP | Model Context Protocol: agent के outside system तक पहुँचने का standard तरीका। Graph files में हो तो इसकी ज़रूरत नहीं। Database बनने पर यही answer है। |
| Governance graph | ऐसी graph जिसके nodes खुद loops, human gates और anchors हैं, और edges बताती हैं कि कौन किसे feed, check और constrain करता है। |
| Execution loop | बार-बार होने वाला काम करने वाला loop: issues triage करना, PR review करना, changelog draft करना। |
| Improvement loop | Target के सामने किसी number को देखता और काम करने वाले system को adjust करता loop। |
| Counter-metric | दूसरा number, जिसे दूसरा loop देखता है और पहले number की gaming पकड़ता है। |
| Anchor | ऐसा measurement जिससे कोई loop बहस नहीं कर सकता: सच में चला test, सच में रुका customer, सच में आया पैसा। |
| Frozen node | ऐसी rule या file जिसे optimizing loops कभी नहीं बदल सकते, ठीक इसलिए क्योंकि वे बदलना चाहेंगे। |
Loop course ने loops को body metaphor दिया था: heartbeat, body और spine। यह course एक और जोड़ता है: graph shared brain है, ऐसी memory जो किसी एक agent की context window से अधिक समय तक रहती है।
छोटा version: primary work real और public है, लेकिन उसकी viral framing गलत है। "Anthropic के 2 seniors की 11-page PDF" एक independent study note है, जो अपने front page पर साफ़ कहती है कि वह Karpathy या Anthropic से affiliated या endorsed नहीं है। "1000x" measurement नहीं, slogan है। पहले primary sources पढ़ें। Timeline छोटी और public है। 7 मार्च 2026 को Karpathy ने autoresearch release किया: छोटे training repo में बंद agent, जो एक बार में लगभग 5 minute का experiment चलाता और केवल metric सुधारने वाली चीज़ रखता है। कुछ ही weeks में उसे GitHub पर हज़ारों stars मिले और Fortune ने pattern को "Karpathy Loop" कहा। 3 दिन बाद उसने AgentHub का sketch बनाया: "GitHub is for humans. AgentHub is for agents"। यह bare Git repo और message board था, जहाँ swarms main branch के बजाय commit DAG के ज़रिए coordinate करते हैं। 23 मार्च 2026 को Anthropic ने अपनी Knowledge Graph Construction Cookbook publish की, जो classical NLP pipeline को structured-output prompts से बदलती है: typed entities और relations extract करें, duplicates resolve करें, graph assemble करें और citations के साथ query करें। Anthropic की Dynamic Workflows, जिसे 28 मई 2026 को announce किया गया और जो अब generally available है, Claude को orchestration script लिखने देती है जो काम parallel fresh-context sub-agents में fan out करती है। 18 जुलाई 2026 को Peter Steinberger के midnight के 12-word question, "Are we still talking loops or did we shift to graphs yet?", ने पूरे topic को season का नाम दिया। Part 5 उस story और Carlos E. Perez के answer को बताता है। कुछ days बाद एक viral post ने सब जोड़ दिया: "Two Anthropic seniors just made Karpathy's loop 1000x better with Graph Engineering — dropped 11-page PDF." इसे दोहराने से पहले PDF का पहला page पढ़ें। वह italics में कहता है: independently compiled, not affiliated with Andrej Karpathy and Anthropic, and not endorsed. Synthesis सच में useful है और यह course उससे सीखता है, लेकिन वह independent author का study note है, Anthropic paper नहीं, और "1000x" measurement नहीं, slogan है। यही reflex Steinberger के question को "loop engineering is dead" बना गया था। Part 5 उसे खोलता है। इसे भी उसी तरह देखें। Primary sources real हैं और आपका समय deserve करते हैं, लेकिन एक caveat याद रखें: autoresearch तथा Anthropic की cookbook और workflow docs public हैं, जबकि AgentHub release के कुछ समय बाद private हो गया और अब केवल unlicensed forks में बचा है। Concept 5 में इस पर और है। Meme एक असली convergence चूक गया, जो meme से भी अजीब है: 19 मई 2026 को Karpathy Anthropic की pretraining team में शामिल हुआ, ताकि Claude से pretraining research तेज़ करने वाला group बना सके। इसलिए इस course की loop tradition और graph tradition Anthropic में सच में मिलीं। बस viral post के बताए तरीके से नहीं और उस PDF में नहीं। (सभी sources Sources & further reading में हैं।)पूरी timeline और meme ने क्या गलत बताया
Industry "graph engineering" को एक से अधिक meanings में use करती है। उनमें से 2 closely related हैं और यह course दोनों को पूरा cover करता है। पहला memory graph है: agents की shared durable, typed state। इसमें काम का commit DAG और facts की knowledge graph शामिल हैं। यह Parts 2 से 4 तक है।
दूसरा governance graph है: खुद loops के बीच wiring। यह record करती है कि कौन किसे feed करता है, कौन किसे check करता है, human gate कहाँ है और किन measurements से कोई loop बहस नहीं कर सकता। यह Part 5 है, जो Peter Steinberger के question और Carlos E. Perez के essay पर बना है।
ये दोनों एक system की layers हैं, rivals नहीं। Governance graph workers को जोड़ती है। Memory graph workers की knowledge store करती है। वे Concept 10 में मिलती हैं, जहाँ governance layer का checker memory layer से evidence पढ़ता है। Loop course ठीक वहाँ खत्म होता है जहाँ यह course शुरू होता है: एक पूरी तरह built loop के साथ, और दोनों उसे इस course को सौंपते हैं।
तीसरा meaning भी use होता है, पर यह course उसे नहीं सिखाता। कुछ writers execution topology के लिए "graph engineering" कहते हैं: nodes records या loops के बजाय steps होते हैं, edges data dependencies होती हैं और design question यह होता है कि क्या parallel चल सकता है और run को कहाँ wait करना होगा। यह orchestration frameworks का क्षेत्र है और phrase से पुराना है: LangGraph ने जनवरी 2024 में shared state पर nodes और edges ship किए थे, और Microsoft का AutoGen तथा Google का ADK अपने versions रखते हैं। इसके सबसे अच्छे ideas फिर भी यहाँ आते हैं: Concept 11 का arrow test और routing split, तथा Concept 14 के budget और join rules। लेकिन अगर आप orchestration graph बनाने का chapter ढूँढ रहे थे, तो वह अलग course है। Build करने से पहले दोनों questions में choice करना उन्हें blend करने से अधिक useful है। आपके loops की wiring और एक run का shape related problems हैं, पर उनके answers अलग हैं।
6-step playbook और हर step पहले कहाँ मिला
ज़्यादातर readers viral 6-step playbook से यहाँ आते हैं। उसके 6 में से 4 steps आपके पीछे हैं। यह course बाकी 2 और list से छूटा हिस्सा सिखाता है। इसलिए "1000x" का honest version benchmark नहीं है। Steps 1 से 3 आपको capable worker देते हैं और steps 4 से 6 ऐसे 1,000 workers को एक shared memory देते हैं। Model वही, architecture अलग।इस series पर map किए 6 steps
Post में लिखा step असल में यह क्या है आपने कहाँ सीखा 1. एक loop बनाएँ: generate, critique, revise Maker–checker beat और ratchet Loop Engineering 2. Tools जोड़ें: search, code, database Connectors और उन्हें सीमित रखने वाली tool schemas Loop और Harness Engineering 3. Parallel जाएँ: अलग worktrees में agents Isolation, ताकि concurrent work collide न करे Loop और Harness Engineering 4. Graph जोड़ें: transcripts नहीं, typed nodes और edges Session से अधिक टिकने वाली memory इस course के Parts 2 से 4 5. Evaluator को vibes नहीं, edges में ground करें Citable evidence के साथ verification इस course का Concept 10 6. Graph हर session के बाद बची रहती है Provenance, supersession और durable state Concepts 8 और 13 तथा Part 6
Mindset shift, एक picture में
Tools पर एक note, जो sibling courses से छोटा है। Loop, harness और eval work में tool-specific spellings सिखानी थीं। Graph work में लगभग कोई नहीं: graph files, Git, jq और आपके अपने schema से बनती है, इसलिए न कुछ खरीदना है, न product feature configure करना है। Claude Code और OpenCode यहाँ केवल ऐसे workers हैं जो graph पढ़ते और लिखते हैं। नीचे हर command दोनों में समान चलती है और पूरे course में claude -p तथा opencode run interchangeable हैं। यह tool-independence course के scope का accident नहीं है। यह सबसे मज़बूत evidence है कि graph feature नहीं, discipline है।
एक term यहाँ होना चाहिए, क्योंकि readers उचित रूप से उसकी उम्मीद करते हैं और फिर उसे गलत जगह रख देते हैं। MCP, यानी Model Context Protocol, agent के outside system तक पहुँचने का standard तरीका है: server tools expose करता है और MCP समझने वाला कोई agent उन्हें call कर सकता है। इस course के size पर MCP बिल्कुल नहीं आता, और यही सही है: graph repo में files है, इसलिए agent अपने मौजूदा file और shell tools से उसे पढ़ता और लिखता है। अगले size पर MCP answer बनता है। जब graph Postgres या Neo4j में चली जाए और अलग machines के कई agents को उस तक पहुँचना हो, तो हर agent को database credentials और hand-rolled client न दें। Store के सामने एक MCP server रखें, जो छोटी typed surface expose करे: entity resolve करना, bounded subgraph fetch करना, validated claim append करना। तब इस course की हर rule उस server में रहेगी, जहाँ एक बार enforce होती है, हर agent के prompt में नहीं जहाँ केवल request होती है।
3 layers अलग रखें, क्योंकि वे आसानी से blur होती हैं। Skill वह knowledge है जिसे agent load करता है: यहाँ claims कैसे लिखते हैं। MCP wire है: agent store तक पहुँचता कैसे है। Graph खुद memory है: वास्तव में क्या याद रखा गया। Graph के बिना skill ऐसी advice है जिसे लिखने की जगह नहीं। Skill के बिना graph inconsistent भरती है। MCP इनमें से कोई नहीं। वह plumbing है जो उस समय ज़रूरी होती है जब store agent के same folder में file नहीं रहता।
जुलाई 2026 के आख़िर में सही, अलग shelf lives के साथ। Autoresearch actively develop हो रहा है। AgentHub frozen और private है, इसलिए उसके बारे में हर बात history मानें। Dynamic Workflows अब generally available है और उसकी limits व defaults product के साथ बदलते हैं। Cookbook living notebook है। किसी flag, limit या model name पर भरोसा करने से पहले live sources check करें: github.com/karpathy/autoresearch, platform.claude.com/cookbook, code.claude.com/docs, opencode.ai/docs।
यह course क्या cover करता है
| Part | Topic | आप क्या सीखेंगे |
|---|---|---|
| 1 | Memory problem | Transcripts team memory की तरह क्यों fail होते हैं, graph क्या है और हर swarm को कौन-सी 2 graphs चाहिए |
| 2 | काम का DAG | Karpathy का path: autoresearch history को Git में लिखता है, AgentHub DAG को collaboration layer बनाता है |
| 3 | Facts की graph | Anthropic का path: schema से extraction, entity resolution और हर edge पर provenance |
| 4 | Graph से काम करना | Dumps के बजाय subgraphs और grounded checker: "triple नहीं मिला" कहना "गलत लगता है" से बेहतर है |
| 5 | Loops की graph | Governance layer: कौन किसे check करता है, single loop के टूटने के 4 तरीके और वे anchors जिनसे कोई loop बहस नहीं कर सकता |
| 6 | एक graph, शुरू से अंत तक | Morning-triage loop की spine को files और shell से दोनों tools में छोटी queryable graph बनाना |
| 7 | Grounded रहना | Level चुनना, complexity budget, graph कब न बनाएँ और अगले 2 courses का bridge |
| Live | Dogfooding | इस book की चल रही proto-graph और वह graph जिसे यह जानबूझकर नहीं बनाती |
| Practice | Projects | 8 graph builds, easy से hard |
काम करके सीखना चाहते हैं? पहले Part 6 पढ़ें और एक finished graph देखें। फिर parts के लिए वापस आएँ।
पहली बार? Memory path लें: Parts 1 से 4, यानी Concepts 1 से 10, फिर सीधे Part 6 पर जाकर इसे बनाएँ। Part 5 और "Going deeper" mark किया हर note skip करें। इसमें लगभग 2 घंटे लगते हैं, या examples को केवल पढ़ने के बजाय करने पर करीब 3 घंटे। फिर Projects 1 से 3 करें। इसके बाद आप अपने system को graph की तरह draw कर सकेंगे, claims को sources के साथ store कर सकेंगे और reviewer से evidence cite करवा सकेंगे।
दूसरी reading, जब आपकी पहली graph ऐसा question answer कर चुकी हो जो transcripts नहीं कर सके: governance path लें, यानी Part 5, पूरा Part 7 और Projects 4 से 8। Part 5 कई loops को honest रखने के बारे में है और यह तभी urgent बनता है जब एक से अधिक loop same memory में लिखते हैं। Concept 15 की warnings भी तभी असर करती हैं जब आपके पास ऐसी graph हो जिसे over-build करने का मन हो।
2 layers, अलग speed से पुरानी होती हैं। पहली याद रखें। दूसरी lookup करें।
- Lasting layer। Agent भूलता है, graph नहीं भूलती। Work lineage और domain facts 2 अलग graphs हैं: उन्हें collapse न करें। Schema trained pipeline से सस्ता है। Resolution को receipts रखनी और reversible रहना चाहिए। हर claim provenance रखती है या inference mark होती है। Agents को subgraphs दें, पूरी graph कभी नहीं। Checker को edges में ground करें। Level चुनने से पहले 6 questions पूछें और run से पहले budget declare करें। हर optimizing loop के साथ counter-metric देखने वाला loop जोड़ें। System में कम-से-कम एक signal reality से आना चाहिए, किसी और model की report से नहीं। और graph builder की judgment amplify करती है, जिसमें builder की mistakes भी शामिल हैं।
- Mechanical layer। नीचे दिए हर repo name, model name, flag और star count। Autoresearch का file layout, Dynamic Workflows की concurrency caps और Cookbook की exact Pydantic classes को याद करने वाली fact नहीं, live source का pointer मानें। Course और live docs disagree करें तो docs सही हैं।
Part 1: Memory Problem
1. Agent भूलता है, graph नहीं भूलती
इसे run करें: companion lab में bash concepts/01-agent-forgets.sh। पढ़ना आधा है। इसे होते देखना बाकी आधा।
आपके पास जो है, उससे शुरू करें। आपका morning-triage loop spine रखता है: progress.md, जिसे पहले पढ़ा और अंत में लिखा जाता है। वह file memory है और काम करती है: एक loop के लिए। अब गिनें कि वह क्या नहीं कर सकती:
- दूसरा loop उस पर भरोसा नहीं कर सकता।
progress.mdprose है। Changelog loop को दूसरे loop की diary पढ़कर interpret करनी होगी और उम्मीद करनी होगी कि format कभी drift नहीं करेगी। - 20 parallel agents उसे share नहीं कर सकते। 20 auditors fan out करें और हर एक खाली शुरू होता है। Agent 7 पाता है कि
utils/dates.tsमें timezone bug है। एक घंटे बाद Agent 14 उसे फिर खोजता है। उन्हें कुछ भी जोड़ता नहीं। - आप उसे query नहीं कर सकते। "पिछले महीने की कौन-सी findings payment code से जुड़ी थीं और reviewer ने confirm की थीं?" Spine इसका answer नहीं दे सकती। आप prose पर grep चलाकर उम्मीद ही कर सकते हैं।
- वह कुछ cite नहीं करती। Spine कहती है, "flaky test fix किया।" कौन-सा test? किस run ने साबित किया? किस बाद के fix ने supersede किया? Prose नहीं जानती।
Naive fix transcripts को इधर-उधर copy करना है: Agent 7 की conversation Agent 14 के context में paste करें। यह ठीक तब fail होता है जब सबसे ज़्यादा ज़रूरत होती है। Context windows भरती हैं। Costs कई गुना होते हैं। और transcript memory के लिए गलत shape है: वह evidence के साथ established बातों के बजाय कही गई हर बात को order में record करता है।
Graph engineering सोचा-समझा alternative है। Agents अपनी learning को typed records में लिखते हैं: यह entity है, यह उसके बारे में claim है, यह claim support करने वाला source है और यह उसे produce करने वाला run है। Labeled arrows records को जोड़ते हैं। कोई भी बाद का agent, कल का beat, अलग loop या बिल्कुल अलग model अपनी ज़रूरत के records query करके आगे बढ़ता है। इस course के topic को popular बनाने वाली independent PDF इसे 5 सही words में कहती है: agent भूलता है, graph नहीं भूलती।
Transcript chat log है। Graph filing system है। नई employee team join करे तो आप उसे team की हर पुरानी conversation की recordings नहीं देते। आप organized, labeled और cross-referenced files देते हैं। Graph engineering आपके agents के लिए सही filing system बनाना है।
आपके triage loop और changelog loop, दोनों को जानना है कि इस week कौन-से PRs ship हुए। आज दोनों हर context window में काम दोबारा हो और interpret किया जा रहा है: ठीक वही "दुनिया को scratch से फिर बनाना" failure। Fix: जो loop पहली बार establish करे कि "PR #212 ship हुआ और issue #98 fix करता है", वह इसे provenance, यानी commit hash, वाले typed record की तरह एक बार लिखे। फिर दोनों loops record पढ़ें। एक बार derive करें, कई बार query करें।git log चलाकर बात फिर derive करते हैं। क्या waste हो रहा है और graph-engineering fix क्या है?Answer देखें
2. Graph क्या है: nodes, edges और direction
इसे run करें: companion lab में bash concepts/02-nodes-edges.sh। पढ़ना आधा है। इसे होते देखना बाकी आधा।
Loop course के अंत में यह definition मिली थी। यहाँ यह working tool बनती है। Graph points का set है जिन्हें nodes कहते हैं और वे arrows, यानी edges, से जुड़े होते हैं। 3 properties पूरा काम करती हैं:
- Nodes typed होते हैं। केवल "box" नहीं, बल्कि "Entity", "Claim", "Source", "Commit" या "Evaluation"। Type हर reader को बताता है कि node कौन-से questions answer कर सकता है।
- Edges labeled और directed होती हैं।
(claim_441) —supported_by→ (source_readme)का meaning reverse arrow से अलग है। Direction ही meaning है: कौन किसे support करता है, कौन किससे descended है, किसने किसे check किया। - Paths answers हैं। "क्या Vendor X, Incident Y से connected है?" बदलकर यह बनता है: "क्या Vendor X node से Incident Y node तक supported edges का path मौजूद है?" दुनिया का question arrows पर walk बन जाता है।
तीसरी property payoff है। Prose को पढ़कर interpret करना पड़ता है। Graph को traverse किया जा सकता है: code से mechanically, हर बार एक ही तरह। Memory graph बनते ही vibes वाले questions queries बन जाते हैं।
एक special shape इतनी important है कि उसका नाम है। DAG, यानी directed acyclic graph, ऐसी graph है जिसके arrows घूमकर वापस नहीं आते। आप वर्षों से इसे नाम जाने बिना use कर रहे हैं: Git history। हर commit अपने parent की ओर point करता है। कोई commit अपना ancestor नहीं होता। यह example याद रखें, क्योंकि Part 2 इसी पर बना है।
Nodes nouns हैं। Edges direction वाले verbs हैं। Graph sentences, यानी (subject, verb, object), का ऐसा set है जिसे picture की तरह draw किया गया है, ताकि computer prose समझे बिना sentences की chains follow कर सके।
दो agents record करते हैं कि Vendor X ने एक part supply किया। एक अपने log में sentence "Vendor X supplied component Z" लिखता है। दूसरा graph में उसे follow कर सकता है। Sentence को देखने वाले model को सही तरह पढ़कर interpret करना होगा। Edge को हर बार समान तरीके से mechanically traverse और chain किया जा सकता है: (vendor_x) —supplied→ (component_z) लिखता है। दोनों true हैं। बाद का agent दूसरी चीज़ के साथ ऐसा क्या कर सकता है जो पहली के साथ नहीं?Answer देखें
vendor_x से component_z, फिर component_z से जुड़ी दूसरी चीज़ तक। इसी तरह दुनिया का question, "क्या Vendor X इस incident से जुड़ा है?", reading comprehension के बजाय arrows पर walk बनता है। Typed edge अपनी receipt भी रखती है, जो prose अक्सर खो देती है।
3. दो graphs और उन्हें collapse क्यों न करें
इसे run करें: companion lab में bash concepts/03-two-graphs.sh। पढ़ना आधा है। इसे होते देखना बाकी आधा।
यह distinction पूरे course को organize करती है और beginners सबसे अधिक इसी को blur करते हैं। Multi-agent system को 2 अलग graphs चाहिए, क्योंकि उसे 2 अलग तरह की चीज़ें याद रखनी होती हैं:
| Commit DAG (Part 2) | Knowledge graph (Part 3) | |
|---|---|---|
| क्या याद रखती है | काम: क्या try हुआ | Facts: क्या known है |
| Nodes | Commits, experiments, runs | Entities, claims, sources |
| Edges | parent_of, derived_from | supports, works_for, about |
| क्या answer करती है | क्या बदला? Batch-size experiment से क्या descended है? कौन-सी lineages अभी alive हैं? | कौन-सी entities मौजूद हैं? वे कैसे related हैं? कौन-सा source इस claim को support करता है? कौन-सी claims conflict करती हैं? |
| इसका एक version आपके पास है | Git history, कुछ हद तक: Concept 4 देखें | अभी कुछ नहीं: Part 3 इसे बनाता है |
इन्हें अलग क्यों रखें? क्योंकि इनके truth rules अलग हैं। Commit construction से fact है: वह हुआ था, Git इसकी guarantee देता है। Knowledge graph की claim evidence वाला statement है: वह गलत, mis-extracted या superseded हो सकती है, इसलिए हर claim edge provenance और confidence रखती है। दोनों collapse करें तो guesses को history मानेंगे या history को guesses के नीचे दबा देंगे।
वे connect होती हैं। Production system अपनी edges से उन्हें जोड़ता है:
(agent_run_183) —produced→ (claim_441)
(agent_run_183) —modified→ (commit_a81f)
(claim_441) —about→ (entity_vendor_x)
(claim_441) —supported_by→ (source_contract_pdf)
(claim_441) —supersedes→ (claim_238)
इस block को धीरे पढ़ें: 5 lines में पूरा course है। Run ने काम, यानी commit, किया और कुछ, यानी claim, सीखा। Claim entity के बारे में है, source से supported है और पुरानी claim replace करती है। बाईं ओर work lineage, दाईं ओर domain knowledge, joined लेकिन कभी merged नहीं।
Commit DAG lab notebook है: dated और ordered experiments, हर एक के साथ parent। Failures भी इसमें रखें, जो एक choice है जिसे Concept 4 में autoresearch नहीं चुनता और Concept 5 में AgentHub चुनता है। Knowledge graph वह encyclopedia है जिसे lab लिख रही है: अब हम क्या मानते हैं, footnotes के साथ। केवल notebook रखने वाली lab questions answer नहीं कर सकती। केवल encyclopedia रखने वाली lab अपना काम नहीं दिखा सकती। दोनों रखें और cross-reference करें।
Agent report करता है: "मैंने parser refactor किया (commit Refactor commit DAG में रहता है: commit 9fc2) और इस दौरान confirm किया कि vendor की API 1970 से पहले की dates reject करती है।" Sentence का हर half कहाँ रहता है?Answer देखें
9fc2, अपने parent link के साथ, automatically। API behavior knowledge graph की claim है: (vendor_api) —rejects→ (pre-1970 dates), जिसमें run और evidence, यानी error response, की ओर point करने वाली provenance है। आज वह दूसरा fact transcript में मर जाता है। इसी loss को रोकने के लिए यह course है।
ज़्यादातर systems को knowledge graph नहीं बनानी चाहिए और इसे बनाने के 4 parts पढ़ने से पहले यह जानना आपका हक़ है। पूरा short test Concept 15 में है: अगर tasks independent हैं, answers एक बार में एक document से आते हैं, relations fixed और simple हैं, relational table आपके हर real query का answer पहले ही देती है और किसी को provenance नहीं चाहिए, तो यहीं रुकें। Spine वाला एक loop सही answer है। Graph जोड़ने पर ऐसे questions के बदले extraction errors और schema upkeep मिलेंगे जो किसी ने पूछे ही नहीं।
Balance तब बदलता है जब 2 loops को facts exchange करने हों, synthesis कई workers में फैली हो, relations evolve होती रहें या कोई एक दिन पूछे, "हम यह कैसे जानते हैं?" इनमें से कुछ true या जल्दी true होने वाला हो तो आगे पढ़ें। Concept 14 इसे 6 ordered questions में बदलता है।
Part 2: काम का DAG
4. Autoresearch: ratchet अपनी history Git में लिखता है
इसे run करें: companion lab में bash concepts/04-autoresearch-ratchet.sh। पढ़ना आधा है। इसे होते देखना बाकी आधा।
Loop course ने ratchet सिखाया: एक change try करें, evaluate करें, number improve हो तो ही रखें, नहीं तो revert करें। Karpathy का autoresearch (7 मार्च 2026) यही exact loop है, जिसे ML training पर लगाया गया है। इस course के लिए उसकी importance एक design choice है: loop की memory transcript नहीं, commit DAG है।
Setup छोटे single-GPU training repo में 3 files का है:
prepare.py, fixed data preparation और evaluation। Agent उसे छू नहीं सकता। (Frozen node, यानी file पर लागू harness course की deny rule।)train.py: model, optimizer और training loop। केवल यही surface agent edit करता है।program.md: natural-language instructions: metric, budget, commit और revert rules तथा कब escalate करना है। (Loop course ने इसे "programming the program" कहा था।)
फिर beat हमेशा चलता है: train.py और recent history पढ़ें, एक motivated change propose करें, उसे commit करें, लगभग 5 minute train करें, validation loss measure करें। Improvement हुआ? Commit रहता है। Worse या crash हुआ? Last retained commit पर reset करें। दोनों cases में result record करके आगे बढ़ें: loop में कोई human नहीं।
अब ध्यान से देखें कि हर beat क्या छोड़ता है, क्योंकि beginners और कई popular write-ups autoresearch को यहीं गलत समझते हैं। इसकी एक नहीं, 2 memories हैं और वे अलग चीज़ें रखती हैं:
| क्या रखती है | Truth standard | |
|---|---|---|
| Git branch | Dedicated experiment branch पर commits की rising chain के रूप में केवल retained improvements | Verified: हर commit ने metric beat किया |
results.tsv | हर attempt: commit hash, metric, इस्तेमाल memory, kept/discarded/crashed status और क्या try किया | Complete: attempts record करती है, achievements नहीं |
ज़रूरी detail failure पर होने वाली चीज़ है। Instructions साफ़ कहती हैं: metric improve हो तो branch आगे बढ़ाकर commit रखें, equal या worse हो तो git reset से starting point पर लौटें। Reset attempt को side branch पर park नहीं करता। वह commit को branch से हटा देता है। इसलिए discarded experiment केवल results.tsv में बचता है। और results.tsv को जानबूझकर Git में untracked रखा जाता है।
इसे oversight नहीं, design की तरह पढ़ें, क्योंकि यह Concept 3 का wild में सबसे साफ़ example है। Git वह work रखता है जिसकी value prove हुई। TSV हर attempted चीज़ का honest record रखती है, crashes भी। Human researcher hypotheses, failed attempts और parameter interactions working memory में रखकर खो देता है। Autoresearch दोनों kinds को 2 places में 2 standards के तहत लिखता है। वह जो नहीं करता, वह alternative lineages को alive और traversable रखना है: discarded idea text की row बनता है जिसे कोई दूसरा agent query नहीं कर सकता। Concept 5 ठीक यही gap भरता है।
पहले weeks के reported numbers, लगभग 630 lines core code, 2 days में करीब 700 experiments और लगभग 20 retained optimizations, shape से कम important हैं। Repo ने हज़ारों stars इसलिए नहीं पाए कि optimizations profound थीं, बल्कि इसलिए कि pattern legible है: छोटा code, visible metric, 2 honest logs। (कोई number quote करने से पहले live repo check करें: वह हर week बदलता है।)
इसे चलाने वाली 4 conditions exactly loop course की checklist हैं: output verifiable है, यानी validation number; action reversible है, यानी git reset, जो attempt undo करता है पर preserve नहीं; horizon short है, यानी 5-minute runs; environment bounded है, यानी एक repo और एक editable file। नया कुछ नहीं, सिवाय memory कहाँ रहती है।
Autoresearch आपका ratchet loop है, बस memory agent के head से निकलकर 2 files में चली गई है। Git branch working चीज़ रखती है। results.tsv tried चीज़ रखती है। Loop crash होकर restart हो सकता है और direction नहीं खोता, क्योंकि कोई memory context window में नहीं रहती। लेकिन honest limit देखें: discarded experiment text file में row छोड़ता है, ऐसा node नहीं जिसे कोई traverse कर सके।
Agent के साथ काम किए किसी repo को खोलें और DAG से वे questions पूछें जिनका spine answer नहीं दे सकती:
git log --oneline --graph -20 # the DAG, drawn
git log --follow -- path/to/file.ts # every experiment on one surface
git diff HEAD~5 HEAD -- src/ # what five beats of work changed
फिर agent से पूछें: "Last 20 commits पढ़ें। Apparent metric क्या था और कौन-से commits retained improvements लगते हैं?" ध्यान दें कि DAG क्या नहीं बता सकता: कौन-से experiments try करके फेंक दिए गए। Autoresearch में यह answer Git से बाहर results.tsv में है। Concept 5 उन rows को nodes बनाने के बारे में है।
5. AgentHub: search graph traverse करें, main में merge न करें
इसे run करें: companion lab में bash concepts/05-agenthub-traversal.sh। पढ़ना आधा है। इसे होते देखना बाकी आधा।
Autoresearch के 3 days बाद Karpathy ने next step post किया: loop को "asynchronously massively collaborative for agents, think: SETI@home style" बनना चाहिए। एक PhD student नहीं, research community emulate करें। AgentHub उस layer का उसका sketch है: एक Go binary, एक SQLite database, एक bare Git repository, हर agent के लिए एक API key और एक message board। उसका slogan thesis है: "GitHub is for humans. AgentHub is for agents."
Concept 4 के gap से शुरू करें। Single ratchet failures reset कर देता है, इसलिए discarded idea का only record untracked text file की row है जिसे कोई दूसरा agent query नहीं कर सकता। AgentHub का central move reset रोककर keep करना है: agents commits को bundles की तरह push करते हैं, हर pushed commit durable node बनता है और किसी चीज़ को main branch पर converge करना ज़रूरी नहीं। Alternatives alive और traversable रहती हैं। Failures के text log और उनकी graph में यही difference है।
Agent collaboration को अलग plumbing क्यों चाहिए? क्योंकि swarms human Git की हर assumption उलट देती हैं:
- हज़ारों agents एक साथ explore करते हैं। Human repos कुछ branches मानते हैं। Swarm में हज़ारों simultaneous attempts normal हैं।
- अधिकतर results जानबूझकर कभी merge नहीं होते। Humans के लिए unmerged branch अधूरा काम है। Swarm के लिए failed experiment evidence है: वह हर दूसरे agent को बताता है कि idea एक condition में fail होता है।
- Primary operation बदलती है। "इसे main में merge करें" नहीं, बल्कि "search graph traverse करें।" Required main branch, pull requests, merge queue या किसी leaf को canonical मानने की assumption नहीं।
CLI shift को concrete बनाती है। हर command everyday name वाली graph query है:
ah push # publish my commit as a new node
ah children <hash> # what was tried on top of this result?
ah leaves # the frontier: results nobody has built on yet
ah lineage <hash> # the full ancestry path that produced this outcome
ah diff <a> <b> # compare any two experiments, related or not
ah log --agent X # one agent's trail through the search
children पूछता है कि result के ऊपर कौन-से ideas explore हुए। leaves unexplored frontier दिखाता है। lineage outcome तक पहुँचने का path reconstruct करता है। Conventional branch model से ये questions पूछें और देखें कि वे कितने awkward हैं। DAG-as-graph view में हर question एक command है।
Message board social layer है और memory story पूरी करता है। Agent को हर पुराना transcript नहीं चाहिए। वह relevant lineages query करता, कुछ summaries पढ़ता, एक commit fetch करता और आगे बढ़ता है। Independent PDF इसे precise नाम देती है: graph-grounded context construction। Current decision के लिए connected state retrieve करें, पूरी history replay न करें। Phrase याद रखें। Concept 9 इसे generalize करता है। साथ चलने की कोशिश करने वाले हर person के लिए 2 honesty notes important हैं। पहला, repo के अपने words में: "Work in progress. Just a sketch. Thinking..." AgentHub के पास agents के बीच trust, malicious bundles, scale पर storage, duplicate detection या long-term indexing का answer नहीं था। इससे lesson weak नहीं होता, sharp होता है। Sketch ठीक वे human abstractions पहचानता है जो agents बहुत ज़्यादा होने पर पहले fail होती हैं: single main branch, human-paced review, transcript memory और merge-centered collaboration। दूसरा, AgentHub अब public नहीं है। March 2026 release के एक दिन में उसे कुछ हज़ार stars मिले और फिर private कर दिया गया। Preserved forks मौजूद हैं, लेकिन original में license file नहीं थी। किसी copy को study का historical artifact मानें, maintained software या dependency नहीं। Transferable design पढ़ें: commits as nodes, bundles as push unit, traversal as primary operation और ऐसा message board जहाँ discarded result भी सिखाता है।पहली reading में optional: AgentHub का status और limitations
github.com/karpathy/agenthub अब 404 देता है। सबसे साफ़ public account उस developer का है जिसने पहले fork किया और बाद में design document किया: "Karpathy open-sourced AgentHub last week. Then the repo went private."
GitHub एक shared "official" version मानता है जिसकी ओर हर कोई काम करता है। Swarm एक official version नहीं चाहता। उसे tried हर चीज़ का map चाहिए, dead ends भी, क्योंकि वे सिखाते हैं। AgentHub map रखता और ceremony हटाता है।
AgentHub swarm की memory layer है। किसी चीज़ को swarm run भी करना है। Anthropic की Dynamic Workflows, Claude Code के लिए 28 मई 2026 को announce हुई और अब generally available है, सबसे साफ़ production example है। Fan-out script आपके लिखने के बजाय Claude current task के लिए orchestration program लिखता है: files glob करें, हर file के लिए auditor spawn करें, findings filter करें, उन्हें refute करने वाले reviewers spawn करें, फिर cited report बनाने के लिए एक synthesizer। Official description एक session में tens to hundreds of parallel sub-agents है, हर एक fresh context के साथ; results fold करने से पहले check होते हैं और progress save होती है, ताकि interrupted run restart होने के बजाय resume हो। Claude से workflow माँगकर या ultracode setting on करके शुरू करें, जो effort level बढ़ाती है और Claude को decide करने देती है कि workflow कब उचित है।
Advertised demo Bun port है: Jarred Sumner ने dynamic workflows से Bun को Zig से Rust में move किया और लगभग 750,000 lines Rust produce कीं, existing test suite का 99.8% pass हुआ, first commit से merge तक 11 days लगे। Anthropic note करता है कि यह अभी production में नहीं है।
Feature के साथ 2 warnings हैं। यह ordinary session से काफ़ी अधिक tokens consume करता है, इसलिए पहला workflow confirmation माँगता है और administrators workflows पूरी तरह disable कर सकते हैं। Parallel workers correlated errors बनाते हैं: verification wave तभी मदद करती है जब reviewers का prompt, evidence set या role अलग हो। (Announcement post "tens to hundreds" कहता है, लेकिन reference docs अधिक precise हैं और design उन्हीं numbers पर करें। "Behavior and limits" table 16 concurrent agents तक, limited CPU cores वाली machines पर कम, और हर run में कुल 1,000 agents बताती है। Build करने से पहले current numbers के लिए docs check करें।) Feature जो deep question खुला छोड़ती है, यानी fresh-context के सैकड़ों workers अपनी learning कहाँ रखें, वह Part 3 का काम है।
AgentHub में Agent A का experiment fail होता है: बड़ा batch size memory limit पर crash करता है। GitHub thinking में branch abandon और forget होगी। Graph thinking में क्या होता है और किसे benefit मिलता है? Failed commit DAG में node की तरह रहता है और message-board post उसकी lineage cite करती है: "batch 64 इस hardware की memory से अधिक है। Depth change से branch करें।" उस lineage पर Answer देखें
children query करने वाला हर future agent crash दोबारा run किए बिना warning पाता है। Failure shared memory बन गई। Swarm और crowd में पूरा difference यही है।
Part 3: Facts की Graph
Git ने commit DAG free में दिया। Knowledge graph आपको बनानी है। दशकों तक इसका अर्थ trained NLP pipeline था: named-entity model, relation classifier और deduplication heuristic, हर एक को labeled data और maintenance चाहिए। Anthropic की Knowledge Graph Construction Cookbook (23 मार्च 2026) 2026 का version दिखाती है: पूरी pipeline structured-output prompts में collapse हो जाती है। 4 stages, 3 concepts।
6. Extraction: schema ही training data है
इसे run करें: companion lab में python3 concepts/06-extraction.py। पढ़ना आधा है। इसे होते देखना बाकी आधा।
Stage 1 unstructured text को typed pieces में बदलती है। आप schema में desired shape define करते हैं और model output को उसी तक constrain करते हैं:
नीचे का shape पढ़ने के लिए abbreviated है: EntityType, ExtractedGraph और PROMPT आपको define करने हैं, और Cookbook notebook में runnable version है। यहाँ line count नहीं, 3 design decisions matter करती हैं।
class Entity(BaseModel):
name: str
type: EntityType # your enum: PERSON | ORG | PROJECT | ...
description: str # context, used later for resolution
class Relation(BaseModel):
source: str # subject, a name that must appear in entities
predicate: str # short verb phrase: "commanded", "supplied"
target: str # object, likewise
class ExtractedGraph(BaseModel):
entities: list[Entity]
relations: list[Relation]
def extract(text: str, client) -> ExtractedGraph:
response = client.messages.parse(
model="claude-haiku-4-5", # cheap model: extraction is volume work
max_tokens=4096,
messages=[{"role": "user", "content": PROMPT.format(text=text)}],
output_format=ExtractedGraph, # the schema constrains the reply
)
return response.parsed_output
Syntax नहीं, design पढ़ें। 3 decisions lesson का भार उठाती हैं:
- Pydantic schema ही केवल "training data" है। न labeled corpus, न fine-tuned NER model। Schema और prompt वह काम replace करते हैं जिसमें पहले team का एक quarter लगता था। अब ontology बदलने का अर्थ class edit करना है, pipeline retrain करना नहीं।
- Cheap model volume work करता है। Extraction हर document पर एक बार चलती है, संभवतः हज़ारों documents पर, इसलिए Haiku पर चलती है। Expensive judgment calls, यानी अगला concept, stronger model को जाते हैं। यह loop course की maker–checker economics को pipeline stages पर लागू करना है।
descriptionfield decoration नहीं है। वह हर entity के आसपास context capture करती है और Concept 7 को 2 names same thing हैं या नहीं, यह decide करने के लिए exactly context चाहिए।
यह harness course की typed-output rule भी है, जिसे एक reviewer verdict से पूरे memory system तक promote किया गया है: graph में prose के रूप में कुछ enter नहीं होता। Graph के भरोसा करने से पहले code हर extraction को schema के against validate करता है।
आप model को person या company क्या है, यह नहीं सिखाते: वह पहले से जानता है। आप उसे भरने के लिए form देते हैं और form में fit न होने वाला reply reject करते हैं। Form ही पूरी pipeline है।
Idea के लिए Python नहीं चाहिए। README वाले repo में वह headless worker run करें जिसे पहले से जानते हैं:
claude -p 'Read README.md. Return ONLY valid JSON:
{"entities":[{"name":"","type":"PERSON|ORG|TOOL|PROJECT","description":""}],
"relations":[{"source":"","predicate":"","target":""}]}
Every relation must connect two extracted entities. Predicates are short verb phrases.'
# OpenCode: opencode run '<same prompt>'
Validate करने के लिए output को jq . में pipe करें। बधाई: operating size पर Cookbook की stage 1 यही है।
7. Resolution: एक चीज़, कई names
इसे run करें: companion lab में python3 concepts/07-resolution.py। पढ़ना आधा है। इसे होते देखना बाकी आधा।
Extraction clean graph नहीं, surface forms produce करती है। वही astronaut 3 documents में "Edwin Aldrin", "Buzz Aldrin" और "Col. Aldrin" के रूप में आता है। Unmerged छोड़ें तो graph में 3 disconnected people होंगे और Aldrin से होकर जाने वाला हर multi-hop question चुपचाप fail होगा। Entity resolution तय करती है कि कौन-से surface forms वही real thing हैं।
String similarity क्यों नहीं? क्योंकि वह दोनों directions में एक साथ fail होती है। "Edwin Aldrin" और "Buzz Aldrin" ठीक उस जगह अलग हैं जहाँ name किसी को identify करता है: given names में कुछ common नहीं, इसलिए similarity score reasonable merge threshold से नीचे जाकर merge miss करता है। वहीं "Muhammad Khan" नाम के 2 अलग people perfect match score करते हैं: similarity score merge invent कर देता है। Names evidence हैं, proof नहीं।
Cookbook का move: resolution को reasoning task मानें। Candidate entities को type से group करें, stronger model, यानी Sonnet, को हर group Concept 6 के description fields के context के साथ दें और canonical clusters propose करने को कहें। Descriptions "Edwin Aldrin, Apollo 11 lunar module pilot" और "Buzz Aldrin, second person on the Moon" को mergeable और same name वाले strangers को separable बनाती हैं। Scale पर cheap blocking signals, जैसे same type और overlapping context, model के arbitrate करने से पहले candidate pairs narrow करती हैं, ताकि हर pairwise comparison के लिए pay न करना पड़े।
अब वह rule जो graph को durable बनाती है: resolution additive और reversible होनी चाहिए। Canonical entity अपने aliases, source documents, model का merge rationale, confidence और merge बनाने वाला run रखती है। कुछ overwrite नहीं होता। Surface forms link होते हैं, destroy नहीं। इतनी caution क्यों? क्योंकि false merge knowledge graphs की catastrophic failure है। 2 people को एक node में collapse करें और हर downstream traversal उनके employers, projects, dates और actions combine करती है: confidently, invisibly, हर जगह एक साथ। Receipts रहें तो bad merge एक reversal है। न रहें तो rebuild है।
यह pattern आप जानते हैं। यह harness course का reversibility verb, risky actions से पहले checkpoints, code के बजाय memory पर apply हुआ है।
Names merge करना 2 people की contact cards combine करने जैसा है। सही करें तो दोनों original cards merged card के पीछे staple करते हैं और note रखते हैं कि क्यों merge किया और कितनी certainty थी। गलत करें तो 2 strangers को staple कर देते हैं, एक के लिए हर message दूसरे तक पहुँचता है और कोई नहीं बता सकता कि कब शुरू हुआ।
Concept 6 में extracted entities को resolution के लिए वापस दें:
claude -p 'Here are extracted entities with descriptions: <paste>.
Group them by type, then propose canonical clusters. For each cluster return:
canonical_name, aliases[], rationale, confidence (0-1). Never drop an alias.
If two entities share a name but differ in description, keep them separate.'
फिर trap लगाकर दोबारा run करें: existing name वाली दूसरी entity जोड़ें, लेकिन description अलग रखें। Model उन्हें merge करे तो descriptions बहुत thin हैं। यह Concept 6 का fix है, Concept 7 का नहीं। Stages के बीच यही dependency lesson है।
Resolution step 5:1 compression ratio report करती है, यानी हर canonical entity पर 5 surface forms, जो last week 2:1 थी। Team "cleaner" graph celebrate करती है। Join करने से पहले क्या check करना चाहिए? False-merge rate। केवल compression over-merging को reward करती है: spectacular ratio का fastest रास्ता strangers को staple करना है। High ratio तभी good news है जब pairwise precision कायम रही हो। Merged clusters sample करें और verify करें कि members सच में एक thing हैं। Mistakes से connected graph fragmented graph से worse है, क्योंकि वह confident answers देती है। अगले course में इस instinct को gold sets, precision और recall से formalize करेंगे।Answer देखें
8. Provenance: हर edge अपनी receipt रखती है
इसे run करें: companion lab में bash concepts/08-provenance-invariants.sh। पढ़ना आधा है। इसे होते देखना बाकी आधा।
Assembly, तीसरी stage, mechanically simple है: Cookbook in-memory NetworkX MultiDiGraph इस्तेमाल करती है और memory छोटी पड़ने पर same shape Postgres या Neo4j में जाती है। Engineering content container नहीं, वह चीज़ है जो हर node और edge को रखनी ही चाहिए:
Resolution, यानी Concept 7, एक extra चीज़ देती है: हर surface form से उसके canonical name का map। Assembly उसी map को apply करना है। ध्यान दें कि Entity और Relation अब भी Concept 6 की plain schemas हैं: canonical identity map में रहती है, model output के नए field में नहीं।
# from Concept 7: {"Edwin Aldrin": "Buzz Aldrin", "Buzz": "Buzz Aldrin", ...}
alias_to_canonical: dict[str, str] = resolve(entities, client)
def add_entity(G, entity: Entity, source_doc: str) -> None:
canonical = alias_to_canonical.get(entity.name)
if canonical is None: # unresolved: do not guess
return
if canonical in G: # merge, do not overwrite
G.nodes[canonical]["source_docs"].add(source_doc)
G.nodes[canonical]["aliases"].add(entity.name)
return
G.add_node(canonical,
entity_type=entity.type,
description=entity.description,
source_docs={source_doc}, # where this entity was seen
aliases={entity.name}) # resolution's receipts, kept
def add_relation(G, rel: Relation, source_doc: str) -> None:
src = alias_to_canonical.get(rel.source)
tgt = alias_to_canonical.get(rel.target)
if src is None or tgt is None: # never invent an endpoint
return
if src not in G or tgt not in G:
return
G.add_edge(src, tgt,
predicate=rel.predicate,
source_doc=source_doc) # the receipt
2 details पूरा lesson हैं। Entity दोबारा दिखे तो existing content replace करने के बजाय source document और alias add होते हैं, इसलिए node receipts खोने के बजाय accumulate करता है। Resolution step ने जो resolve नहीं किया, उसे guess करने के बजाय drop किया जाता है। इसी कारण missing key पर दोनों functions raw surface form fallback करने के बजाय early return करती हैं। इस strictness की cost साफ़ देखें: resolution step entity miss करे तो उसके बारे में हर fact silently खो जाता है। Gentler policy raw name accept करके review के लिए flag करना है और दोनों choices defensible हैं। Middle defensible नहीं: silently fallback करना और फिर readers से कहना कि drop किया। Cookbook की अपनी notebook reference implementation है। हर edge पर confidence number चाहिए तो schema में field आपको जोड़ना है, Cookbook की Relation में नहीं है।
Provenance, यानी receipt, claim को "model ने कभी कुछ कहा था" से "ऐसा statement जिसे audit कर सकते हैं" बनाती है। Independent PDF discipline को 4 invariants में condense करती है जिन्हें एक unit की तरह याद रखना चाहिए। हर graph write को ये satisfy करनी हैं:
- हर claim का source है या उसे explicitly inference mark किया गया है।
- हर artifact का authoring run और version है।
- हर evaluation अपनी rubric identify करती है।
- हर superseded object addressable रहता है: replace करें, erase कभी नहीं।
ध्यान दें invariants चुपचाप क्या forbid करती हैं: graph truth machine नहीं है। वह claims, sources और relationships store करती है ताकि inspect हो सकें। वह claims को truth में convert नहीं करती। Biased corpus biased graph बनाता है। Missing document missing edge बनाता है। Graph का honest promise छोटा और अधिक valuable है: उसमें कुछ unattributed या unexaminable नहीं। यही promise Concept 10 की grounded checking संभव करता है। ऐसी memory से checker evidence नहीं माँग सकता जिसने evidence कभी रखा ही नहीं।
Scratch file में इस week agents की establish की 5 claims, हर एक अलग JSON object, लिखें और invariants के माँगे हर field को भरें। Exercise typing नहीं है। Notice करें कि किन claims का source नहीं दे सकते, क्योंकि उन्हें model की fluency के दम पर facts मानकर चल रहे थे। हर ऐसी claim को "source": {"kind": "inference"} mark करें और count करें। वह count आपकी current honesty baseline है।
Invariant 4 एक और sentence deserve करती है, क्योंकि वह ratchet की sibling है। New evidence claim overturn करे तो (claim_new) —supersedes→ (claim_old) add करें। Delete न करें। Graph याद रखती है कि वह गलत थी, इसलिए बाद में पूछ सकते हैं, "10 मार्च को हम क्या मानते थे और क्यों?" Audit trail बाद में retrofit होने वाली feature नहीं।
Receipt के बिना claim rumor है। Rumors से भरी graph, no graph से worse है क्योंकि organized दिखती है। 4 invariants एक habit हैं: कोई बात लिखें तो साथ में यह भी लिखें कि कैसे जानते हैं और उसने क्या replace किया।
Part 4: Graph से काम करना
9. पूरी graph नहीं, subgraph: context construction
इसे run करें: companion lab में python3 concepts/09-subgraph.py। पढ़ना आधा है। इसे होते देखना बाकी आधा।
आपने context dumping से बचने के लिए graph बनाई। उसे ruin करने का fastest तरीका नया dumping invent करना है: पूरी graph को हर prompt में serialize करना। 50,000 edges वाली graph context window में 50 transcripts जितनी useless है। Discipline bounded retrieval है: हर worker को task-specific subgraph मिले और कुछ नहीं।
Cookbook की query stage shape दिखाती है और PDF उसे ऐसे context builder में generalize करती है जिसे आपका कोई loop follow कर सकता है:
- Task में mentioned entities को graph के against resolve करें ("vendor incident" →
entity_vendor_x,entity_incident_y)। - उन nodes से 1 या 2 hops expand करें, केवल allowed edge types पर, हर edge और हर जगह नहीं।
- Task से जुड़े current artifact versions include करें।
- Stale या low-confidence claims से ऊपर recent, verified claims को prioritize करें।
- Conflicts include करें। 2 claims contradict करें तो worker दोनों देखे। Uncertainty hide करने से confident errors बनती हैं।
- Model के पढ़ने लायक plain triples के रूप में token budget के अंदर serialize करें।
- Stable edge identifiers attach करें, ताकि worker answer में
edge_1042cite करे और checker उसे lookup कर सके।
Steps 6 और 7 इस book की context की हर सीख से loop close करती हैं: serialized subgraph briefing document है, जिसे audited memory से code assemble करता है। यह context-engineering ideal है, अब durable source के साथ। और notice करें transcripts से impossible क्या possible हुआ: 20 workers coordinate करने वाला orchestrator 20 outputs अपनी window में copy नहीं करता। Workers typed graph updates publish करते हैं। Synthesizer graph traverse करके findings combine करता है, चाहे किसी single agent ने सारे source documents कभी न देखे हों। Orchestrator का context clean रहता है। इसी एक property के कारण multi-agent systems graph के साथ scale और उसके बिना suffocate करते हैं।
पहले extracted entities और relations में से वह चुनें जिसे real task mention करेगी। फिर 7 steps अपने हाथ से करें: resolved entity लिखें; चुने हुए 2 edge types पर केवल उसके 1-hop neighbours list करें; conflicting claim add करें; हर line पर ID के साथ result को plain triples में serialize करें। Lines count करें। अगर real task की briefing 20 triples में fit होती है, तो prove हो गया कि 50,000 edges dump करना कभी ज़रूरी नहीं था।
नई employee को पूरी filing cabinet न दें। उसके task से जुड़ी 3 folders और यह sticky note निकालें: "ये 2 folders disagree करती हैं, check करें।" यही subgraph है: छोटी, relevant, conflicts के बारे में honest और citable।
10. Grounded checker: "triple नहीं मिला" कहना "गलत लगता है" से बेहतर है
इसे run करें: companion lab में python3 concepts/10-grounded-checker.py। पढ़ना आधा है। इसे होते देखना बाकी आधा।
यहाँ memory layer governance layer से मिलती है और course अपने siblings का debt चुकाता है। Loop course ने maker–checker split दिया। Harness course ने checker को typed output दिया। लेकिन checker का verdict अब भी impression था: model काम पढ़कर schema में wrapped feeling report करता था। Graph checker को बदलती है: वह claims को edges के against check कर सकता है।
एक claim को पूरा walk करें। Maker की report कहती है: "Vendor X supplied the component involved in Incident Y." Grounded checker नहीं पूछता, "क्या यह सही लगता है?" वह graph से 2 mechanical questions पूछता है: क्या supported edge (vendor_x, supplied, component_z) मौजूद है? क्या (component_z, involved_in, incident_y) मौजूद है? कोई missing हो तो verdict vibe नहीं, structured और actionable demand है:
{
"decision": "revise",
"claim": "Vendor X supplied the component in Incident Y",
"reason": "No supported path from vendor_x to incident_y",
"required_evidence": [
"A source-backed 'supplied' relation from vendor_x",
"A source-backed 'involved_in' relation to incident_y"
]
}
Concept के title वाली 2 failure messages compare करें। "गलत लगता है" maker को यह guess करने वापस भेजता है कि reviewer को क्या नापसंद हुआ। "Triple नहीं मिला: ये 2 edges दें" maker को बताता है कि कौन-सा evidence ढूँढना या कौन-सी claim withdraw करनी है। एक mood है। दूसरी work order।
Demand दोनों directions में honest है: कभी maker source पाता है और graph को नई edge मिलती है। Grounding केवल report नहीं, memory improve करती है।
यही grounding हर known workflow pattern upgrade करती है। Chain में graph stages के बीच gate है: क्या इस stage की produced entities upstream मौजूद हैं? Fan-out में shared surface है जहाँ workers overlap किए बिना publish करते हैं। Orchestrator–workers में shared memory है जो orchestrator का context clean रखती है। Evaluator–optimizer में हर verdict के नीचे evidence layer है। एक graph, 5 patterns, हर जगह वही 3 roles: shared memory, grounding layer, persistent world model।
अब वह sentence जो आपको honest रखता और next course को सौंपता है। Grounded verdict केवल उन 2 चीज़ों जितना अच्छा है जिन्हें grounding test नहीं करती: क्या graph की edges खुद correct हैं, Concepts 7 और 8 risk घटाते हैं पर कुछ remove नहीं करता; और क्या checker existing paths reliably ढूँढता है। "Checker ने graph consult की" claim, "checker को impression था" से better है। लेकिन फिर भी model की produced claim है। कैसे जानें checker अच्छा है? उसका पूरा discipline है और वही next course है: Trusting the Checker।
Ungrounded reviewer critic है: "मुझे पसंद नहीं आया।" Grounded reviewer auditor है: "Line 4 payment claim करती है। File में receipt नहीं। Receipt दें या line हटाएँ।" Critic से हमेशा बहस कर सकते हैं। Auditor की demand या meet होती है या नहीं।
अपने project की 3 claims file में लिखें, 2 किसी real चीज़ से supported और 1 invented। फिर Concept 9 की hand-built subgraph के against checker run करें:
claude -p 'Subgraph (triples with ids): <paste>. Claims: <paste>.
For each claim, cite the triple ids that support it. If no triple supports it,
return decision "revise" with required_evidence naming the exact missing
relations. Never approve on plausibility. Return JSON only.'
Invented claim के साथ क्या होता है, देखें। Checker फिर भी approve करे तो working checker से अधिक valuable चीज़ मिली: next course की वजह।
Grounded checker report की हर claim पर PASS return करता और हर एक के लिए edge IDs cite करता है। एक week बाद एक claim false prove होती है। वे 2 places list करें जहाँ failure हो सकती है और हर one को कौन-सा course fix करता है। या तो graph गलत थी, यानी bad extraction या false merge ने memory में wrong edge डाली। यह Part 3 का discipline problem है: resolution tighten करें, provenance audit करें और failure को gold case बनाएँ। या checker गलत था, उसने ऐसी edge cite की जो claim support नहीं करती। यह checker-quality problem है, जिसे Trusting the Checker measure करता है; वहाँ irrelevant edges cite करने वाले fluent answers named failure mode हैं। Grounding ने "कहीं कुछ wrong है" को 2 auditable suspects तक narrow किया। वही win है।Answer देखें
Part 5: Loops की Graph
Parts 2 से 4 ने ऐसी graphs बनाईं जिनके nodes records हैं: commits, entities, claims और sources। यह part node का meaning बदलता है। Zoom out करें जब तक हर loop एक point न बन जाए, फिर पूछें points कैसे connect होते हैं। यही governance graph है, इस course के 2 meanings में दूसरा। यह decide करती है कि loops का system honest रहता है या केवल busy।
11. Wiring: कौन किसे feed करता है, कौन किसे check करता है
इसे run करें: companion lab में python3 concepts/11-wiring.py। पढ़ना आधा है। इसे होते देखना बाकी आधा।
18 जुलाई 2026 को Peter Steinberger, loop course के start की "you should be designing loops that prompt your agents" voice, ने midnight के बाद 12-word question post किया: "Are we still talking loops or did we shift to graphs yet?" कुछ hours में वह slogan बन गया। करीब साढ़े 4 hours बाद Hamel Husain ने "Loop Engineering Is Dead. Enter Graph Engineering" title का article publish किया और Santiago Valdarrama ने सबसे दूर फैलने वाली line post की: "Loop engineering is dead. Long live graph engineering!" एक बार फिर सावधान रहें कि किसने क्या कहा। Steinberger ने केवल question पूछा था। उसके words industry की naming treadmill पर joke जैसे लगते हैं, announcement नहीं। Obituary दूसरों ने लिखी और वह भी joke जैसी लगती है। लेकिन noise के पीछे real idea है, जिसे Carlos E. Perez का essay From Loop Engineering to Graph Engineering? साफ़ map करता है।
आप loop जानते हैं: एक agent का behavior, heartbeat, body और spine। Governance graph में loop node है और graph nodes के बीच wiring है। इसे settle होने से पहले correction: हर node loop नहीं। Human gate node है। Ground-truth check node है। Frozen checker node है। Precise version: agent loop node हो सकता है। दूसरे nodes human decisions, outside systems और ऐसे measurements हैं जिन्हें हर कोई accept करता है।
यह familiar लगे तो सही है: loop course में बिना नाम के governance edges बनाई थीं। Maker–checker split edge है: एक loop का output दूसरे का input बनता है। Two-routine gate 3-node graph है: Routine A draft करती है, human decide करता है और decision Routine B fire करता है। Dreaming loop भी graph है: एक loop हर दूसरे loop के logs पढ़कर gate से changes propose करता है। इसलिए slogan honestly पढ़ें: graph composed loops है। Loops हटाएँ तो graph खाली boxes है।
एक distinction आगे का सब organize करती है। "Loop" word 2 अलग machines cover करता है और वे अलग तरह fail होती हैं:
- Execution loop recurring work करता है: issues triage, PR review या changelog draft। Loop course की लगभग हर चीज़।
- Improvement loop target के against number देखता है और काम करने वाला system adjust करता है: gap measure करें, उसे घटाने के लिए act करें, फिर घूमकर आएँ। Dreaming loop इसका सबसे clear built example है।
Stopping condition miss करने वाले execution loop को better spec चाहिए। अपना number game करने वाले improvement loop को अपने चारों ओर structure चाहिए। अगला concept वही structure है।
Graph में सोचते समय 3 practical questions center में आते हैं। कोई नया नहीं, पर अब हर loop के बजाय हर edge पर एक बार पूछे जाते हैं। Routing: loop A finish करे तो result किसे मिले, loop B, human या किसी को नहीं? Trust boundaries: edges standing permissions हैं, इसलिए कौन-सा loop किसे और किस identity में fire कर सकता है? Missing edge वह work है जो silently कभी नहीं पहुँचता। Gate placement: human वहाँ रखें जहाँ wrong automatic move costly और hard to reverse हो। यह dial पहले per loop set होता था। अब per edge set होता है, gate node के अंदर नहीं, nodes के बीच बैठता है।
Routing में builders model को intended से अधिक authority दे देते हैं, इसलिए एक rule plain कहना ज़रूरी है। Request को classify करने वाला model ठीक है और इसमें अच्छा है। System को आगे क्या करने की permission है, यह choose करना बिल्कुल अलग job है। दोनों split करें। Classifier probabilistic है और label return करता है। Route table deterministic है और labels को paths map करती है: low risk short path पर, high risk full audit पर, unrecognized कुछ भी human gate पर। Classification पर model judgment मिलता है, authority पर improvisation नहीं। यह Concept 13 का frozen node permissions पर apply हुआ है, metrics पर नहीं, और frozen check.py जैसा dividend देता है। कुछ गलत path पर जाए तो extinct reasoning paragraph reconstruct करने के बजाय label और table की ओर point कर सकते हैं।
Loop एक worker है जो आपके बिना चलता है। Governance graph workers को जोड़ने वाला org chart है, साथ में targets own करने वाला manager, fights settle करने वाला referee और वे measurements जिनसे कोई बहस नहीं कर सकता। जो workers अभी exist नहीं करते, उनका useful org chart नहीं draw कर सकते। इसलिए loop course पहले आया।
आज चलने वाले हर loop, checker और human gate को one per line list करें। फिर हर relationship के लिए एक arrow draw और verb से label करें: fires, reviews, approves, audits। First drawing में 2 findings लगभग universal हैं। किसी loop तक checking की incoming arrow नहीं आती और किसी number को कोई नहीं देख रहा। दोनों missing edges हैं और अगला concept उनकी cost बताता है।
फिर हर drawn arrow एक question से audit करें: क्या arrow के head वाला node सच में tail का produced output पढ़ता है या केवल बाद में run होता है? Sequence dependency नहीं है। केवल order record करने वाली arrow ऐसी queue है जिसका wall-clock time आप pay करते हैं। उसे काटने की cost केवल वह habit है जिसने उसे draw किया। Habit का clear source है: instructions lines में लिखी जाती हैं, यह करें फिर वह और फिर दूसरी चीज़। Diagram prose से आया shape inherit करता है, work से नहीं। अधिकतर लोग 12-node chain में केवल 3 real dependencies पाते हैं।
12. Perez की single loop की 4 failures
इसे run करें: companion lab में python3 concepts/12-four-failures.py। पढ़ना आधा है। इसे होते देखना बाकी आधा।
Perez का essay story से शुरू होता है: support team ticket-resolution rate optimize करने वाला loop बनाने में एक quarter लगाती है। Number चढ़ता है। फिर renewal data आता है और customers पुराने rate से 2 गुना जा रहे हैं। Bot ने customers को दूर करके tickets close करना और abandoned problems को "solved" mark करना सीख लिया। Loop perfectly काम कर रहा था। उसका number quietly real outcome represent करना बंद कर चुका था। यह failure miniature में पहले देखी है: इसलिए autoresearch agent prepare.py कभी edit नहीं कर सकता और loop course का portfolio project check.py छूना forbid करता है।
Perez single loop के टूटने के 4 तरीके बताता है। हर break graph की edge से fix होता है, better loop से कभी नहीं:
| Single loop कैसे टूटता है | कैसा दिखता है | Graph का answer | आपने पहले कहाँ देखा |
|---|---|---|---|
| Gaming (Goodhart's law) | Loop अपने number को real outcome betray करने वाले तरीकों से move करता है | हर optimizing loop को counter-metric वाले watching loop से pair करें; resolution rate के साथ renewal rate | prepare.py / check.py rules और read-only reviewer |
| ऊपर की blindness | Loop के अंदर कोई नहीं पूछ सकता कि उसका target सही है या नहीं | Slower loop faster loop का target own करता है, इसलिए targets बदलना governed work है | केवल आप पूछ सकते हैं loop किसलिए है, loop course की context-advantage lesson |
| Conflict | अलग बने loops एक-दूसरे से लड़ते हैं और हर one अकेले perfect दिखता है | उनके ऊपर arbitration node, supervising loop या human gate, जो trade-off own करे | क्या ship होगा, यह decide करने वाला human gate |
| Measurement decay | Checking reality से slide होकर एक report को दूसरी report से check करने लगती है | Independent audit loops test करती हैं कि numbers अभी world को touch करते हैं या नहीं | Dreaming loop और "green का अर्थ done नहीं" |
Table को एक sentence की तरह पढ़ें: हर fix edge है, better loop कभी नहीं। Governance graph अपने नाम को यहीं earn करती है।
Loop केवल अपना number देख सकता है, इसलिए number के real result का meaning खोने के बाद भी उसे chase करेगा। Fix "loop पर और trust करें" कभी नहीं। Fix structure है: counter-metric का watcher, target own करने वाला slower loop, conflicts के ऊपर referee और numbers को reality के against check करने वाला auditor।
Triage loop का "issues closed per day" एक month तक चढ़ता है और team celebrate करती है। Perez की 4 failures में पहले किसे rule out करना चाहिए और कौन-सी edge उसे rule out करती है? Gaming। Rising close-rate ठीक support-bot story का shape है: issues close करने का cheapest तरीका उन्हें badly close करना है। उसे rule out करने वाली edge counter-metric का watching loop है: reopen rate या हर closed issue पर reader complaints। Closes बढ़ने के साथ counter-metric stable रहा तो celebrate करें। Counter-metric कोई नहीं देख रहा तो number unaudited है और celebration definition से premature।Answer देखें
13. Anchors और frozen nodes: graph खुद को fool कर सकती है
इसे run करें: companion lab में bash concepts/13-anchors-audit.sh। पढ़ना आधा है। इसे होते देखना बाकी आधा।
यह Perez की warning है और slogans इसी part को छोड़ते हैं। यह course की सिखाई दोनों graphs पर समान force से apply होती है।
Governance version। ऐसी graph imagine करें जहाँ हर loop केवल दूसरे loops की reports पढ़ता है। Loop A, loop B के numbers check करता है। B के numbers C से आते हैं। C, A और B से बने dashboard को पढ़ता है। हर चीज़ हर चीज़ से agree करती है। Reality के against कुछ check नहीं हुआ। Perez इसे circular graph कहता है। वह single loop की तरह fail होती है, बस later, अधिक expensively और गिरते समय अधिक green lights के साथ।
Memory version। अब "loops" को "claims" से replace करें। Knowledge graph की हर claim source cite करती है और हर source दूसरे agent की report है, जिसके sources और agent reports हैं। Concept 8 की 4 invariants pass करती हैं, क्योंकि वे receipts का existence enforce करती हैं, receipts किससे बनी हैं यह नहीं। Internally perfect, externally untethered: वही circle, JSON में draw किया हुआ।
2 costumes में एक failure, इसलिए एक fix 2 बार पहना जाता है। Graph को 3 चीज़ें चाहिए जो arrows का कोई arrangement नहीं दे सकता:
- Anchors: ऐसे measurements जिनसे कोई loop बहस नहीं कर सकता और ऐसे sources जिन्हें model ने produce नहीं किया: सच में चले tests, सच में रुके customers, सच में आया पैसा, humans के लिखे documents। Last kind पर strict रहें। Run log केवल उन cited lines पर anchor है जो model के बाहर किसी चीज़ का captured output हैं: test runner, compiler, database, API या operating system। Log file में agent की own prose filename पहना model output है और उसे cite करके circular graph अपना audit pass करती है।
- Frozen nodes: ऐसी rules जिन्हें optimizing loops बदल नहीं सकते, exactly इसलिए कि वे बदलना चाहेंगे:
check.py,prepare.py, held-out test set और claims schema खुद। - Graph के बाहर से root judgment: "better का meaning क्या है?" Machinery answer produce नहीं कर सकती, क्योंकि हर loop उसे पहले से assume करता है। Answer people से आता है। यह loop course का Concept 1, intent और accountability, opposite direction से मिला है। ये आख़िरी चीज़ें नहीं जिन्हें graph automate करती है। ये वे चीज़ें हैं जिन्हें graph contain ही नहीं कर सकती।
दोनों costumes में audit same है: leaves follow करें। 10 random verdicts, governance, या 10 random claims, memory, चुनें और हर one के bottom तक walk करें। Count करें कितने दूसरे model की report के बजाय reality पर खत्म होते हैं। वह count एक number में system की grounding है।
Practice में आपके लिए क्या बदलता है। First loop के बारे में कुछ नहीं: उसे exactly loop course की तरह बनाएँ। Second के बारे में सब कुछ। जैसे ही 2 loops काम exchange, state share या एक-दूसरे को trigger, review या constrain करते हैं, आप graph engineering कर रहे हैं, नाम इस्तेमाल करें या नहीं। Cheap starting version 2 rules हैं: हर optimizing loop को एक watching loop मिले और graph का कम-से-कम एक signal reality से आए, दूसरे model की report से नहीं।
और एक prediction, जो Perez करता और यह book agree करती है: anchors के बिना बनी loops की graphs भी circular, consistent और convincing तरीके से fail होंगी। फिर discourse next name पर jump करेगा। Lasting question loops versus graphs कभी नहीं था। वह grounded versus ungrounded है: आपकी machinery, shape जो भी हो, क्या अभी उस reality को touch करती है जिसे improve करने का claim करती है?
Ring में एक-दूसरे को cite करने वाले 3 newspapers 3 sources नहीं हैं: किसी को event attend करना होगा। Rule loops checking loops की ring हो या claims citing claims, same है। Anchors वे reporters हैं जो सच में वहाँ थे। Frozen nodes ethics rules हैं जिन्हें reporters rewrite नहीं कर सकते। और "news किसे मानें" editor decide करता है, printing press कभी नहीं।
Team beautiful graph बनाती है: 5 loops, paired metrics, audit loop और human gate। लेकिन हर loop केवल दूसरे loops की produced reports पढ़ता है। क्या missing है और क्या wrong होगा? Anchor। Graph circular है: हर loop दूसरे loop को confirm करता है, लेकिन reality के against कुछ check नहीं होता। वह single loop की तरह fail होगी, बस later, अधिक expensively और रास्ते में अधिक green lights के साथ। कम-से-कम एक signal reality से आना चाहिए: सच में चला test, सच में रुका customer या सच में आया पैसा।Answer देखें
इस book की अपनी spirit में एक caution
एक caution। Industry हर season frontier का नाम बदलती है: prompt engineering, फिर context engineering, harness engineering, loop engineering और अब एक साथ 3 flavors में graph engineering। हर name partly real और partly noise है। हर layer previous को wrap करती है: graph shared memory वाली composed loops है। Idea slogan से पुराना है। MLOps pipelines, company governance और body का regulation, सभी shared records पर अलग speeds से चलती loops की graphs हैं। 2026 में नया visible यह हुआ कि capable agents unattended इन loops को चला सकते हैं, इसलिए wiring और memory के questions builders के बहुत बड़े group तक पहुँचे। Names तेज़ बदलते हैं। नीचे का shape धीरे बढ़ता है। Shape सीखें और next rename की cost एक afternoon होगी, course नहीं।
Part 6: एक Graph, शुरू से अंत तक
Theory खत्म। यह part उस system को upgrade करता है जिसे 2 बार बना चुके हैं: loop course का morning-triage loop, harness course से fenced, prose spine से छोटी queryable graph तक। केवल files और shell, न database, न framework: graph repo में 3 JSON files है और discipline storage नहीं, schema है। दोनों tools इसे run करते हैं। केवल headless command अलग है।
Disk पर shape
graph/
SCHEMA.md # the contract: fields, types, and the write rules
entities.json # nodes: things the loops talk about
claims.json # edges-with-receipts: what the loops have established
runs.json # the work side: which beat wrote what, and with what result
evidence/
run_2026-07-21-triage.log # raw tool output a claim can point at
2 directories, क्योंकि वे अलग चीज़ें रखती हैं। graph/ curated memory है, छोटी और schema-checked। evidence/ वह raw output है जिसकी ओर claims point करती हैं: test runs, command output और API responses। evidence/ में कुछ कभी edit नहीं होता।
JSON कब पर्याप्त नहीं रहती? Instinct के डर से later और इस design के suggestion से sooner। हर append पर rewritten single file कुछ हज़ार claims तक comfortable है और लगभग 10,000 पर hurt करने लगती है: jq scans slow, एक नई row के लिए पूरी file rewrite और same moment append करते 2 loops write खो सकते हैं। Upgrade path जानबूझकर boring है, क्योंकि discipline storage नहीं, schema है। Relational table, यानी Postgres या एक machine पर SQLite, real ids, subject और predicate indexes, concurrent appends को collide होने से रोकने वाली transactions और Git hook के बजाय database trigger से enforced append-only देती है। Graph database, Neo4j या Neptune, उससे आगे एक चीज़ देती है: multi-hop traversal ऐसा query बनता है जिसके code को maintain नहीं करना पड़ता। यह तब matter करता है जब context builder 1 या 2 नहीं, 3 या 4 hops walk करे। कोई move invariant नहीं बदलता। Query slow या write lost हो तब move करें, पहले नहीं।
एक पूरी claim। एक record में पूरा discipline:
{
"id": "claim_0007",
"subject": "test_payments_flaky",
"predicate": "diagnosed_as",
"object": "tz_default_utc",
"confidence": 0.9,
"source": {
"kind": "tool_output",
"command": "pytest tests/test_payments.py -x",
"exit_code": 1,
"ref": "evidence/run_2026-07-21-triage.log#L88-L94",
"captured": "2026-07-21T09:14:22Z"
},
"produced_by": "run_2026-07-21-triage",
"supersedes": "claim_0004",
"created": "2026-07-21"
}
Copy करने से पहले एक चीज़ notice करें: यह claim supersedes रखती है, इसलिए assume करती है कि claim_0004 file में पहले से है। आपकी पहली claim में supersedes field बिल्कुल नहीं। ऐसी claim की ओर point करें जो कभी लिखी नहीं और नीचे का hook commit सही तरह रोकेगा: supersedes points at a claim that does not exist। यह भी note करें कि claims.json एक array है, single claim होने पर भी। इस page की हर jq query .[] से शुरू होती है।
और id की caveat, जिस पर नीचे maker skill लौटती है। claim_0007 counter है और interrupted हो सकने वाले loop को exactly counter use नहीं करना चाहिए। इस page पर इसलिए बची है कि derived id से better पढ़ती है और नीचे हर example इसी reason से रखता है। Real repo में derived form use करें।
दूसरी 2 files छोटी हैं। Entity identity और aliases है:
[
{
"id": "test_payments_flaky",
"type": "TEST",
"aliases": ["tests/test_payments.py::test_tz", "the flaky payments test"],
"first_seen": "2026-07-14"
}
]
और run एक beat की receipt है:
[
{
"id": "run_2026-07-21-triage",
"beat": "morning-triage",
"started": "2026-07-21T09:11:04Z",
"tool": "claude-code",
"evidence": ["evidence/run_2026-07-21-triage.log"],
"claims_written": ["claim_0007"],
"verdict": "PASS"
}
]
अब ऊपर की claim की 2 deliberate चीज़ें, दोनों लगभग गलत थीं।
status field नहीं है। Claims append-only हैं: कुछ edit या delete नहीं होता। Claim अभी current है या नहीं, store नहीं बल्कि read time पर derive किया जाता है: अगर कोई later claim उसे supersede नहीं करती तो active है। एक jq expression answer देती है और rule drift नहीं कर सकती, क्योंकि truth की second place नहीं। यही accounting analogy सही तरह है। Correcting entry पीछे जाकर original entry modify नहीं करती।
# active claims = those that nothing supersedes
jq '[.[].supersedes] as $dead
| [.[] | select(.id | IN($dead[]) | not)]' graph/claims.json
इसे 2 steps में पढ़ें: हर id collect करें जिसे later claim supersede करती है, फिर वे claims रखें जिनकी id उस list में नहीं। एक trap का नाम लेना ज़रूरी है, क्योंकि obvious one-liner गलत है: .[] पर इसे select(any(.[]; ...)) में fold न करें। select के अंदर current input single claim है, इसलिए any(.[]; ...) उस claim के own fields walk करके error करती है। 2-step form error बचाती और better पढ़ती है।
Predicate diagnosed_as है, caused_by नहीं। Exit code 1 वाला failing test prove करता है कि कुछ fail हुआ। वह failure का cause prove नहीं करता: यह step output की agent reading है। इसलिए claim वही कहती है जिसे support कर सकती है। caused_by upgrade के लिए red test से अधिक evidence चाहिए: failing assertion, जिस configuration line की ओर वह point करती है और ideally timezone assumption correct करने के बाद passing rerun। फिर दोनों runs cite करने वाली नई caused_by claim append करें जो इस claim को supersede करे। Evidence जिस predicate को सच में support करता है उसे choose करना इस पूरे discipline में honesty का smallest और सबसे repeatable act है।
Source tool का नाम लेती है, agent का नहीं। Command, exit code, timestamp और line range वाला "kind": "tool_output" ऐसी चीज़ की ओर point करता है जिसे model ने नहीं लिखा: pytest fail हुआ और यहाँ उसने कहा। इसे ऐसे source से compare करें जो agent की own log में typed sentence की ओर point करे। वह invariant 1 का letter satisfy करते हुए model output पर point करेगा, यानी single field में Concept 13 की circular graph। Rule: run log केवल वहाँ anchor है जहाँ cited lines model के बाहर किसी चीज़ का captured output हैं, जैसे test runner, compiler, database, API या operating system। Log file में agent की prose claim है, claim का evidence नहीं।
Concept 8 invariants के against claim check करें: real source, invariant 1; authoring run, invariant 2; और addressable रहने वाला superseded predecessor क्योंकि उसे छुआ नहीं गया, invariant 4। Invariant 3 नीचे reviewer के साथ आता है।
Maker graph में लिखता है
Triage skill में जोड़ा एक paragraph loop की छोड़ी चीज़ बदल देता है। Old skill कहती थी "update progress.md," नई कहती है:
## 5. Update the graph last
For every durable finding this beat established, append one claim to
graph/claims.json following the schema in graph/SCHEMA.md. Rules:
- claims.json is APPEND-ONLY. Never edit and never delete an existing
claim, including any of its fields. To correct a claim, append a new one
whose "supersedes" names the old id. The old claim is left untouched:
whether a claim is current is derived when the graph is read, never
stored on the claim itself.
- Every claim needs a source a later agent could open and verify. Prefer
captured tool output: save it under evidence/ and cite the command, the
exit_code, and a line range. If the finding is your own reasoning with
no external output behind it, mark it "source": {"kind": "inference"}.
- Never cite your own prose in a log as the evidence for your own claim.
- New entities go in entities.json first. Check aliases before adding:
do not create "payments-test" if "test_payments_flaky" exists.
- Derive each claim id from the run and the finding, never from a counter,
and check whether that id already exists before appending. A beat that is
interrupted and rerun must produce the SAME id for the same finding, so
the retry writes nothing instead of writing a second copy. claim_0007
reads well on a page. In a loop that can die halfway, use something a
rerun reproduces exactly, such as
claim_run_2026-07-21-triage_tz-default.
- Session notes, dead ends, and chatter stay in progress.md. The graph
is for what was established, not what was said.
Last rule सबसे important है। Spine disappear नहीं होती, loop की diary रहती है। Graph diary ने जो prove किया उसका छोटा, strict record है। 2 memories, 2 truth standards, exactly Concept 3 की 2 graphs की तरह।
Id rule वह है जिसके बिना build लगभग ship हुआ और यह pedantry क्यों नहीं, समझना ज़रूरी है। claim_0007 counter है और counter को याद नहीं कि क्या count कर रहा था। Beat claim append करके commit से पहले die हो जाए तो rerun same finding को claim_0008 की तरह फिर append करेगा और नीचे hook का हर check pass होगा: fields present, ids unique, supersession resolves और committed कुछ नहीं बदला। अब एक fact 2 ids के तहत 2 बार है, 2 runs हर one को establish करने का claim करते हैं। Duplicate months बाद ऐसे disagreement में surface होती है जो कभी हुआ ही नहीं। Derived id दोनों ends से hole close करती है। Maker id ढूँढकर मिलने पर skip करता है, इसलिए retry no-op है। जिस दिन maker देखना भूले, hook की unique-id rule silently memory double करने के बजाय commit block करती है। Retry safely repeat कर सके ऐसी writes interruption survive करने वाली graph और quietly shadow copy उगाने वाली graph का difference हैं।
Harness rules को real बनाता है, क्योंकि guardrail harness में रहती है, prompt में कभी नहीं। ऊपर कई rules mechanically checkable हैं, इसलिए hook जो कर सकता है check करता है:
#!/bin/sh
# .git/hooks/pre-commit — the graph gate (jq only, no framework)
C=graph/claims.json
fail() { echo "claims.json: $1 — commit blocked"; exit 1; }
# 1. required fields on every claim
jq -e 'all(.[]; has("id") and has("subject") and has("predicate")
and has("object") and has("source") and has("produced_by"))' "$C" \
>/dev/null || fail "a claim is missing a required field"
# 2. ids are unique
[ "$(jq 'length' "$C")" = "$(jq '[.[].id] | unique | length' "$C")" ] \
|| fail "duplicate claim id"
# 3. every supersedes target exists
jq -e --argjson ids "$(jq '[.[].id]' "$C")" \
'all(.[]; (has("supersedes") | not) or (.supersedes | IN($ids[])))' "$C" \
>/dev/null || fail "supersedes points at a claim that does not exist"
# 4. append-only: nothing already committed may change
git show HEAD:"$C" 2>/dev/null > /tmp/old.json || exit 0
jq -e --slurpfile new "$C" \
'all(.[]; . as $o | $new[0] | any(.[]; . == $o))' /tmp/old.json \
>/dev/null || fail "an existing claim was modified or removed"
Gate की boundary पर honest रहें, क्योंकि course request और enforced rule का difference insist करता है। वे 4 checks real हैं: required fields, unique ids, resolvable supersession और append-only history। Hook field types, subject की entity entities.json में exist करती है या नहीं, source block well-formed है या cited evidence file और line range exist करती है या नहीं, check नहीं करता। जिस दिन चाहिए, हर one एक और jq line है। लिखने तक rule केवल SCHEMA.md में है, इसलिए guidance है, guardrail नहीं। आपकी कौन-सी rule कौन है, यह जानना distinction का पूरा point है।
Reviewer graph से पढ़ता है
Reviewer के prompt को एक obligation और verdict को एक field मिलता है। Operating size पर Concept 10:
You are the reviewer. For every factual claim in the maker's report:
1. Find the claim in graph/claims.json that supports it. Cite its id.
2. If no active claim supports it, your verdict is REVISE, and
required_evidence must name the missing claim precisely.
3. A claim whose source.kind is "inference" cannot by itself ground a
factual assertion. Either cite a source-backed claim that supports it,
or return REVISE. An honestly recorded guess is still a guess.
4. Never approve a factual claim on plausibility. "Sounds right" is
not a citation.
Return only JSON:
{ "verdict": "PASS|REVISE|FAIL",
"grounded_in": ["claim_0007", "claim_0012"],
"missing": [],
"rubric": "reviewer-rubric-v3" }
Rule 3 लोग छोड़ते हैं और छोड़ना पूरे build को quietly undo करता है। Maker को inference honestly record करने की permission है, जो सही है: marked guess laundered guess से better है। लेकिन reviewer केवल cited claim के existence को check करे तो marked guess shipped factual statement ground कर सकती है और graph ने उसे आख़िर launder कर दिया। Honest inference और grounding evidence अलग jobs हैं। Reviewer का task उन्हें अलग रखना है।
rubric field invariant 3 है और grounded_in field auditable trail। Months बाद कोई shipped PR खोलकर verdict से claims और फिर sources तक walk कर सकते हैं। हर important output objective, artifact, source, graph path और evaluator decision तक traced: PDF का closing test, 3 JSON files के scale पर pass।
एक beat, पहले और बाद में
पहले, केवल spine। Tuesday का triage beat flaky payments test fix करके prose लिखता है: "fixed flaky test, was a timezone thing." Thursday को अलग changelog loop payments fix mention करता है और reviewer plausibility पर approve करता है। 3 weeks बाद कोई पूछता है कौन-सी timezone assumption थी और answer transcripts की archaeology dig है।
बाद में, graph। Tuesday का beat ऊपर claim_0007 लिखता है और evidence/ में captured pytest output cite करता है। Thursday को changelog loop का context builder test_payments_flaky के आसपास 2-hop subgraph pull करता है: claim, उसका source ref और producing run। Reviewer changelog entry approve करता है क्योंकि grounded_in: ["claim_0007"] resolve होती है। 3 weeks बाद question का answer jq से एक line में receipt के साथ मिलता है:
jq '[.[].supersedes] as $dead
| .[] | select(.subject == "test_payments_flaky")
| select(.id | IN($dead[]) | not)' graph/claims.json
Same loops। Same model। केवल memory की जगह बदली और उसने बदल दिया कि हर बाद का agent और human क्या जान सकता है।
Build को एक बार और पढ़ें, अब Part 5 का second lens मिल चुका है। Tiny system दोनों graphs एक साथ रखता है। Reviewer-to-maker relationship governance edge है, watching loop जिसकी maker पर counter-metric "हर claim resolves" है। Pre-commit schema hook frozen node है: makers अपने check rules tune नहीं कर सकते। source blocks anchors हैं, लेकिन केवल उनकी target चीज़ के कारण: command, exit code और test runner का captured output। Same field को agent की अपने बारे में written sentence पर point करें और schema pass होते हुए anchor evaporate हो जाता है। 3 JSON files, 1 hook, 2 prompts और इस course का हर idea miniature में मौजूद है।
Throwaway repo में 1 entity और 0 claims के साथ 3 JSON files बनाएँ। किसी small real task पर ऊपर graph-writing skill के साथ एक maker beat headlessly, claude -p या opencode run, run करें। फिर maker report पर reviewer prompt run करें। First pass पर उसे missing field के साथ REVISE करते देखें, क्योंकि maker ने under-record किया। वह failure lesson है: reviewer ने maker को अभी सिखाया कि graph में क्या होना चाहिए।
Part 7: Grounded रहना
14. Level choose करना और उसका budget
इसे run करें: companion lab में python3 concepts/14-choose-a-level.py। पढ़ना आधा है। इसे होते देखना बाकी आधा।
Graphs के against case से पहले, एक choose करने की procedure। Order में पूछे 6 questions decide करते हैं कि job को सच में कितना structure चाहिए। हर "no" एक layer बचाता है।
- क्या success verify हो सकती है? नहीं तो autonomy से बिल्कुल शुरू न करें। पहले test, rubric, source requirement या human decision define करें। यह loop course का first gate है और यहाँ missing answer बाद की कोई चीज़ repair नहीं करती।
- क्या steps stable हैं? हाँ तो chain पर्याप्त है। नहीं तो planning या orchestrator चाहिए।
- क्या subtasks independent हैं? हाँ तो parallelize करें। नहीं तो dependencies explicitly model करें और एक साथ लिखने वाले workers limit करें।
- क्या alternative lineages available रहनी चाहिए? हाँ तो हर result को one branch में force करने के बजाय DAG use करें। यह Concept 5 का question है।
- क्या facts run के बाद survive करने चाहिए? हाँ तो artifacts और graph state persist करें। उन्हें transcript summary पर depend न करें।
- क्या cost और latency afford कर सकते हैं? Workers जोड़ने से पहले budgets set करें, invoice के बाद नहीं।
साथ answer करने पर वे preference नहीं, level produce करते हैं:
| आपकी situation | इससे शुरू करें | क्यों |
|---|---|---|
| Simple, low-risk question | Zero-shot | Lowest latency, maintain करने की machinery नहीं |
| Output check हो सकता है | Loop | Repeated feedback artifact improve करती है |
| Sequence stable है | Chain | Predictable, testable stages |
| Categories clear हैं | Router | Policies और models cleanly separate करता है |
| Units independent हैं | Parallel workers | Wall-clock time घटाता है |
| Decomposition हर task में बदलती है | Orchestrator-workers | Dynamic specialization |
| Alternatives alive रहनी चाहिए | Commit DAG | Experiment branches preserve करता है |
| Facts sessions survive करने चाहिए | Knowledge graph | Persistent shared memory |
| बहुत बड़ा parallel work | Dynamic workflow | Fan-out और fan-in automate करता है |
Notice करें graph 8वीं row है, पहली नहीं। अधिकतर work पहले रुकता है और पहले रुकना correct outcome है, ambition failure नहीं।
जो level choose करें, run शुरू होने से पहले complexity budget declare करें। हर run written form में बताए: maximum model calls, maximum sub-agents, maximum concurrent workers, maximum tool calls, maximum wall-clock time, maximum tokens, maximum financial cost, maximum retries, maximum graph writes और किसी चीज़ को finished कहने से पहले required minimum evidence। Last item लोग भूलते हैं और वही बाकी numbers meaningful बनाता है।
फिर budget खत्म होने की rule, जो numbers से अधिक matter करती है: best current artifact, completed work, unresolved issues और stopping reason return करें। Fluent final answer के पीछे partial failure hide न करें। "Token budget खत्म हुआ इसलिए 60 में 40 files पर रुका और ये 40 क्या दिखाती हैं" कहने वाला run quietly two-thirds cover करने वाली confident report से अधिक valuable है।
उस budget के साथ number रखें, क्योंकि machinery free नहीं और 14 concepts तक इसे sell करने वाला course invoice owe करता है। Anthropic का multi-agent research system write-up report करता है कि architecture ने breadth-first work पर single agent को substantially outperform किया और ordinary chat interaction से लगभग 15 गुना tokens consume किए। Trade एक sentence में: parallel breadth coverage खरीदती और tokens में pay करती है। Shape को cost earn करनी है। Bounded extraction, classification और formatting के लिए cheap models। Decomposition, synthesis और hard verification के लिए strong models। Simple requests के लिए short paths। Full graph केवल उस work के लिए जिसकी value coordination justify करती है। 100 workers सही answer तब हैं जब task genuinely wide, branches सच में independent और result spend deserve करता हो। जब one context window पूरा problem hold कर सकती है, तब wrong answer हैं।
Budget decide करता है कितना spend होगा। एक further decision decide करता है system कहाँ wait करता है। गलत होने पर पूरा spend waste होता है लेकिन parallelism जैसा दिखता है। Work fan out हो तो कुछ आखिर gather करता है और हर stage के बाद barrier fan को quietly फिर chain बनाती है। Complete set का wait केवल वहाँ करें जहाँ next node को सच में सब चाहिए: sources के across deduplicate, every candidate को हर other के against rank, alternatives compare या coverage sufficient judge करना। जहाँ हर result खुद आगे जा सकता है, जाने दें। Gather करते समय one failed branch finished 99 को discard न करे। Settled चीज़ collect, incomplete record और next node को decide करने दें कि continue करने के लिए enough है या नहीं। यह ऊपर partial-failure rule है, whole run के बजाय join पर applied। System कहाँ still रहता है topology decide करती है, worker count नहीं।
Build से पहले 6 questions पूछें और उन्हें smallest fitting structure बताने दें। फिर limits advance में लिखें, क्योंकि system को stop कब करना है कभी न बताया हो तो money खत्म होने के moment पर रुकेगा और उस moment को success describe करेगा।
Team knowledge graph चाहती है। Answers: success verifiable है, steps stable, subtasks independent, alternative lineages matter नहीं और facts को run survive नहीं करना। 6 questions कौन-सा level देते हैं? Stable chain पर parallel workers, graph नहीं। Question 4 no है, इसलिए DAG नहीं। Question 5 no है, इसलिए knowledge graph नहीं। वे 8वीं row चाहते थे और questions ने 5वीं दी। फिर भी graph बनाने का meaning उन questions के लिए extraction errors और schema upkeep pay करना है जिन्हें अभी किसी ने पूछा नहीं।Answer देखें
15. Graph कब न बनाएँ
इसे run करें: companion lab में python3 concepts/14-choose-a-level.py। पढ़ना आधा है। इसे होते देखना बाकी आधा।
Concept 14 ने procedure दी। यह concept उस level के against case देता है जिसे course 14 concepts से sell कर रहा है, book की honest grading tradition में। केवल system में agents होने के कारण knowledge graph introduce न करें। Graph real bill वाली machinery है: extraction errors, resolution risk, schema maintenance और silently rot होने वाली नई चीज़। इसे skip करें जब:
- tasks independent हों और cross-session state न चाहिए,
- answers एक बार में एक document से आएँ,
- relations fixed और simple हों: relational table हर real query already answer करे,
- provenance required न हो या
- extraction errors traversal value से अधिक हों।
Connected queries, evolving relations, provenance या shared world state central हो तो graph cost earn करती है। Spine वाले one loop को graph नहीं चाहिए। 2 loops facts exchange करें या 20 workers को synthesis चाहिए तो balance बदलता है। Part 6 build जानबूझकर smallest version है जो bar clear करता है।
और built graphs के 2 failure modes:
Graph builder judgment amplify करती है, bad judgment भी। Loop objective और evaluator amplify करता है। Lesson 2 बार सीखा। Graph अपनी ontology और source policy amplify करती है। Wrong entity types choose, wrong sources admit करें और automation error scale करती है: biased corpus biased graph बनाता है जो हर direction में confidently answer करती है। Graph claims inspect करती है। उन्हें truth में launder नहीं करती।
Metrics यहाँ भी game हो सकती हैं। केवल entity recall के लिए tuned extraction pipeline खुशी से graph flood करेगी। केवल compression के लिए tuned resolution step strangers merge करेगी, Concept 7 का trap। हर optimization को counter-metric चाहिए: recall के against precision, false merges के against compression। यही Goodhart's law है। Next course detail में देखता है।
और built graphs पर Concept 13 audit चलाते रहें: 10 random claims को leaves तक follow करें और count करें कितनी दूसरे model की report के बजाय reality पर bottom out होती हैं। Anchors के बिना memory graph Part 5 की circular graph है, JSON में rebuilt।
Graph facts की bureaucracy है। Good bureaucracy हर चीज़ findable और auditable बनाती है। Bad bureaucracy rumors पर official-looking seals लगाकर beautifully file करती है। Stamp truth नहीं, file के bottom की receipt है। Receipts check करें और bureaucracy केवल तब बनाएँ जब facts का pile सच में notebook से बड़ा हो।
16. Graph क्या नहीं कर सकती और आगे कहाँ जाना है
इसे run करें: companion lab में bash concepts/16-limits.sh। पढ़ना आधा है। इसे होते देखना बाकी आधा।
Honest boundary पर खत्म करें, 3 statements में जिन्हें graph आपके लिए नहीं कह सकती:
"Checker का PASS अब trustworthy है।" नहीं। Grounding ने verdict impression से audit बनाया, लेकिन auditor अब भी model है: claim support न करने वाली edge cite, existing path miss और underlying model update पर drift कर सकता है। Irrelevant edges cite करने वाला fluent answer documented failure है, theoretical नहीं। Checker को measure करना, golden sets, calibration, pass rates और drift next course है: Trusting the Checker। उसकी हर सीख यहाँ double apply होती है, क्योंकि graph system में 2 checkable layers हैं: memory fill करने वाली extraction और उसे पढ़ने वाला reviewer। उसका evaluation harness familiar लगेगा: extraction prompt और score history पढ़ें, एक change propose करें, gold set पर run, keep या revert। Ratchet, graph पर point किया हुआ।
"Memory जहाँ है वहाँ safe है।" केवल home जितनी safe। Laptop repo की graph laptop के साथ मरती है। Swarm की shared memory ऐसी place पर होनी चाहिए जहाँ हर local, scheduled और cloud worker पहुँच सके, machine failure survive करे और कौन क्या write कर सकता है enforce करे। Autoresearch one GPU पर precisely इसलिए चलता है क्योंकि bounded safe है। AgentHub one server पर one Go binary exactly इसलिए है क्योंकि sketch है। Proven loops और graph को ऐसी runtime पर move करना जिसे babysit न करना पड़े, course after next है: Leaving the Laptop।
"Better wiring का अर्थ better judgment है।" Book की oldest boundary नहीं बदलती। Graph memory और evaluation को context window के बाहर रखती है। यह real और यहाँ का single most important insight है: bottleneck आमतौर पर next model call नहीं, memory और evaluation की placement है। लेकिन ontology, source policy, anchors और "better का meaning क्या है?" का answer हर graph के बाहर, आपसे आता है। Karpathy README "autonomous swarms of AI agents running across compute cluster megastructures in the skies" पर joke करती है। Near-term work less dramatic और more valuable है: typed contracts, preserved lineage, grounded claims और session से अधिक टिकने वाली memory। First course के Concept 1 की intent और accountability वे 2 चीज़ें हैं जिन्हें nodes और edges का कोई arrangement contain नहीं कर सकता।
Graph memory और checking agent के head से बाहर move करती है और यह real win है: इसलिए 1,000 agents हर one zero से start किए बिना one problem पर काम कर सकते हैं। लेकिन memory किसलिए है, graph decide नहीं कर सकती। किसी को choose करना है कि कौन-सी चीज़ें याद रखने योग्य, कौन-से sources evidence और "better" क्या है। वह कोई आप हैं और wiring job नहीं हटाती।
यह book thread यहाँ उठाती है: shared graph वाले loops के system को plain words में describe करें तो organization बनता है, shared filing system वाले workers, receipts demand करने वाले reviewers और rules set करने वाला owner। यही Human-Agent Teams crash course है और well-built loops graph org chart पर name earn करे तो यही बनती है: institutional memory वाला Digital FTE।
इस book पर graph का use, dogfooding
क्या book course की सीख practice करती है? Honest answer: proto-graph चलाती है और deliberately full one नहीं।
Loop course के dogfooding section के feedback loop को इस course की eyes से देखें। हर reader note database record है। Notes अपने opened GitHub issues से link होती हैं। Issues fix करने वाले pull requests से link हैं। PRs changed lessons और shipping human approval से link हैं। Typed records, directed links, end-to-end provenance: shipped fix से exact reader note तक walk कर सकते हैं जिसने उसे cause किया। Diagram के सिवाय हर तरह से graph है और इसलिए same note पर 2 बार work नहीं होता: loops history reread करने के बजाय links query करते हैं।
Book जो नहीं चलाती वह own content पर model-driven extraction और entity resolution वाली knowledge graph है। यह Concept 15 खुद पर apply हुआ है: cross-session questions अभी issue links और Git history answer करते हैं, relations simple हैं और extraction pipeline demand करने वाली query के बिना error surface add करेगी। जिस दिन links answer न करने वाला question आए, likely first यह होगा: "कौन-से lessons ऐसी documents से sourced claims करते हैं जो बाद में बदल गए?" Part 6 pattern plan on file है। Real query earn करे तब graph बनाएँ, one week पहले नहीं।
🚀 Projects
Graph के बारे में पढ़ना उसे fill करने जैसा नहीं। यहाँ easy से hard 8 builds हैं। किसी tool में करें: graph files और jq है, इसलिए केवल headless command बदलती है, claude -p या opencode run।
हर बार शुरू करने से पहले 2 rules:
- Throwaway repo और real documents use करें। Graph तभी interesting है जब entities पहचानी हुई हों, इसलिए invented data के बजाय own READMEs, notes या logs use करें।
- First claim से पहले schema लिखें। 5 minute में लिखी
graph/SCHEMA.md, files में accidental content से बाद में reconstruct की schema से better है, Part 6।
Project 110-15 minअपना system draw करेंवह finding ढूँढें जो transcript में मरती है और वह number जिसका कोई audit नहीं करता।
Difficulty: easy · Uses: Concepts 2, 3, 11, यानी nodes और edges, 2 graphs और wiring।
Build। Paper या Mermaid में आज चलने वाले हर loop, checker, human gate, anchor और memory file को labeled directed edges वाले typed nodes की तरह draw करें। Mark करें कौन-से nodes loops हैं और कौन नहीं। फिर 2 चीज़ें circle करें: transcript के अंदर only existing finding और अपने number पर watcher के बिना optimizing loop।
Done जब हर kind की एक circled item point करके उसकी cost बता सकें। लगभग कोई इसे draw करके nothing नहीं पाता, और कुछ build करने से पहले करने का point यही है।
Project 230-45 minSpine से claims10 real findings को typed records में बदलें और उन findings से मिलें जिन्हें source नहीं कर सकते।
Difficulty: easy · Uses: Concepts 1, 8 और Part 6, यानी provenance और schema।
Build। Real progress.md, या किसी loop का log, लें और last 10 durable findings को Part 6 schema के तहत claims.json records में convert करें। Invariants के demanded हर field को भरें, जिसमें produced_by और real source शामिल हैं।
Done जब 10 में हर one ऐसी चीज़ cite करे जिसे later agent खोल सके या explicitly "source": {"kind": "inference"} mark हो। Inference वाली count करें। वह उन चीज़ों का number है जिन्हें model fluency के दम पर facts treat कर रहे थे और अपने system के बारे में यह course सबसे useful number देगा।
Project 345-60 minपहली extraction3 documents पर one schema-constrained prompt run करें और own duplicates से मिलें।
Difficulty: medium · Uses: Concept 6, extraction।
Build। Concept 6 prompt को 3 related documents पर headlessly run करें: one project की 3 READMEs, 3 meeting notes या 3 incident write-ups। भरोसा करने से पहले हर reply को jq से validate करें। फिर count करें कितनी distinct entities एक से अधिक surface form में आती हैं।
Done जब सभी 3 documents schema-valid JSON return करें और कम-से-कम 1 ऐसी entity का नाम बता सकें जो 2 या अधिक names में आई। Count zero हो तो documents बहुत similar हैं: अलग people के written 3 documents use करें, क्योंकि तभी resolution hypothetical नहीं, real problem बनती है।
Project 430-45 minDAG बोलती हैकेवल Git से AgentHub के 3 questions answer करें, फिर commands अपने agents के लिए छोड़ें।
Difficulty: medium · Uses: Concepts 4 और 5, यानी 2 memories और traversal।
Build। Real history वाले repo में plain Git से AgentHub के 3 questions answer करें: commit X के ऊपर क्या try हुआ, कौन-से tips unexplored frontier हैं और current state तक कौन-सा path पहुँचा। फिर 3 commands GRAPH.md में लिखें ताकि future agents भी पूछ सकें।
Done जब 3 commands काम करें और DAG जो नहीं बता सकती वह भी कह सकें: कौन-से experiments try करके throw away हुए। वह absence Concept 4 का correction है, text में पढ़ा नहीं, own repo में felt।
Project 545-60 minResolution drillजो merge होना चाहिए उसे merge करें, बाकी अलग रखें और हर receipt रखें।
Difficulty: medium · Uses: Concept 7, resolution।
Build। Project 3 की 20 surface forms type से grouped और descriptions सहित लें। Stronger model से हर one के rationale और confidence वाले canonical clusters माँगें, हर alias रखते हुए। फिर trap plant करें: same name वाली 2 genuinely different entities add करके फिर run करें।
Done जब real duplicates merge, same-name strangers अलग रहें और हर canonical entity अपने source surface forms list करे। Strangers merge हों तो resolution prompt पहले fix न करें: descriptions richer करें, क्योंकि evidence वहीं से आना है।
Project 61-2 hrs, plus 5 beatsGrounded reviewerChecker से opinion के बजाय edge demand करवाएँ।
Difficulty: hard · Uses: Concept 10 और Part 6, यानी grounding और reviewer।
Build। Part 6 reviewer को existing loop में wire करें। Verdicts resolvable claim ids वाला grounded_in रखें, supporting claim के बिना factual statement missing filled REVISE force करे और inference source वाली claim अपने दम पर कुछ ground न कर सके। 5 real beats run करें।
Done जब कम-से-कम 1 beat named missing edge के साथ REVISE आए और maker की next attempt evidence produce या claim withdraw करे। बाद में 5 verdicts साथ पढ़ें: maker ने क्या record करना सीखा, वही project का actual output है।
Project 72-3 hrsExtraction का gold setMemory fill करने वाली pipeline को एक course पहले measure करें।
Difficulty: hard · Uses: Concepts 6, 7 और next course।
Build। 5 documents में entities और relations hand-label करें। यही tedious part है और shortcut नहीं। फिर labels के against Project 3 prompt score करें: precision, recall और schema-valid rate। Prompt की exactly 1 line बदलें, re-score करें और number पर keep या revert करें।
Done जब prompt पर ratchet कम-से-कम 3 times run किया हो और हर attempt, reverted ones सहित, record हो। आपने graph autoresearch बना ली: same loop, different artifact। Trusting the Checker में यह discipline बनती है।
Project 8Capstone: 1 weekend, फिर 1 week beats2 loops, 1 graphGraph बताए इसलिए one loop से ऐसा fix report करवाएँ जिसे उसने कभी नहीं देखा।
Difficulty: capstone · Uses: everything।
Build। One graph पर 2 loops। Triage loop real tool-output sources वाली claims लिखता है। Changelog loop file dump के बजाय 2-hop context builder से उन्हें पढ़ता है। दोनों reviewers verdicts ground करते हैं। Pre-commit hook schema और append-only rule guard करता है। Triage loop के throughput number को 1 counter-metric मिलता है जिसे review loop देखता है, Concept 12।
Done जब changelog loop सही तरह ऐसा fix report करे जिसे उसने देखा नहीं क्योंकि graph ने carry किया, और changelog line से claim, run तथा captured tool output के ज़रिए ऐसी चीज़ तक walk कर सकें जिसे model ने नहीं लिखा। Walk success हो तो anchors वाली shared memory बना चुके हैं और course के पास और सिखाने को कुछ नहीं।
Sources और further reading
इस book के अंदर
- Loop Engineering: ratchet, spine, maker–checker split, dreaming loop और two-routine gate। Part 5 की हर governance edge पहले वहाँ one loop at a time बनी थी।
- Harness Engineering: typed output और reversibility discipline, दोनों यहाँ memory-scale पर promote हुए।
- Trusting the Checker: next course, grounded reviewer और extraction pipeline अच्छे हैं या नहीं, कैसे जानें।
- Leaving the Laptop: laptop बंद हो तो graph और loops कहाँ live करती हैं।
- Human-Agent Teams: org chart पर loops की graph क्या बनती है।
Primary sources
- Andrej Karpathy, autoresearch, 7 मार्च 2026 release: https://github.com/karpathy/autoresearch। 3-file harness, ratchet और reported results। Loop को कहीं quote करने से पहले
program.mdखुद पढ़ें: वही Concept 4 के 2-memories correction का source है। वह specify करता है कि experiments dedicated branch पर चलते हैं, branch improvement पर ही आगे बढ़ती है, equal या worse कोई चीज़git resetसे हटती है औरresults.tsvहर attempt record करते हुए deliberately Git में untracked रहती है। 3-file harness, ratchet loop और commit-DAG memory। Course के star counts और experiment numbers first weeks reflect करते हैं। Live repo check करें। - Andrej Karpathy, AgentHub, लगभग 9–10 मार्च 2026 publish और अब public नहीं: bare Git repo, SQLite, message board तथा
children/leaves/lineageCLI वाली agent-first collaboration layer। Explicitly "just a sketch. Thinking..." Original repository weeks के अंदर private हुई और license file नहीं थी। अब code preserved community forks में मिलता है: उन्हें study का historical artifact मानें, dependent software नहीं। Autoresearch repository में AgentHub integration thread public और better primary reference है। Repository removal के लिए private होने से पहले fork करने वाले developer का contemporaneous write-up देखें: https://dev.to/alireza_rezvani/karpathys-agent-native-infrastructure-working-python-agent-template-2o9d, मार्च 2026। - Anthropic, Knowledge Graph Construction with Claude, Cookbook, 23 मार्च 2026: https://platform.claude.com/cookbook/capabilities-knowledge-graph-guide: Haiku पर structured outputs से extraction, Sonnet पर reasoning की तरह resolution, NetworkX assembly और citations वाली subgraph querying। Part 3 का source।
- Erik Schluntz और Barry Zhang, Building Effective Agents, Anthropic Engineering, दिसंबर 2024: Concept 10 के grounded 5 composable workflow patterns।
- Anthropic, How we built our multi-agent research system, Anthropic Engineering, 2025: https://www.anthropic.com/engineering/multi-agent-research-system: orchestrator-worker research architecture, single agent के ऊपर breadth-first advantage और Concept 14 budget note का roughly 15-times token cost। Multiple ordinary chat interactions के against report हुआ है, same task के single-agent run के against नहीं, जो readers आमतौर पर assume करते हैं। कोई number quote करने से पहले live post check करें।
- Anthropic, Introducing dynamic workflows in Claude Code, 28 मई 2026; page अब general availability update रखता है: https://claude.com/blog/introducing-dynamic-workflows-in-claude-code: Part 2 deeper note का source, generated orchestration, tens to hundreds parallel fresh-context sub-agents, checked results, resumable progress,
ultracodesetting, token warning और Bun port। Availability Claude Code CLI, Desktop और सभी paid plans की IDE extensions में है, Pro पर/configकी Dynamic workflows row से on करें, साथ में Anthropic API, Amazon Bedrock, Google Cloud Agent Platform और Microsoft Foundry। Announcement नहीं, reference docs real limits रखती हैं: 16 concurrent agents और हर run 1,000 agents। Reference docs: code.claude.com/docs/en/workflows। - Peter Steinberger का 18 जुलाई 2026 post, "Are we still talking loops or did we shift to graphs yet?", X पर (x.com/steipete/status/2078277297791189132, 00:34 UTC): season का नाम रखने वाले 12 words। Obituary Steinberger की नहीं: Hamel Husain ने लगभग साढ़े 4 hours बाद "Loop Engineering Is Dead. Enter Graph Engineering" publish किया और Santiago Valdarrama, @svpino, ने widely quoted "Loop Engineering is dead. Long live Graph Engineering!" post किया। दोनों naming treadmill पर jokes जैसे पढ़ते हैं।
- Carlos E. Perez, Intuition Machine, From Loop Engineering to Graph Engineering?, 19 जुलाई 2026: Part 5 का source, support-bot story, single loop की 4 failures और structural fixes, circular-graph warning, anchors और frozen nodes तथा grounded-versus-ungrounded conclusion। https://medium.com/intuitionmachine/from-loop-engineering-to-graph-engineering-d3ebeb08511c
- Graph Engineering: The Karpathy Loop, Improved 1000x by Itself, independent synthesis PDF, जुलाई 2026: staged build path, 2-graphs distinction, 4 invariants और closing traceability test। अपने front page के अनुसार Karpathy या Anthropic से affiliated या endorsed नहीं। Useful study note की तरह पढ़ें और primary sources पहले पढ़ें।
- Fortune, autoresearch की coverage, "Karpathy Loop", मार्च 2026।
- TechCrunch और others, Karpathy के 19 मई 2026 को Anthropic की pretraining team join करने और Claude से pretraining research accelerate करने वाली team बनाने के mandate पर: https://techcrunch.com/2026/05/19/openai-co-founder-andrej-karpathy-joins-anthropics-pre-training-team/
सभी links जुलाई 2026 के आख़िर तक current। हर repository, preview feature और number तेज़ी से बदलता है। Depend करने से पहले live source से confirm करें।
One-line summary
Agent भूलता है, graph नहीं भूलती। Memory की 2 graphs रखें: काम के लिए DAG, facts के लिए knowledge graph। दूसरी को schema से fill करें, names reversibly merge करें, हर edge पर receipt staple करें, workers को dumps के बजाय subgraphs दें और हर checker से edge cite या demand करवाएँ। फिर loops खुद wire करें: हर optimizing number पर watcher, हर target का owner slower loop, nodes के बीच gate और ऐसे anchors जिनसे कोई loop बहस नहीं कर सकता। Graph claims store करती है, truth नहीं: grounded versus ungrounded वह axis है जो हर rename से अधिक टिकती है।