AI agentల రకాలు: reflex, goal-based, learning వివరాలు

AI agentల రకాలు

AI agentల రకాలు ఒకే వర్గీకరణ నుంచి వస్తాయి: simple reflex, model-based reflex, goal-based, utility-based మరియు learning agents. ప్రతి పేరు ఒక విషయాన్ని వివరిస్తుంది: agent ఎంత సమాచారాన్ని గుర్తుంచుకుంటుంది, చర్య తీసుకునే ముందు ఎంత దూరం వరకు ప్రణాళిక రూపొందిస్తుంది. multi-agent మరియు hierarchical అనే మరో రెండు పదాలు, ఏ ఒక్క agent ఎలా నిర్ణయం తీసుకుంటుందో కాకుండా, అనేక agentలను కలిసి ఎలా అనుసంధానించారో వివరిస్తాయి.

మీరు ఉపయోగించిన ప్రతి model కంటే ఈ జాబితా పాతది. ఇది ప్రామాణిక AI పాఠ్యపుస్తకం నుంచి వచ్చింది. Large language modelలు వచ్చిన తర్వాత కూడా ఇది ఉపయోగకరంగానే ఉంది. ఎందుకంటే మీ రూపకల్పనను ఇప్పటికీ నిర్ణయించే ప్రశ్నను ఇది అడుగుతుంది: ఈ వ్యవస్థ చర్య తీసుకునే ముందు ఏ విషయం తెలుసుకోవాలి? agent ఎక్కడ ముగుస్తుంది, అది నడిచే chat assistant ఎక్కడ ప్రారంభమవుతుంది అనే విషయాన్ని ఇంకా స్పష్టంచేసుకుంటున్నట్లయితే, ముందుగా AI agentకు మరియు అది నడిచే LLMకు మధ్య తేడా చదవండి. ఈ పేజీ ఆ దశ తర్వాతి విషయాన్ని ప్రారంభిస్తుంది.

సరళ reflex agents: ఒక condition, ఒక action

సరళ reflex agent ప్రస్తుత input ను ఒక action కు mapping చేస్తుంది. అంతకుముందు జరిగిన విషయాల గురించి అది ఎలాంటి memory ను నిల్వచేయదు. Temperature 25 కంటే ఎక్కువగా ఉంటే fan ను ఆన్ చేయాలి. మొత్తం mechanism ఇదే.

మీరు ఇలాంటి agent ను ఇప్పటికే ఉపయోగించి ఉండే అవకాశం చాలా ఎక్కువ. ఒక webhook n8n workflow ను trigger చేస్తుంది. ఆ workflow form submission ను చదివి database లో ఒక row ను రాస్తుంది. ఇది సరళ reflex agent. ఆ row కోసం ఒక category ని ఎంచుకోవడానికి మధ్యలో language model ఉన్నా, ఇది అదే రకమైన agent గా ఉంటుంది. గంట క్రితం అది ఏమి చేసిందో అడిగితే చెప్పలేడు. ఎందుకంటే ఆ సమాధానాన్ని ఏదీ నిల్వ చేయలేదు.

ఈ రకం ప్రజలు ఊహించేదానికంటే ఎక్కువ సందర్భాల్లో సరైనది. దీన్ని అమలు చేయడం చవకగా ఉంటుంది. దీని failure ను సులభంగా అర్థం చేసుకోవచ్చు: condition సరిపోలిందా లేదా అన్నదే విషయం. పని నిజంగా "X వచ్చినప్పుడు Y చేయాలి" అనే విధంగా ఉంటే, memory తప్పులు జరిగే అవకాశాలను మాత్రమే పెంచుతుంది. దాని వల్ల అదనపు ప్రయోజనం ఉండదు. webhook ద్వారా trigger అయ్యే n8n agent ఈ taxonomy లోని ఇదే వరుసకు చెందినది; దీనిపై user interface మాత్రమే ఉంటుంది.

సరైన action చరిత్రపై ఆధారపడిన క్షణంలో ఇది విఫలమవుతుంది. Thread state లేని reply bot మూడో message కు తనతో తానే విరుద్ధంగా సమాధానం ఇస్తుంది. ఎందుకంటే మొదటి రెండు messages దాని input లో ఎప్పుడూ భాగం కాలేదు.

ఈవెంట్ల మధ్య స్థితిని నిలుపుకునే model-based reflex agents

Model-based reflex agent తన పరిసరాల అంతర్గత చిత్రాన్ని నిలుపుకుంటుంది. కొత్త input వచ్చినప్పుడు ఆ చిత్రాన్ని update చేస్తుంది. ఇక్కడ "model" అంటే neural network model కాదు; ప్రపంచానికి సంబంధించిన model. ప్రస్తుత అర్థం ఏర్పడకముందే ఈ పదం సుమారు నలభై సంవత్సరాలుగా వాడుకలో ఉంది. మొదటిసారి చదివినప్పుడు ఇది దాదాపు అందరినీ గందరగోళానికి గురిచేస్తుంది.

చలనం గుర్తించకపోతే ఇరవై నిమిషాల తర్వాత lights off చేసే home automation rule model-based. అది తప్పనిసరిగా అలా ఉండాలి. "ఇప్పుడే చలనం లేదు" మరియు "21:40 నుంచి చలనం లేదు" అనే రెండు పరిస్థితులు simple reflex agent కు ఒకే input గా కనిపిస్తాయి. వాటి మధ్య తేడాను చూపేది నిల్వ చేసిన state మాత్రమే.

LLM సందర్భంలో, వెనుక memory store ఉన్న ఏ agent అయినా ఇదే విధానం. అది నిరంతరం నవీకరించబడే conversation summary కావచ్చు. ప్రతి run ప్రారంభంలో agent చదివే సాధారణ markdown file కావచ్చు. Agent కోసం local memory service ఈ ఆలోచనను ఒక ప్యాకేజీగా అందిస్తుంది. Mechanism మారదు. ఈవెంట్ ముగిసిన తర్వాత కూడా agent ప్రపంచం గురించి ఉంచుకున్న చిత్రం కొనసాగుతుంది.

State కు ఖర్చు ఉంటుంది. పాతబడిన fact, fact లేకపోవడంకన్నా ప్రమాదకరం. ఎందుకంటే agent ఎలాంటి హెచ్చరిక లేకుండా, పూర్తి నమ్మకంతో దాని ఆధారంగా చర్య తీసుకుంటుంది. మీరు నిల్వ చేసే ప్రతి సమాచారానికి expire అయ్యే విధానం లేదా మళ్లీ నిర్ధారించే విధానం ఉండాలి. లేకపోతే మార్చిలో decommission చేసిన server గురించి agent నిరంతరం reasoning చేస్తూనే ఉంటుంది.

తనిఖీ చేయగల స్థితి వైపు ప్రణాళిక చేసే లక్ష్య-ఆధారిత ఏజెంట్లు

లక్ష్య-ఆధారిత ఏజెంట్‌కు ఒక లక్ష్య స్థితి అందుతుంది. దాన్ని చేరుకునే చర్యల క్రమాన్ని అది శోధిస్తుంది. అది చివరికి చేరాల్సిన స్థానం నుంచి వెనుకకు పనిచేస్తుంది. అందువల్ల మార్గాన్ని ముందుగానే రాసి ఉంచాల్సిన అవసరం ఉండదు.

మీరు స్వయంగా అమలు చేయగల స్పష్టమైన ఉదాహరణ coding agent. "విఫలమవుతున్న test ను pass చేయించు" అనే సూచనలో ఏ files లేదా ఏ steps అవసరమో చెప్పలేదు. ఏజెంట్ test ను చదివి, ఒక plan రూపొందించి, ఏదో మార్చి, test ను అమలు చేసి, error ను చదివి, మళ్లీ ప్రయత్నిస్తుంది. అది వాస్తవంగా అమలు చేయగల check వద్ద loop ముగుస్తుంది. అందుకే ఆ సూచన పనిచేస్తుంది; "ఈ code ను మెరుగుపరచు" పనిచేయదు. ఏజెంట్ స్వయంగా evaluate చేయగల goal ను ఏజెంట్ చేరుకోగలడు. అది evaluate చేయలేని goal, ఖర్చుతో కూడిన అంతులేని loop గా మారుతుంది. మీ స్వంత VPSపై coding agent ను అమలు చేయడం ద్వారా ఆ loop ను మీ laptop ను ఆక్రమించకుండా నిరంతరం నడిచే చోట ఉంచవచ్చు.

ఖర్చు ఈ దశలో వస్తుంది. ప్రతి planning step ఇప్పటివరకు ఉన్న history ను కలిగి ఉండే మరో model call అవుతుంది. అందువల్ల ten-step task, one-step task ధరకు ten times కాదు; దానికంటే ఎక్కువ ఖర్చవుతుంది. ముఖ్యమైన engineering loop నిర్మాణం మరియు దాన్ని ఆపే condition పై ఆధారపడి ఉంటుంది. ఇదే loop engineering విషయం.

Utility ఆధారిత agents: అనేక మంచి సమాధానాల మధ్య ఎంపిక

Goal అనేది binary. Utility అనేది ఒక score. Utility ఆధారిత agent అనేక ఆమోదయోగ్యమైన ఫలితాలను పరిశీలించి, మీరు రూపొందించిన function ప్రకారం అత్యధిక score పొందినదాన్ని ఎంచుకుంటుంది.

పని రోజు ప్రారంభమయ్యేలోపు పూర్తవుతూ, uplink పై అధిక భారం కలిగించని backup job ఒక utility సమస్య. దీనికి ఒకే సరైన సమాధానం ఉండదు; trade-off మాత్రమే ఉంటుంది. ఏ request ను ఏ model నిర్వహించాలో నిర్ణయిస్తూ, ధరను answer quality తో పోల్చే router కూడా ఇదే విధంగా పనిచేస్తుంది.

Algorithm కష్టమైన భాగం కాదు. నిజాయితీగా ఉండే utility function రాయడమే కష్టం. Cost ఆధారంగా మాత్రమే score ఇస్తే, ఖరీదైన model అవసరమైన request తో సహా ప్రతి request కు అత్యంత చవకైన model ను ఎంచుకుంటారు. System మీరు కొలిచిన అంశాన్నే ఖచ్చితంగా optimise చేస్తుంది. మీరు కొలిచిన అంశాన్ని కొలవడం సులభం కాబట్టి మాత్రమే ఎంచుకున్నప్పుడు ఇది సమస్యగా మారుతుంది.

లెర్నింగ్ ఏజెంట్లు: చాలా మంది తమ వద్ద ఇప్పటికే ఉన్నాయని భావించే రకం

లెర్నింగ్ ఏజెంట్ గత ఫలితాలపై వచ్చిన feedback ఆధారంగా తన ప్రవర్తనను మార్చుకుంటుంది. ఫలితాన్ని అంచనా వేసే ఒక భాగం, ఆ అంచనా ఆధారంగా policyని మార్చే మరో భాగం దీనికి అవసరం.

చాలా తక్కువ self-hosted వ్యవస్థలు ఈ నిర్వచనానికి సరిపోతాయి. గత వారం తాను రాసిన notes ను చదివే agent, memory file కలిగిన model-based agent మాత్రమే. దాని weights మారవు. దాని policy కూడా మారదు. Retrieval అనేది learning కాదు. ఈ తేడా ఆచరణలో ముఖ్యమైనది: memory-based వ్యవస్థలో memoryని ఎవరైనా సవరించకపోతే, అది చేసిన తప్పును ఎప్పటికీ పునరావృతం చేస్తుంది. Learning వ్యవస్థ మాత్రం అదే తప్పును మళ్లీ చేయడం ఆపాలి.

మీకు learning భాగం కావాలంటే, ముందుగా evaluationను నిర్మించండి. Score చేసిన test set, దానిపై మీ మార్పును అమలు చేయడం, ఆ మార్పును ఉంచాలా లేదా తొలగించాలా అనే నిర్ణయం — ఇవి కలిసి ఒక closed loopను ఏర్పరుస్తాయి. అందులో learning component మీరే. ఇది వినిపించినంత వేగంగా జరగదు. ప్రస్తుతం self-hosted భాగాలతో పనిచేసే ఏకైక విధానం ఇదే. eval harnessను self-host చేయడం అక్కడి నుంచే ప్రారంభమవుతుంది.

బహుళ-ఏజెంట్ మరియు హైరార్కికల్ వ్యవస్థలు: రకాలు కాదు, అమరికలు

ఇవి ఆరవ మరియు ఏడవ రకాలు కావు. ఏజెంట్లు ఎలా అమర్చబడ్డారో ఇవి వివరిస్తాయి.

బహుళ-ఏజెంట్ వ్యవస్థ shared environment లో ఒకేసారి అనేక ఏజెంట్లను నడుపుతుంది. ఉదాహరణకు, ఇది queue లేదా git repository కావచ్చు. Environment shared గా ఉండటంతో ఏజెంట్లు అందులో పరస్పరం ఢీకొంటారు. ఇద్దరు ఏజెంట్లు ఒకే file ను సవరించడం సాధారణ వైఫల్యం. దీనికి పరిష్కారం lock లేదా work queue. ఏ prompt దీనిని పరిష్కరించదు.

హైరార్కికల్ వ్యవస్థలో workers పై supervisor ఉంటుంది. Supervisor ఒక task ను విభజించి, భాగాలను పంపిణీ చేసి, తిరిగి వచ్చిన ఫలితాలను merge చేస్తుంది. ఇది ప్రజలు పనిని విభజించే విధానంతో సరిపోలడం వల్ల విస్తృతంగా ఉపయోగిస్తారు. అయితే supervisor చదివే ప్రతి report తో దాని context పెరుగుతుంది కాబట్టి ఇది ఖరీదైనది. బహుళ-ఏజెంట్ harness ఆ wiring ను ఆచరణలో చూపిస్తుంది.

ఎక్కువగా పనిచేయని నలుగురు agents కంటే, సరిగ్గా పనిచేసే ఒక agent మేలు.

ప్రతి handoff లో సమాచారం కోల్పోయే అవకాశం ఉంటుంది. ముందుగా ఒక loop తో ప్రారంభించండి. bottleneck గా ఉన్న step ను స్పష్టంగా గుర్తించగలిగినప్పుడు మాత్రమే దాన్ని విభజించండి.

దాదాపు ప్రతి వాస్తవ వ్యవస్థ hybrid గా ఎందుకు ఉంటుంది

మీరు స్వయంగా నడిపించే deployment agent ను పరిగణించండి. ఒక webhook దాన్ని ప్రారంభిస్తుంది; ఇది reflex ఆధారిత ప్రవర్తన. అది ప్రస్తుత release స్థితిని చదువుతుంది; ఇది model-based. నడుస్తున్న version నుంచి target version కు వెళ్లే దశలను అది ప్రణాళిక చేస్తుంది; ఇది goal-based. ప్రస్తుత load ఆధారంగా rollout window ను ఎంచుకుంటుంది; ఇది utility-based. అది తన policy ని ఎప్పుడూ సవరించదు; కాబట్టి అది learning system కాదు.

ఒకే వ్యవస్థలో taxonomy లోని నాలుగు వర్గాలు ఒకేసారి ఉంటాయి. పూర్తయిన product కు label పెట్టడానికి కాకుండా, design checklist గా ఉపయోగించినప్పుడే taxonomy ఉపయోగకరంగా ఉంటుంది. వ్యవస్థ తప్పుగా ప్రవర్తించినప్పుడు, ఏ layer లో సమస్య ఉందో తెలుసుకోవడం ఉపయోగకరమైన ప్రశ్న. తప్పు event పై పనిచేసిన trigger, పాతబడిన state, ఎప్పటికీ pass కాని goal check, తప్పు outcome కు reward ఇచ్చే score — ఇవి నాలుగు వేర్వేరు bugs. వీటికి నాలుగు వేర్వేరు పరిష్కారాలు అవసరం.

ఏ పనికి ఏ రకం సరిపోతుంది

• ట్రిగ్గర్ స్థిరంగా ఉండి, ప్రతిస్పందన కూడా స్థిరంగా ఉండి, గత చరిత్ర అవసరం లేకపోతే: simple reflex.
• సరైన ప్రతిస్పందన గతంలో ఏమి జరిగిందనే దానిపై ఆధారపడితే: model-based reflex.
• తుది స్థితిని తనిఖీ చేయగలిగినా, అక్కడికి చేరే మార్గం ముందుగా తెలియకపోతే: goal-based.
• పరస్పర సమన్వయం అవసరమైన అనేక ఆమోదయోగ్య ఫలితాలు ఉంటే: utility-based.
• కాలక్రమేణా ఫలితాలు మెరుగుపడాలంటే: eval loop రూపొందించండి. ఈ ప్రక్రియలో నేర్చుకునే component మీరే అని అంగీకరించండి.

ఈ agents ను మీరే host చేయగలరా, దానికి ఎంత ఖర్చవుతుంది?

అవును. ఖర్చు రెండు భాగాలుగా ఉంటుంది. Orchestration ఖర్చు తక్కువ. n8n instance లేదా Python లోని agent loop ఎక్కువ సమయం network calls కోసం వేచి ఉంటుంది. అందువల్ల 2 vCPU మరియు 4 GB RAM సరిపోతాయి. ఖర్చు ప్రధానంగా model వల్ల వస్తుంది.

Agent hosted API ను పిలిస్తే server కు దాదాపు ఏమీ అవసరం ఉండదు. బిల్లు tokens సంఖ్యకు అనుగుణంగా పెరుగుతుంది. Goal-based agent విషయంలో ఇది మీరు అనుమతించే planning steps సంఖ్యపై ఆధారపడుతుంది. కాబట్టి loop కు పరిమితి పెట్టండి.

Model ను మీ స్వంత hardware పై నడిపితే, మీరు అసలు ఏ model ను నడపగలరో RAM నిర్ణయిస్తుంది. క్రింది గణాంకాలు August 2026 నాటికి ప్రచురించబడిన 4-bit quantised weights యొక్క సాధారణ file sizes. వాటి పక్కన మొత్తం RAM కోసం planning figure ఇచ్చాం. కారణం context window మరియు runtime కు weights కు మించిన అదనపు memory అవసరం.

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

4-bit లో 8B model యొక్క weights సుమారు 4.9 GB ఉంటాయి. 10 GB RAM ఉన్న machine దాన్ని swapping లేకుండా నడుపుతుంది. అదే quantisation వద్ద 70B model యొక్క weights 43 GB ఉంటాయి. దీనికి సుమారు 64 GB RAM అవసరం. ఈ సంఖ్యల్లో లేనిది speed. GPU లేని VPS లో 4-bit 8B model సెకనుకు single-digit tokens మాత్రమే ఉత్పత్తి చేస్తుంది. రాత్రంతా queue ను ప్రాసెస్ చేసే agent కు ఇది సరిపోతుంది. కానీ వ్యక్తి ఫలితం కోసం వేచి ఉన్న interactive పనులకు ఇది నెమ్మదిగా ఉంటుంది. Local inference ను batch పనులకు పరిమితం చేయండి. Interactive భాగాలకు GPU లేదా API ఉపయోగించండి. మీరు స్వయంగా host చేయగల AI agents యొక్క సంక్షిప్త జాబితా ఏ projects disk స్థలానికి తగినవో వివరిస్తుంది. 2026లో agents కోసం నేర్చుకోవాల్సిన విషయాల క్రమం ఏమి, ఏ క్రమంలో నేర్చుకోవాలో వివరిస్తుంది.

టాక్సానమీ ఉపయోగపడటం ఆగే చోట

ఇది tools లేదా permissions గురించి ఏమీ చెప్పదు. పాఠ్యపుస్తకంలోని agents గ్రహించి చర్య తీసుకుంటాయి. production API token తమ వద్ద ఉన్న agent గురించి ఆ అధ్యాయం రాసినవారు ఆందోళన చెందలేదు. shell access ఉన్న goal-based agent, read-only database connection మాత్రమే ఉన్న goal-based agent ఒకే పట్టిక వరుసలో ఉంటాయి. కానీ వాటి ప్రమాద స్థాయిలు పూర్తిగా భిన్నంగా ఉంటాయి. Agent ఎంత తెలివిగా ఉండాలో నిర్ణయించే ముందు, అది ఏ వనరులను తాకవచ్చో నిర్ణయించండి. దానికి credential ఇచ్చే ముందు AI agent నుంచి secrets ను ఎలా దూరంగా ఉంచాలి చదవండి.

ఒక step విఫలమైనప్పుడు ఏమి జరుగుతుందో కూడా ఇది చెప్పదు. వాస్తవ agents తమ runtime లో ఎక్కువ భాగాన్ని errors నిర్వహించడానికే వినియోగిస్తాయి: rate limit ఎదురవడం లేదా model ఊహించని ఫలితాన్ని tool తిరిగి ఇవ్వడం వంటి సందర్భాల్లో. మీ system ఉపయోగించదగినదిగా ఉందా లేదా అనేది ఆ code నిర్ణయిస్తుంది. Taxonomy లోని ఏ వరుసా దాన్ని వివరించదు.

FAQ

AI agents యొక్క ఐదు రకాలు ఏమిటి?

Simple reflex, model-based reflex, goal-based, utility-based, learning agents అనే ఐదు రకాలు ఉన్నాయి. Agent చర్య తీసుకునే ముందు దానికి ఎంత సమాచారం ఉందనే క్రమంలో ఇవి అమర్చబడ్డాయి. Simple reflex agent ప్రస్తుత input ను మాత్రమే చూస్తుంది. Model-based agent తన environment కు సంబంధించిన state ను నిల్వ ఉంచుతుంది. Goal-based agent లక్ష్య state వైపు ప్రణాళిక రూపొందిస్తుంది. Utility-based agent సాధ్యమైన అనేక ఫలితాలకు score కేటాయించి, అత్యధిక score ఉన్నదాన్ని ఎంచుకుంటుంది. Learning agent feedback ఆధారంగా తన policy ని మార్చుకుంటుంది. అయితే వాస్తవ self-hosted setup లో ఇది దాదాపుగా ఉపయోగించబడదు.

సాధారణ automation కోసం ఏ రకమైన AI agent ను ఉపయోగించాలి?

Simple reflex agent ను ఉపయోగించాలి. ఆచరణలో దీని అర్థం webhook లేదా fixed sequence ను trigger చేసే schedule. ఇప్పుడే వచ్చిన input పై మాత్రమే సరైన response ఆధారపడి ఉంటే, memory వల్ల failure modes పెరుగుతాయి, సామర్థ్యం మాత్రం పెరగదు. గతంలో ఏమి జరిగిందో తెలుసుకోవాల్సిన ఒక నిర్ణయాన్ని స్పష్టంగా గుర్తించగలిగినప్పుడు model-based design కు మారండి.

నా స్వంత AI agents ను VPS పై నడపవచ్చా?

అవును. Orchestration layer తేలికగా ఉంటుంది. అందువల్ల 2 vCPU మరియు 4 GB RAM ఉంటే workflow engine లేదా agent loop సౌకర్యంగా నడుస్తుంది. అసలు నిర్ణయం model ఎక్కడ నడవాలి అనేదే. Hosted API ఉపయోగిస్తే server చిన్నదిగా ఉంటుంది, ఖర్చు tokens పైకి మారుతుంది. Local model కు దాని parameter count కు అనుపాతంగా RAM అవసరం. GPU లేకపోతే అది సెకనుకు single-digit tokens మాత్రమే generate చేస్తుంది. అందువల్ల ఇది chat window కంటే queued batch work కు అనుకూలంగా ఉంటుంది.

Large language model స్వయంగా AI agent అవుతుందా?

కాదు. Model input text ను output text గా మార్చి ఆగిపోతుంది. దాన్ని loop లో చుట్టి, world పై చర్య తీసుకునేలా చేసి, వచ్చిన result ను మళ్లీ దానికి అందించినప్పుడు అది agent అవుతుంది. ఇందుకోసం agent call చేయగల tools మరియు loop ఎప్పుడు ఆగాలో తెలిపే condition అవసరం. Wrapper అనేదే agent. Model దాని లోపల ఉండే ఒక component మాత్రమే.

నాకు multi-agent system అవసరమా?

సాధారణంగా అవసరం లేదు. అనేక tools తో కూడిన ఒకే loop చాలా పనులను నిర్వహిస్తుంది. దీన్ని debug చేయడం కూడా చాలా సులభం. పనిలోని భాగాలు నిజంగా స్వతంత్రంగా ఉండి ఒకేసారి నడపగలిగినప్పుడు, లేదా ఒక భాగానికి వేరే model అవసరమైనప్పుడు multiple agents ఉపయోగపడతాయి. అయితే coordination ఖర్చు ఉంటుంది: shared state నిర్వహణ అవసరం, అలాగే ప్రతి worker report చదివే కొద్దీ context పెరుగుతున్న supervisor అవసరం. ఆలస్యంగా నడుస్తున్న step ను స్పష్టంగా గుర్తించగలిగినప్పుడు మాత్రమే రెండో agent ను జోడించండి.