AI Agent کیا ہے: پانچ کلاسیکی اقسام، دو حریف تعریفیں

اس field کی سب سے پرانی مثال دو خانوں، A اور B، کی دنیا میں ایک vacuum cleaner ہے، جہاں ہر خانہ clean یا dirty ہو سکتا ہے۔¹ یہ ہر textbook میں اس لیے بچی ہوئی ہے کہ یہ سب سے چھوٹی دنیا ہے جس میں agent صحیح یا غلط ہو سکتا ہے۔

percept ایک جوڑا ہے — میں کہاں ہوں، اور کیا یہاں dirt ہے — اور 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";   

اسے دو خانوں والی دنیا کی ہر starting configuration کے خلاف چلائیں:

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 ہے: یہ صرف موجودہ percept پر عمل کرتا ہے، اس سے پہلے کسی چیز کی memory کے بغیر۔ یہ کوئی کھلونا category نہیں — thermostat بھی یہی ہے، اور language model کی ایک single call بھی، جب اس کے ساتھ کوئی conversation attached نہ ہو۔

اب اسے ویسے توڑیں جیسے reality توڑتی ہے۔ ایک real vacuum robot کے پاس dirt sensor اور bumper ہوتا ہے، carpet کے نیچے A نام کا خانہ نہیں۔ location کو percept سے نکال دیں اور باقی کچھ نہ بدلیں:

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، دو خانے۔ ایک starting state سے یہ تین steps میں finish کر لیتا ہے؛ دوسری سے یہ دائیں wall میں پانچ سو بار جا لگتا ہے اور battery ختم ہونے تک چلتا رہتا۔ یہ دونوں situations کے فرق کو perceive نہیں کر سکتا، اس لیے ان میں مختلف act نہیں کر سکتا۔ Russell اور Norvig عام نتیجہ ایک line میں بیان کرتے ہیں: partially observable environments میں simple reflex agents کے لیے infinite loops اکثر ناگزیر ہوتے ہیں۔¹

ایک fix ہے جس کی لاگت ایک line ہے اور 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 handle نہیں کر سکتا تھا، اور اس کی قیمت ایک ایسی currency میں لگتی ہے جس کا نام پہلے آپ کو رکھنا پڑتا ہے۔

ایک agent اپنے environment کو sensors کے ذریعے perceive کرتا ہے اور actuators کے ذریعے act کرتا ہے۔ agent program percepts سے actions تک function ہے — اوپر کی ہر listing ایک یہی ہے۔ percept sequence اب تک perceive کی گئی ہر چیز ہے، اور simple reflex agent اس سب کو ignore کر کے صرف آخری item دیکھتا ہے۔

Rationality وہ لفظ ہے جسے زیادہ تر articles غلط لیتے ہیں، اور اسے درست لینا اس باب کے باقی حصے کو قابلِ استعمال بنا دیتا ہے۔ agent اپنے آپ میں rational یا irrational نہیں ہوتا۔ Russell اور Norvig rational agent کی تعریف ایسے کرتے ہیں کہ وہ ہر ممکن percept sequence کے لیے وہ action منتخب کرے جس سے اس کے performance measure کے maximise ہونے کی توقع ہو، اس sequence کے evidence اور اس کے اندر built-in knowledge کو دیکھتے ہوئے۔¹ performance measure agent کے اندر نہیں ہوتا: یہ designer کا ہوتا ہے، اور rationality صرف اسی کے نسبت define ہوتی ہے۔

Specification عموماً چار چیزوں، 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" کا کوئی قابلِ جانچ مطلب نہیں، اور "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)، اور جسے کم سمجھا جاتا ہے، unknown، کیونکہ آپ کے پاس reliable model نہیں کہ آپ کے اپنے tools دنیا کے ساتھ کیا کرتے ہیں۔ اسی لیے باب 23 کے loop کو planning سے زیادہ error handling چاہیے۔

Real floors one-dimensional نہیں ہوتے، اس لیے world کو plan میں promote کریں۔ hash marks walls ہیں، asterisks dirt ہیں، اور robot middle chamber سے start کرتا ہے:

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

واضح upgrade memory ہے۔ agent ایک map رکھتا ہے: ہر وہ square جہاں یہ کھڑا ہوا اور ہر وہ square جہاں bumper fired ہوا۔ اس کا rule ہے کہ کسی adjacent square میں چلے جسے اس نے visit نہیں کیا — right، پھر down، پھر left، پھر up — اور جب اردگرد سب known ہو جائے تو back off کرے۔ یہ model-based reflex agent ہے: یہ percept history سے internal state maintain کرتا ہے، اس لیے اس چیز پر act کر سکتا ہے جو اس وقت اسے نظر نہیں آ رہی۔

یہ واقعی improvement ہے، مگر پھر بھی کافی نہیں:

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

پانچ ہزار moves، floor کا آدھا حصہ کبھی دیکھا ہی نہیں گیا۔ map درست ہے اور rules درست ہیں۔ agent جو نہیں کر سکتا وہ map کو استعمال کر کے کہیں جانا ہے: اس کے rules صرف یہ جواب دیتے ہیں کہ "میرے چار neighbours میں سے کس میں قدم رکھوں"، اس لیے جب اس کے ساتھ والے unvisited squares ختم ہو جاتے ہیں تو اس کے پاس یہ خیال express کرنے کا کوئی طریقہ نہیں رہتا کہ آٹھ moves دور ایک unvisited square ہے اور میں وہاں کھڑا ہونا چاہتا ہوں۔ اسے معلوم ہے وہ کہاں ہے۔ اسے معلوم نہیں کہ وہ کہاں ہونا چاہتا ہے۔

ایک goal-based agent اپنے world کے model کے اوپر اس situation کی description رکھتا ہے جسے وہ لانا چاہتا ہے، اور actions کا انتخاب ان کی sequences پر search کر کے کرتا ہے جب تک اسے ایسی sequence نہ مل جائے جو وہاں ختم ہوتی ہو۔ Goals action selection کو lookup سے search میں بدل دیتے ہیں۔

goal ہے "کوئی dirty square باقی نہ رہے"۔ search nearest dirty square تک breadth-first walk ہے، اور جو path یہ return کرتا ہے وہ 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 cost کرتے ہیں جبکہ آٹھ-move detour 13 cost کرتا۔

یہ کچھ اور کر ہی نہیں سکتا۔ goal ایک binary test ہے: floor clean ہے یا نہیں۔ clean floor پر ختم ہونے والا ہر plan اسے برابر satisfy کرتا ہے، اس لیے جب کئی succeed کریں تو agent کے پاس ان میں choose کرنے کو کچھ نہیں۔ ایک success کو دوسرے پر ترجیح دینے کے لیے outcomes پر ایک number چاہیے، اور وہ number utility function ہے۔ جو agent اسے maximise کرتا ہے وہ utility-based agent ہے۔

code میں change search کے اندر ایک term ہے۔ Breadth-first search moves گنتی ہے؛ اسے cost گننے دیں تو آپ کے پاس Dijkstra's 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 کم: اکیس فی صد سستا۔ وہی goal، وہی map، وہی code سوائے ایک term کے۔ دونوں agents میں فرق صرف یہ ہے کہ وہ کس چیز میں اچھے ہونے کی کوشش کر رہے ہیں، اور وہ گھر کے لیے مختلف routes لیتے ہیں۔

یہ وہ پہلا point بھی ہے جہاں agent کو ایسی چیز چاہیے جو وہ خود پیدا نہیں کر سکتا۔ کسی کو decide کرنا ہے کہ battery کی ایک unit ایک move کے مقابلے میں کتنی worth رکھتی ہے۔ Utility وہ performance measure ہے جو ایسی form میں لکھا گیا ہے جس کے ساتھ agent compute کر سکے، اور اسے لکھنا designer کا کام ہے۔ جب لوگ کہتے ہیں کہ agent نے "wrong thing optimise" کیا تو عموماً ان کا مطلب bug نہیں ہوتا۔ ان کا مطلب ہوتا ہے کہ یہ line لاپرواہی سے لکھی گئی تھی۔

اب 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 کو change کرتا ہے، ایک critic جو اسے بتاتا ہے کہ agent fixed performance standard کے مقابلے میں کیسا کر رہا ہے، اور ایک problem generator جو ایسی actions propose کرتا ہے جو کچھ سکھانے کے لحاظ سے آزمانے کے قابل ہوں۔¹ اسی environment میں تین policies۔ پہلی learn نہیں کرتی؛ دوسری اور تیسری وہی چیز learn کرتی ہیں اور اسے مختلف طرح use کرتی ہیں۔

hidden rates kitchen کے لیے 0.35، hall کے لیے 0.05، study کے لیے 0.02 اور attic کے لیے 0.01 تھیں — اور learner A نے انہیں ڈھونڈ لیا۔ اس نے kitchen کو گھر کا سب سے dirty room درست identify کیا، پھر simulation کے باقی ہر tick پر kitchen جاتا رہا جبکہ باقی تین ہمیشہ dirty پڑے رہے۔ یہ بالکل نہ learn کرنے سے پانچ گنا worse ہے، اور یہ broken نہیں۔

سبق 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 کرنے کی توقع رکھتا ہے، نہ کہ کسی بھی dirt کے ملنے کا chance — اور اس patrol کو beat کرتا ہے جس سے اس نے start کیا تھا۔

ایک implementation detail نے result decide کیا۔ learner B کے first version میں، وہ room جہاں تین visits میں کوئی dirt نہیں نکلی اس کی rate exactly zero ہو گئی — اور zero times anything is zero، اس لیے اسے دوبارہ کبھی visit نہیں کیا گیا اور estimate کبھی correct نہیں ہو سکا۔ fraction کو smooth کرنے سے، successes plus one over trials plus two، 11,895 بدل کر 1,576 ہو گیا۔ "ابھی observe نہیں ہوا" اور "measure کیا اور zero نکلا" مختلف claims ہیں، اور جو system انہیں اسی 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 سے بھی زیادہ قریب ہیں، ایسے طریقے سے جو پیسہ خرچ کرتا ہے۔

chat ایک model-based reflex agent ہے جس کا model internal نہیں۔ textbook میں state agent program کے اندر ایک variable ہے۔ chat میں یہ transcript ہے: یہ آپ کی side پر رہتا ہے، ہر call پر پورا re-send ہوتا ہے، اور ہر بار model کے اندر scratch سے rebuild ہوتا ہے۔ یہ باب 16 کا quadratic bill ہے، اور یہی وہ object ہے جسے textbook نے "state" label والے box کے طور پر draw کیا تھا۔ یہاں فرق ہے، ایک follow-up question پر پچھلے دو messages کے ساتھ اور بغیر measure کیا گیا:

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

وہی model، user input کے وہی تین words، اور دوسرا corridor robot ہے جو wall میں جا رہا ہے۔ اس run میں کوئی tools نہیں تھے، اس لیے 15 invented ہے — مگر state ہی follow-up کو کوئی معنی دیتی ہے۔ آپ اسے ہر بار rebuild کرتے ہیں اور دو-turn conversation پر اس کے لیے input tokens کا 2.3× pay کرتے ہیں۔ باب 16 نے measure کیا تھا کہ turn forty تک یہ multiplier کہاں پہنچتا ہے۔

Reflexion ایک learning agent ہے جو اپنا program نہیں بلکہ input بدلتا ہے۔ textbook decomposition میں learning element performance element کو modify کرتا ہے۔ Reflexion weights کو چھوڑ دیتا ہے اور reflective text کو episodic buffer میں لکھتا ہے جسے next attempt پڑھتی ہے۔³ learning element ایک prompt ہے، memory ایک database row، performance element ایک frozen model — اور diagram textbook ہی کا ہے، unchanged۔

اور mapping کی honest limit یہ ہے۔ پانچ اقسام agent program کو classify کرتی ہیں۔ 2026 میں وہ program بیچ سے split ہے: کچھ آپ کا code ہے، کچھ ایسے weights کے اندر ہے جو آپ نے train نہیں کیے۔ جب model اپنے طور پر tool call کرنے کا فیصلہ کرتا ہے، تو goal test آپ کے program میں ہے یا model میں؟ taxonomy کے پاس اس کا جواب نہیں، کیونکہ جب یہ لکھی گئی تھی تو goal test کے ہونے کی کوئی اور جگہ تھی ہی نہیں — اور یہی سوال ہے جہاں دو modern definitions کی راہیں جدا ہوتی ہیں۔

definitions behavior کے بارے میں arguments ہیں، اور سامنے trace ہو تو انہیں judge کرنا بہت آسان ہے۔

نیچے والا loop conversation کو model پر بھیجتا ہے؛ اگر reply میں tool call ہو تو یہ tool execute کرتا ہے، result append کرتا ہے اور پوری چیز دوبارہ بھیج دیتا ہے۔ یہ اس machine پر OpenAI-shaped endpoint کے پیچھے local Qwen2.5-0.5B-Instruct کے خلاف چلتا ہے — باب 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 اٹھائے ہوئے ہیں، اور دونوں marked ہیں؛ باقی bookkeeping ہے۔ ایک run میں تینوں behaviors visible ہیں۔ ایسی چیز پوچھی جائے جو یہ خود کر سکتا ہے تو 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 — تیسرا behavior، اور سب سے آسانی سے miss ہونے والا، کیونکہ یہ کچھ نہ ہونے جیسا لگتا ہے۔ loop ختم ہوتا ہے کیونکہ turn 2 tool call کے بغیر واپس آیا۔ کسی نے یہ decide نہیں کیا؛ model نے prose emit کر کے کیا۔ اس program کی termination condition absence کی sign ہے۔

دو مزید runs جگہ کے قابل ہیں۔ دو شہروں کا compare کرنے کو کہا جائے تو model ایک turn میں both tool calls جاری کرتا ہے، دونوں 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 نے کام کیا۔ جواب false ہے، جبکہ دونوں correct numbers transcript میں پڑے ہیں۔ model کو loop میں لپیٹنے سے یہ reason نہیں کرنے لگتا؛ یہ wrong model کو اپنی غلطی پر act کرنے کی صلاحیت دیتا ہے — جو باب 30 پہلے سے ہے، اور باب 29 کا نصف۔

اب marked return delete کریں اور loop کو اپنی cap تک چلنے دیں۔ وہی question، وہی 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، اور ایسا end جس میں agent بھول چکا ہے کہ اس سے کیا پوچھا گیا تھا اور user سے ایسے سوال پر interrogation کر رہا ہے جس کا جواب وہ turn one پر دے چکے تھے۔ correct answer turn 2 پر screen پر تھا، اور اس کے بعد ہر turn نے transcript کو worse کیا۔

لہٰذا agent loop نہیں ہے۔ یہ loop plus اسے چھوڑنے کا rule ہے، اور اس میں ایسا بالکل ایک rule ہے۔ باب 23 پانچ ڈھونڈتا ہے، اور دکھاتا ہے کہ ہر ایک کے missing ہونے پر کیا break ہوتا ہے۔

دونوں کو paraphrase کے بجائے quote کیا گیا ہے، کیونکہ confusion paraphrases میں manufacture ہوتی ہے۔

Definition one boundary کو اس پر رکھتی ہے کہ flow کون control کرتا ہے۔ Anthropic کی Building effective agents ambiguity کا نام لیتی ہے اور اس پر فیصلہ دیتی ہے:

"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 کے بارے میں ایک question ہے: next step کس نے choose کیا؟ آپ کے program میں ایک switch: workflow۔ model: agent۔ وہی document کہتا ہے کہ agents "are typically just LLMs using tools based on environmental feedback in a loop" — جو بالکل اوپر والی listing ہے۔

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

اسی page پر، دو sentences بعد، یہ 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 کرتی ہے؟ چوتھا اسے control of execution پر کھینچتا ہے، جو عین Anthropic کی line ہے۔ مختلف tests، ایک ہی 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، جو ہر agent کے پاس ہوتی ہے۔ "We replaced the workflow with an agent" پہلی definition کے تحت coherent ہے اور دوسری کے تحت تقریباً meaningless۔

2026 میں موجود تین systems، دونوں definitions کے تحت۔

تین میں سے دو sides بدلتے ہیں۔ یہ کسی document کی failure نہیں۔ یہ اس قسم کی meeting کے بارے میں warning ہے جس میں دو لوگ اس بات پر مکمل agree کرتے ہیں کہ system کیا کرتا ہے مگر ایک hour اس بات پر disagree کرتے ہیں کہ اسے کہنا کیا ہے۔

definitions اس لیے collide کرتی ہیں کہ ہر ایک دو independent questions کو ایک word میں collapse کر دیتی ہے۔ انہیں separate کریں اور disagreement ایک table بن جاتا ہے، جو verdict سے زیادہ useful ہے۔

ہر definition ایک مختلف cell کو dispute کرتی ہے، اور باقی دو پر dispute نہیں۔ اس لیے جب label matter کرے — contract میں، risk review میں، postmortem میں — لکھنے کے قابل دو sentences "is it an agent" نہیں بلکہ next step کس نے choose کیا اور کون دیکھ رہا تھا ہیں۔ دونوں کا جواب code پڑھ کر ملتا ہے، دونوں کو کسی کی definition نہیں چاہیے، اور مل کر یہ وہ ہر consequence اٹھاتے ہیں جس کے لیے label stand کر رہا تھا۔

اس میں کچھ نیا نہیں۔ 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 parts describe کرتا ہے بجائے boundary draw کرنے کے۔⁹ تیس years تک agree کرنے سے انکار بتاتا ہے کہ word ایک سے زیادہ job کر رہا ہے۔

اب وہ consequence جو philosophy سے پہلے پہنچتا ہے: bill۔

یہاں ہر measurement کی shape ایک جیسی ہے۔ single call کی cost 39 input tokens تھی؛ ایک tool کے ساتھ وہی question دو calls میں 420 cost کر گیا؛ stopping rule removed loop چھ calls میں 1,688 cost کر گیا۔ growth linear سے worse ہے، کیونکہ turn n اپنے ساتھ ہر previous turn اٹھاتا ہے: اس 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 اس rate پر commercial endpoint پر گئے ہوتے جو باب 16 نے 6 September 2026 کو پڑھے تھے — $2.00 per million input tokens اور $12.00 per million output — تو چار runs کی price یہ بنتی:

row two against row one وہ number ہے جسے یاد رکھنا ہے۔ ساڑھے سات گنا cost، ایسے question کے worse answer کے لیے جسے model پہلے ہی جانتا تھا۔ کچھ misconfigured نہیں تھا: tool موجود تھا، اس لیے model نے اسے use کیا — اور باب 18 کی finding، کہ catalogue کی price نقصان دیتی ہے نہ کہ اس کی accuracy، یہاں ایک tool کے catalogue کے ساتھ اپنی سب سے cheap demonstration رکھتی ہے۔

اسی لیے دونوں documents کا useful half وہ half ہے جو یہ نہ بنانے کے بارے میں ہے۔ Anthropic blunt ہے: ممکنہ طور پر simplest solution تلاش کریں اور complexity صرف ضرورت پر 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" قبول کرتے ہوئے۔⁴ OpenAI کی screen اس کا mirror image ہے — complex judgement، unmaintainable rule sets، unstructured data — اور اسی طرح ختم ہوتی ہے: "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 کے ساتھ خریدتے ہیں جو ایک بار کے بجائے N بار غلط ہو سکتا ہے۔

اب آپ کے پاس taxonomy، دونوں modern definitions، وہ دو axes جو انہیں compatible بناتے ہیں، اور ایک short loop ہے جو answers، calls اور stops کرتا ہے۔

اس loop کے ختم ہونے کا ایک طریقہ ہے: model tools مانگنا بند کر دے۔ باب 23 اسے جان بوجھ کر سات بار توڑتا ہے، اور ہر break ایک piece add کرتا ہے۔ impossible task، اور یہ کبھی ختم نہیں ہوتا — turn cap۔ running کی ایک رات، اور bill آ جاتا ہے — dollars میں budget۔ tool fail ہو — error جس پر model act کر سکے۔ وہی call دو بار — idempotency key۔ ایسی file جسے اسے touch نہیں کرنا چاہیے تھا — human approval۔ restart halfway — session persistence۔ ایسا tool جو تین minutes silence میں لیتا ہے — progress اور cancellation۔ جو نکلتا ہے وہ harness ہے، وہ file جس پر اس course کا باقی حصہ چلتا ہے۔

اس سے وہ سوال بچتا ہے جس کے بارے میں اس باب کا disputed diagonal اصل میں تھا۔ جو loop اپنا next step خود decide کرتا ہے اسے decide کرنا پڑتا ہے کہ کب stop ہو، اور ہم ابھی دیکھ چکے ہیں کہ جب یہ نہیں کر پاتا تو کیا ہوتا ہے: چھ turns، bill کا چار گنا، اور agent user سے ایسے question پر interrogation کر رہا ہے جس کا جواب یہ پہلے دے چکا تھا۔ Stopping ایک condition نہیں۔ کتنی ہیں، اور پہلے کون سی fire ہوتی ہے؟

Lilian Weng کی LLM Powered Autonomous Agents (2023) language agent کو planning، memory اور tool use میں decompose کرنے والی سب سے معروف تحریر ہے، اور دو vendor documents کے ساتھ next read کے لیے درست ہے؛ اس کے تین components اس course کے Chapters 23، 24 اور 18 ہیں، اسی order میں۔

اس chapter میں ہر number اسی machine پر produce ہوا اور کچھ estimate نہیں کیا گیا۔ corridor، floor plan، اس پر walk کرنے والے 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 Qwen2.5-0.5B-Instruct سے آتی ہیں، CPU پر float32 میں greedy decoding کے ساتھ، loopback پر ایک small local Python endpoint کے ذریعے served جو weights load کرتا ہے اور OpenAI chat-completions shape بولتا ہے — وہی seam دوبارہ، tensors Python side پر اور loop TypeScript side پر — اس لیے token counts اس model کے tokenizer کے ہیں اور latencies اسی machine کی۔ باہر سے لیے گئے واحد figures cost table کی دو prices ہیں، جو rates باب 16 نے 6 September 2026 کو OpenAI کی pricing page سے پڑھے تھے، یہاں locally measured token counts پر illustration کے طور پر applied، observed invoice کے طور پر نہیں۔