AI agent क्या है: पाँच क्लासिक प्रकार, दो प्रतिस्पर्धी परिभाषाएँ

इस field का सबसे पुराना उदाहरण दो squares, A और B, वाली दुनिया में vacuum cleaner है, जहाँ हर square या तो clean है या dirty.¹ यह हर textbook में इसलिए बचा हुआ है क्योंकि यह सबसे छोटी दुनिया है जिसमें कोई agent सही या गलत हो सकता है।

percept एक pair है — मैं कहाँ हूँ, और यहाँ गंदगी है या नहीं — और actions हैं SUCK, LEFT और RIGHT। पूरा program एक line है।

type Percept = { dirty: boolean; where?: "A" | "B" };
type Action = "SUCK" | "LEFT" | "RIGHT";

const textbook = (p: Percept): Action =>
  p.dirty ? "SUCK" : p.where === "A" ? "RIGHT" : "LEFT";   

इसे दो-square दुनिया की हर starting configuration के against चलाइए:

A dirty, B dirty, start A    -> steps=3 clean=true
A clean, B dirty, start A    -> steps=2 clean=true
A dirty, B clean, start B    -> steps=2 clean=true

यह एक simple reflex agent है: यह केवल current percept पर act करता है, उससे पहले की किसी चीज़ की memory नहीं रखता। यह toy category नहीं है — thermostat ऐसा ही है, और बिना conversation attached language model की single call भी ऐसी ही है।

अब इसे वैसे तोड़िए जैसे reality तोड़ती है। असली vacuum robot के पास dirt sensor और bumper होता है, carpet के नीचे A labelled square नहीं। percept से location निकाल दीजिए और बाकी कुछ न बदलिए:

const dirtOnly = (p: Percept): Action => (p.dirty ? "SUCK" : "RIGHT");

A dirty, B dirty, start A    -> steps=3   clean=true   still dirty=0
      t=0 at=A percept={dirty:true}  -> SUCK
      t=1 at=A percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:true}  -> SUCK

A dirty, B clean, start B    -> steps=500 clean=false  still dirty=1
      t=0 at=B percept={dirty:false} -> RIGHT
      t=1 at=B percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:false} -> RIGHT
      t=3 at=B percept={dirty:false} -> RIGHT

वही program, दो squares। एक starting state से यह तीन steps में finish करता है; दूसरी से यह right-hand wall में पाँच सौ बार जा टकराता है और battery खत्म होने तक चलता रहता। यह दोनों स्थितियों के बीच फर्क perceive नहीं कर सकता, इसलिए उनमें अलग-अलग act नहीं कर सकता। Russell और Norvig सामान्य परिणाम एक line में बताते हैं: partially observable environments में simple reflex agents के लिए infinite loops अक्सर unavoidable होते हैं.¹

एक fix है जिसकी कीमत एक line और zero memory है, और किसी clever चीज़ तक पहुँचने से पहले उसे मापना चाहिए।

let seed = 12345;
const rnd = () => ((seed = (seed * 1103515245 + 12345) & 0x7fffffff) / 0x7fffffff);

const coin = (p: Percept): Action => (p.dirty ? "SUCK" : rnd() < 0.5 ? "LEFT" : "RIGHT");  

तीन sizes पर all-dirty corridor के दो हजार runs, पूरे समय एक seeded generator:

Randomisation loop को पूरी तरह हटा देता है। इसकी लागत भी है: अगर आपको पता हो कि क्या कर रहे हैं तो आठ rooms को पंद्रह moves चाहिए, और यह agent औसतन 68.7 लेता है और एक बार 306 तक गया। यही पूरा अध्याय miniature में है। हर capability जो हम जोड़ते हैं, उस case में correctness खरीदती है जिसे पिछला agent संभाल नहीं सकता था, और उसका charge ऐसी currency में करती है जिसका नाम आपको पहले रखना पड़ता है।

एक agent अपने environment को sensors के जरिए perceive करता है और actuators के जरिए act करता है। agent program percepts से actions तक का function है — ऊपर की हर listing वही है। percept sequence अब तक perceive की गई हर चीज़ है, और simple reflex agent last item को छोड़कर बाकी सब ignore करता है।

Rationality वह शब्द है जिसे ज्यादातर articles गलत समझते हैं, और इसे सही समझना इस अध्याय के बाकी हिस्से को उपयोगी बनाता है। कोई agent अपने आप में rational या irrational नहीं होता। Russell और Norvig rational agent को ऐसे agent के रूप में define करते हैं जो हर possible percept sequence के लिए वह action चुनता है जिससे उसके performance measure को maximise करने की expected संभावना हो, उस sequence के evidence और उसमें जो भी built-in knowledge हो उसके आधार पर.¹ performance measure agent के अंदर नहीं होता: यह designer का होता है, और rationality सिर्फ उसके relative define होती है।

Specification conventionally चार चीज़ों के रूप में लिखी जाती है, PEAS: performance measure, environment, actuators, sensors।

ध्यान दीजिए कौन-सी row अलग है। 2026 में agents बनाने वाली लगभग हर team E, A और S लिखती है — tool schemas, integrations, message format — क्योंकि इनके बिना code चलेगा नहीं। लगभग कोई P नहीं लिखता। इसके बिना “our agent is doing well” का कोई अर्थ नहीं जिसे कोई check कर सके, और “rational” system पर लागू ही नहीं किया जा सकता, केवल demonstration पर। अध्याय 29 P को number में बदलने के बारे में है, और इसी वजह से वह मौजूद है।

    ┌───────────────────────── the environment ─────────────────────────┐
    │                                                                   │
    │   ┌──────────────────────── the agent ─────────────────────┐      │
    │   │                                                        │      │
 ───┼──►│  sensors  ──►  the agent program  ──►  actuators  ─────┼──────┼──►
percept │                                                        │    action
    │   └────────────────────────────────────────────────────────┘      │
    └───────────────────────────────────────────────────────────────────┘
                                   ▲
              the performance measure lives out here, in the head of
              whoever built the thing, and the agent cannot change it

Task environments को आगे सात axes पर classify किया जाता है, जिनमें से पाँच यहाँ की difficulty का अधिकतर हिस्सा तय करते हैं: fully या partially observable, deterministic या नहीं, episodic या sequential, static या dynamic, known या unknown.¹ real network पर real tools से बात करने वाला agent इन पाँचों के hard corner में होता है — temperature zero पर भी non-deterministic (अध्याय 17), और जो underestimated है, unknown, क्योंकि आपके पास अपनी ही tools दुनिया के साथ क्या करती हैं इसका कोई reliable model नहीं होता। इसलिए अध्याय 23 के loop को planning से ज्यादा error handling चाहिए।

Real floors one-dimensional नहीं होते, इसलिए दुनिया को plan में promote करें। Hash marks walls हैं, asterisks dirt हैं, और robot middle chamber से शुरू करता है:

        col  0 1 2 3 4 5 6
      row 0  * . . # . . *
      row 1  . # . # . # .
      row 2  . # . S . # .        S = the robot starts here
      row 3  . # . # . # .
      row 4  * . . # . . *

सबसे obvious upgrade memory है। agent map रखता है: हर square जहाँ वह खड़ा हुआ और हर square जहाँ bumper चला। इसका rule है किसी ऐसे adjacent square में जाना जिसे उसने visit नहीं किया — right, फिर down, फिर left, फिर up — और जब आसपास सब known हो जाए तो back off करना। यह model-based reflex agent है: यह percept history से internal state maintain करता है, इसलिए जो अभी दिखाई नहीं दे रहा उस पर भी act कर सकता है।

यह real improvement है, और फिर भी enough नहीं:

5,000 steps allowed -> steps=5,000  distinct squares visited=13/25  still dirty=2/4

पाँच हजार moves, floor का आधा हिस्सा कभी देखा ही नहीं। map सही है और rules सही हैं। agent जो नहीं कर सकता, वह है map का इस्तेमाल करके कहीं जाना: उसके rules हमेशा केवल “मेरे चार neighbours में से किसमें कदम रखूँ” का जवाब देते हैं, इसलिए जब उसके पास adjacent unvisited squares खत्म हो जाते हैं, तो उसके पास यह thought express करने का कोई तरीका नहीं रहता कि आठ moves दूर एक unvisited square है और मैं वहाँ खड़ा होना चाहूँगा। उसे पता है कि वह कहाँ है। उसे यह नहीं पता कि वह कहाँ होना चाहता है।

goal-based agent world के अपने model के ऊपर उस situation का description रखता है जिसे वह लाना चाहता है, और actions चुनने के लिए उनके sequences पर search करता है जब तक कोई sequence वहाँ end न हो जाए। Goals action selection को lookup से search में बदल देते हैं।

Goal है “no dirty square remains”। Search nearest dirty square तक breadth-first walk है, और जो path लौटता है वही plan है।

goal-based (fewest moves)      -> moves=27  battery=52  still dirty=0
      from 2,3 -> 4,6 via 5 moves:  2,3 2,4 3,4 4,4 4,5 4,6
      from 4,6 -> 0,6 via 4 moves:  4,6 3,6 2,6 1,6 0,6
      from 0,6 -> 4,0 via 10 moves: 0,6 0,5 0,4 1,4 2,4 2,3 2,2 3,2 4,2 4,1 4,0
      from 4,0 -> 0,0 via 4 moves:  4,0 3,0 2,0 1,0 0,0

सत्ताईस moves, floor clean। लेकिन battery column और plan की last leg देखें। Column 0 carpeted है: carpeted square cross करने की कीमत battery की छह units है, tiled square की एक। agent column 0 से home गया क्योंकि वह आठ के बजाय चार moves हैं, और उन चार carpeted moves की कीमत 24 थी, जबकि आठ-move detour की 13 होती।

यह otherwise कर ही नहीं सकता। Goal एक binary test है: floor clean है या नहीं। clean floor पर end होने वाला हर plan उसे समान रूप से satisfy करता है, इसलिए जब कई plans सफल हों तो agent के पास उनके बीच choose करने के लिए कुछ नहीं होता। एक success को दूसरे पर prefer करने के लिए outcomes पर एक number चाहिए, और वह number utility function है। जो agent उसे maximise करता है वह utility-based agent है।

Code में change search के अंदर एक term है। Breadth-first search moves गिनती है; उससे cost गिनवाइए और आपके पास Dijkstra का algorithm और एक अलग agent है:

const nd = dist.get(k)! + (byCost ? cell.cost : 1);   // <- the entire difference

goal-based    (fewest moves)   -> moves=27  battery=52  still dirty=0
utility-based (cheapest route) -> moves=31  battery=41  still dirty=0
      from 4,0 -> 0,0 via 8 moves: 4,0 4,1 4,2 3,2 2,2 1,2 0,2 0,1 0,0

चार extra moves, battery की ग्यारह units कम: इक्कीस प्रतिशत cheaper। Same goal, same map, same code लेकिन एक term अलग। दोनों agents केवल इस बात में अलग हैं कि वे किस चीज़ में अच्छा होना चाहते हैं, और वे home लौटने के लिए अलग routes लेते हैं।

यह पहला point भी है जहाँ agent को ऐसी चीज़ चाहिए जो वह खुद produce नहीं कर सकता। किसी को तय करना पड़ता है कि एक move के relative battery की unit कितनी worth रखती है। Utility performance measure है जिसे ऐसे रूप में लिखा गया है जिससे agent compute कर सके, और उसे लिखना designer का काम है। जब लोग कहते हैं कि agent ने “wrong thing optimise” किया, तो उनका मतलब लगभग कभी bug नहीं होता। उनका मतलब होता है कि यह line careless लिखी गई थी।

अब dirt को वापस आने दें। चार rooms चार अलग-अलग rates पर फिर से dirty होते हैं, और agent को वे कभी नहीं बताए जाते। वह प्रति tick एक room visit करता है और केवल वही room देखता है। performance measure है 4,000 ticks में dirty बिताए गए room-ticks — कम बेहतर है।

Textbook decomposition में learning agent ऊपर के किसी भी agent में तीन parts जोड़ता है: एक learning element जो agent को बदलता है, एक critic जो बताता है कि fixed performance standard के against agent कैसा कर रहा है, और एक problem generator जो ऐसे actions propose करता है जिन्हें try करना सीखने के लिहाज से worth हो.¹ उसी environment में तीन policies। पहली नहीं सीखती; दूसरी और तीसरी वही चीज़ सीखती हैं और उसे अलग तरह से use करती हैं।

Hidden rates kitchen के लिए 0.35, hall के लिए 0.05, study के लिए 0.02 और attic के लिए 0.01 थीं — और learner A ने उन्हें find कर लिया। उसने kitchen को house का dirtiest room सही identify किया, फिर simulation के बाकी हर tick kitchen जाता रहा जबकि बाकी तीन हमेशा dirty बैठे रहे। यह बिल्कुल न सीखने से पाँच गुना worse है, और यह broken नहीं है।

Lesson utility section वाला ही है। Learner A ने “probability that the room I am about to visit is dirty” को maximise किया। performance measure था “room-ticks spent dirty”। अलग numbers; दूसरा वही है जिसे critic score कर रहा था, और किसी ने agent को बताया नहीं। Learner B वही learned rate last visit के बाद के time से multiply करता है — किसी dirt को find करने की chance के बजाय वह dirt जिसे वह find करने की expect करता है — और उस patrol को beat कर देता है जिससे उसने शुरुआत की थी।

एक implementation detail ने result तय किया। learner B के first version में, जिस room में तीन visits में कोई dirt नहीं मिली उसकी rate exactly zero हो गई — और zero times anything zero होता है, इसलिए वह फिर कभी visit नहीं हुआ और estimate कभी correct नहीं हो सका। fraction को smooth करना, successes plus one over trials plus two, 11,895 को 1,576 में बदल गया। “Not observed yet” और “measured and came out zero” अलग claims हैं, और जो system उन्हें same field में store करता है वह ऐसे decisions लेता है जिन्हें undo नहीं कर सकता।

  1  simple reflex    percept ────────────────────────────────► rules ────► action
  2  model-based      percept ──► [state] ──────────────────► rules ────► action
  3  goal-based       percept ──► [state] ──► [goal] ──────► search ───► action
  4  utility-based    percept ──► [state] ──► [goal] ──► [U] ──► argmax ► action
  5  learning         all of the above, plus [critic] ──► changes the parts above

इन पाँचों में से हर एक आज production में किसी और नाम से मौजूद है।

दो rows analogy से भी ज्यादा close हैं, और इसका पैसा लगता है।

chat एक model-based reflex agent है जिसका model internal नहीं है। Textbook में state agent program के अंदर variable होती है। chat में यह transcript है: यह आपकी side पर रहता है, हर call पर पूरा re-sent होता है, और model के अंदर हर बार scratch से rebuild होता है। यही अध्याय 16 का quadratic bill है, और वही object है जिसे textbook ने “state” labelled box के रूप में draw किया था। यहाँ फर्क है, एक follow-up question पर, उससे पहले के दो messages के साथ और बिना मापा गया:

with the transcript      prompt=67  "The current temperature in Lisbon, Portugal is 15°C."
without the transcript   prompt=29  "Lisbon is the capital of Portugal, not a city in Portugal."

Same model, user input के वही तीन words, और दूसरा वाला corridor robot है जो wall में drive कर रहा है। उस run में tools नहीं थे, इसलिए 15 invented है — लेकिन state ही follow-up को कोई meaning देती है। आप इसे हर बार rebuild करते हैं और दो-turn conversation पर इसके लिए 2.3× input tokens pay करते हैं। अध्याय 16 ने मापा था कि turn forty तक यह multiplier कहाँ पहुँचता है।

Reflexion एक learning agent है जो अपना program नहीं, input बदलता है। Textbook decomposition में learning element performance element को modify करता है। Reflexion weights को छोड़ देता है और episodic buffer में reflective text लिखता है जिसे next attempt पढ़ता है.³ learning element prompt है, memory database row है, performance element frozen model है — और diagram textbook का ही है, unchanged।

और mapping की honest limit यह है। पाँच types agent program को classify करते हैं। 2026 में वह program बीच से split है: कुछ आपके code में है, कुछ उन weights के अंदर जिन्हें आपने train नहीं किया। जब कोई model अपने आप tool call करने का decision लेता है, goal test आपके program में है या model में? Taxonomy के पास जवाब नहीं है, क्योंकि जब वह लिखी गई थी तो उसके होने की कोई और जगह थी ही नहीं — और यही सवाल वह जगह है जहाँ दो modern definitions अलग हो जाती हैं।

Definitions behaviour के बारे में arguments हैं, और सामने trace हो तो उन्हें judge करना कहीं आसान है।

नीचे वाला loop conversation को model को भेजता है; अगर reply में tool call हो तो वह tool execute करता है, result append करता है और पूरी चीज़ फिर भेजता है। यह इस machine पर OpenAI-shaped endpoint के पीछे local Qwen2.5-0.5B-Instruct के against चलता है — अध्याय 14 वाला seam, इसलिए loop को यह पता भी नहीं और परवाह भी नहीं कि port के पीछे क्या है।

const BASE = process.env.LLM_BASE_URL ?? "http://127.0.0.1:8799/v1";

async function loop(question: string, maxTurns = 6) {
  const messages: Msg[] = [
    { role: "system", content: SYSTEM },
    { role: "user", content: question },
  ];

  for (let turn = 1; turn <= maxTurns; turn++) {
    const reply = await call(messages, TOOLS);
    const calls = reply.choices[0].message.tool_calls ?? [];
    messages.push(reply.choices[0].message);

    if (!calls.length) return messages;                      

    for (const c of calls) {
      const out = runTool(c.function.name, JSON.parse(c.function.arguments));
      messages.push({ role: "tool", name: c.function.name, content: out });
    }
  }
  throw new Error("turn cap reached");                       
}

दो lines पूरा idea carry करती हैं, और दोनों marked हैं; बाकी bookkeeping है। एक run में तीनों behaviours दिखते हैं। कुछ ऐसा पूछा जाए जो यह खुद कर सकता है, तो model answers। कुछ ऐसा पूछा जाए जो यह नहीं कर सकता, तो यह calls:

=== a question the model cannot answer, one tool available
  turn 1  prompt= 187  out= 21  finish=tool_calls  CALL get_temperature({"city": "Oslo"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
  turn 2  prompt= 238  out= 12  finish=stop        TEXT "The current temperature in Oslo is 4
                                                        degrees Celsius."
  => model calls=2  prompt tokens=425  output=33  wall=6,257 ms
  => stopped by: the model produced text instead of a call

और यह stops — तीसरा behaviour, और miss करना सबसे आसान, क्योंकि यह ऐसा दिखता है जैसे कुछ नहीं हो रहा। loop इसलिए end होता है क्योंकि turn 2 बिना tool call के वापस आया। यह किसी ने decide नहीं किया; model ने prose emit करके किया। इस program की termination condition absence का sign है।

दो और runs जगह के लायक हैं। दो cities compare करने को कहने पर model एक turn में दोनों tool calls issue करता है, दोनों readings वापस पाता है, और comparison गलत कर देता है:

  turn 1  prompt= 188  out= 43  finish=tool_calls  CALL get_temperature({"city": "Oslo"}),
                                                        get_temperature({"city": "Lisbon"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
          tool  get_temperature -> {"city":"Lisbon","celsius":19}
  turn 2  prompt= 284  out= 13  finish=stop        TEXT "Oslo is currently warmer than Lisbon
                                                        at 4°C."

Tools ने काम किया। parallel call ने काम किया। loop ने काम किया। answer false है, जबकि दोनों correct numbers transcript में बैठे हैं। model को loop में wrap करना उसे reason करने वाला नहीं बनाता; यह गलत model को अपनी गलती पर act करने की ability देता है — जो आगे से अध्याय 30 है, और अध्याय 29 का आधा हिस्सा।

अब marked return delete करें और loop को cap तक run करने दें। Same question, same model:

  turn 1  prompt= 187  out= 21  CALL get_temperature({"city": "Oslo"})
  turn 2  prompt= 238  out= 12  TEXT "The current temperature in Oslo is 4 degrees Celsius."
  turn 3  prompt= 261  out= 30  TEXT "Could you please specify the exact location you're..."
  turn 4  prompt= 302  out= 14  TEXT "Sure! Could you tell me which city you're interested in?"
  turn 5  prompt= 327  out= 35  TEXT "I'm sorry, but I need more details to provide an..."
  turn 6  prompt= 373  out= 12  TEXT "Which city would you like to know the temperature for?"
  => model calls=6  prompt tokens=1,688  output=124  wall=25,261 ms  stopped by: turn cap

चार गुना input tokens, चार गुना wall clock, और ऐसा ending जिसमें agent भूल चुका है कि उससे क्या पूछा गया था और user से उस सवाल के बारे में पूछताछ कर रहा है जिसका जवाब वे turn one पर दे चुके थे। सही जवाब turn 2 पर screen पर था, और उसके बाद हर turn ने transcript को worse बनाया।

तो agent loop नहीं है। यह loop plus उसे छोड़ने का rule है, और इस वाले के पास ऐसा exactly एक rule है। अध्याय 23 पाँच खोजता है, और दिखाता है कि हर एक missing होने पर क्या टूटता है।

दोनों को paraphrase करने के बजाय quote किया गया है, क्योंकि confusion paraphrases में manufacture होती है।

Definition one boundary वहाँ रखती है जहाँ flow को कौन control करता है। Anthropic का Building effective agents ambiguity को name करता है और उस पर rule देता है:

“At Anthropic, we categorize all these variations as agentic systems, but draw an important architectural distinction between workflows and agents: Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.”⁴

Test आपके source code के बारे में सवाल है: next step किसने चुना? आपके program में switch: workflow। model: agent। वही document कहता है कि agents “are typically just LLMs using tools based on environmental feedback in a loop” — जो ऊपर की listing exactly है।

Definition two boundary user से independence पर रखती है। OpenAI का A practical guide to building agents अपनी definitional page ऐसे खोलता है:

“While conventional software enables users to streamline and automate workflows, agents are able to perform the same workflows on the users’ behalf with a high degree of independence. Agents are systems that independently accomplish tasks on your behalf.”⁵

दो sentences बाद, उसी page पर, यह exclude करता है:

“Applications that integrate LLMs but don’t use them to control workflow execution—think simple chatbots, single-turn LLMs, or sentiment classifiers—are not agents.”⁵

इन quotations को order में पढ़िए। Opening sentences line independence पर खींचते हैं: क्या यह चीज़ मेरे बिना जाकर job finish करती है? चौथा sentence इसे control of execution पर खींचता है, जो exactly Anthropic की line है। अलग tests, same page, और real systems हैं जिन पर वे disagree करते हैं।

नीचे vocabulary collision है, और यह real meetings में arguments कराता है। पहले document में workflow architecture है, और वही चीज़ है जो agent नहीं है। दूसरे में workflow “a sequence of steps that must be executed to meet the user’s goal” है — यानी job itself, जो हर agent के पास होती है। “We replaced the workflow with an agent” पहली definition के तहत coherent है और दूसरी के तहत लगभग meaningless।

2026 में मौजूद तीन systems, दोनों definitions के तहत।

तीनों में से दो sides बदलते हैं। यह किसी document की failure नहीं है। यह उस तरह की meeting के बारे में warning है जिसमें दो लोग इस बात पर पूरी तरह सहमत होते हैं कि system क्या करता है, और एक घंटा इस पर असहमत रहते हैं कि उसे क्या कहा जाए।

Definitions collide करती हैं क्योंकि हर एक दो independent questions को एक word में collapse करती है। उन्हें अलग कर दें और disagreement एक table बन जाता है, जो verdict से ज्यादा useful है।

हर definition एक अलग cell dispute करती है, और बाकी दो dispute में हैं ही नहीं। इसलिए जब label matter करता है — contract में, risk review में, postmortem में — लिखने लायक दो sentences “is it an agent” नहीं बल्कि next step किसने चुना और कौन watch कर रहा था हैं। दोनों का जवाब code पढ़कर दिया जा सकता है, किसी की definition की जरूरत नहीं, और साथ मिलकर वे हर consequence carry करते हैं जिसके लिए label खड़ा था।

यह कुछ नया नहीं है। Wooldridge और Jennings ने 1995 में “agent” के competing senses survey किए;⁶ Franklin और Graesser ने 1996 में इस अध्याय का सवाल पूछा, circulation में definitions इकट्ठी कीं और पाया कि वे disagree करती थीं.⁷ 2023 का survey अभी भी agents को first principles से define करता है — “artificial entities that sense their environment, make decisions, and take actions”⁸ — क्योंकि cite करने के लिए settled कुछ था ही नहीं, और CoALA boundary खींचने के बजाय parts describe करता है.⁹ तीस साल तक agree करने से इनकार करना बताता है कि यह word एक से ज्यादा jobs कर रहा है।

अब वह consequence जो philosophy से पहले आता है, यानी bill।

यहाँ हर measurement का shape एक जैसा है। single call की कीमत 39 input tokens थी; वही question one tool के साथ two calls में 420 cost हुआ; stopping rule हटे loop ने six calls में 1,688 cost किया। Growth linear से worse है, क्योंकि turn n अपने साथ हर previous turn carry करता है: उस six-turn run का prompt column 187, 238, 261, 302, 327, 373 पढ़ता है। अध्याय 16 ने derive किया था कि total $\Theta(n^2)$ है और real conversation पर curve fit किया था। agent हर task को उस conversation में बदल देता है, चाहे कोई human उसे कभी देखे या नहीं।

अगर ये measured token counts किसी commercial endpoint पर उन rates पर गए होते जिन्हें अध्याय 16 ने 6 September 2026 को पढ़ा था — $2.00 प्रति million input tokens और $12.00 प्रति million output — तो चार runs की कीमत ऐसी होती:

Row two बनाम row one वह number है जिसे याद रखना चाहिए। साढ़े सात गुना cost, ऐसे question के worse answer के लिए जिसे model पहले से जानता था। कुछ misconfigured नहीं था: एक tool मौजूद था, इसलिए model ने उसका इस्तेमाल किया — और अध्याय 18 की finding, कि catalogue की कीमत hurt करती है, उसकी accuracy नहीं, यहाँ one-item catalogue के साथ अपनी सबसे सस्ती demonstration पाती है।

इसीलिए दोनों documents का useful आधा हिस्सा वह है जो इसे न बनाने के बारे में है। Anthropic blunt है: सबसे simple possible solution खोजो और complexity केवल जब needed हो तब add करो, जिसका मतलब “might mean not building agentic systems at all” हो सकता है, क्योंकि agentic systems “trade latency and cost for better task performance” करते हैं और “for many applications, optimizing single LLM calls with retrieval and in-context examples is usually enough”.⁴ Agent के पक्ष में उसका case narrow है: open-ended problems जहाँ आप steps की संख्या predict नहीं कर सकते और path hardcode नहीं कर सकते, ऐसे environment में जिस पर आप trust करते हैं, “higher costs, and the potential for compounding errors” accept करते हुए.⁴ OpenAI की screen mirror image है — complex judgement, unmaintainable rule sets, unstructured data — और उसी तरह end होती है: “otherwise, a deterministic solution may suffice”.⁵

तो, इस अध्याय की taxonomy में: fixed order में fixed number of steps pipeline है, और उसे agent कहने से वह faster नहीं होगी। अगर steps की संख्या इस पर depend करती है कि रास्ते में क्या मिलता है, तो आपको loop चाहिए — और आप वह flexibility N calls, quadratic transcript, और ऐसे system से खरीदते हैं जो once के बजाय N times गलत हो सकता है।

अब आपके पास taxonomy है, दोनों modern definitions हैं, वे दो axes हैं जो उन्हें compatible बनाते हैं, और एक short loop है जो answers, calls और stops करता है।

उस loop के पास end होने का एक तरीका है: model tools माँगना बंद कर देता है। अध्याय 23 इसे जान-बूझकर सात बार तोड़ता है, और हर break एक piece जोड़ता है। Impossible task, और यह कभी end नहीं होता — turn cap। पूरी रात running, और bill आ जाता है — dollars में budget। Tool fail होता है — error जिस पर model act कर सके। Same call twice — idempotency key। ऐसी file जिसे touch नहीं करना चाहिए था — human approval। halfway restart — session persistence। ऐसा tool जिसे silence में तीन minutes लगते हैं — progress और cancellation। जो निकलता है वह harness है, वह file जिस पर इस course का बाकी हिस्सा चलता है।

इससे वह सवाल बचता है जिसके बारे में इस अध्याय का disputed diagonal सच में था। अपना next step खुद decide करने वाले loop को decide करना पड़ता है कि कब stop करना है, और हमने अभी देखा कि जब वह नहीं कर पाता तो क्या होता है: six turns, चार गुना bill, और एक agent जो user से ऐसे question पर पूछताछ कर रहा है जिसका जवाब वह पहले ही दे चुका था। Stopping एक condition नहीं है। कितनी हैं, और कौन-सी पहले fire होती है?

Lilian Weng का LLM Powered Autonomous Agents (2023) language agent को planning, memory और tool use में decompose करने का best-known तरीका है, और दो vendor documents के साथ सही next read है; इसके three components इस course के अध्याय 23, 24 और 18 हैं, इसी order में।

इस अध्याय का हर number इसी machine पर produce हुआ और कुछ भी estimate नहीं किया गया। Corridor, floor plan, उस पर चलने वाले four agents और three patrol policies ऊपर का TypeScript हैं, Node 22 पर run; randomised agent के figures प्रत्येक 2,000 seeded runs के means हैं और patrol figures 4,000 ticks के single seeded runs हैं। Model traces float32 में CPU पर greedy decoding के साथ Qwen2.5-0.5B-Instruct से आते हैं, loopback पर एक small local Python endpoint द्वारा serve किए गए, जो weights load करता है और OpenAI chat-completions shape बोलता है — वही seam फिर, tensors Python side पर और loop TypeScript side पर — इसलिए token counts उस model का tokenizer हैं और latencies उस machine की हैं। कहीं और से लिए गए केवल figures cost table की दो prices हैं, जो अध्याय 16 ने 6 September 2026 को OpenAI की pricing page से पढ़ी थीं, यहाँ locally measured token counts पर illustration के रूप में apply की गईं, observed invoice के रूप में नहीं।