I used to think building an AI agent was basically the same as prompting a chatbot. You frame the question well, the model answers, and you call it a day. Then I shipped a few applications. Reality hit hard. An LLM is not an agent. An LLM predicts the next token. The loop is what creates the agent.

టీ తయారు చేయడం గురించి ఆలోచించండి. మీరు make_tea() అనే ఒకే ఒక్క కమాండ్‌ను ఇచ్చి వెళ్ళిపోరు. మీరు కెటిల్‌లో నీళ్లు పోస్తారు, ట్యాప్ ప్రెజర్ తక్కువగా ఉందని గ్రహించి వేచి ఉంటారు, స్విచ్ ఆన్ చేస్తారు, స్విచ్ పాడైందని గమనిస్తారు, వేరే బర్నర్ దగ్గరకు వెళ్తారు, ఆవిరి కోసం చూస్తారు, పోస్తారు, రుచి చూస్తారు, బహుశా టీ ఆకులు ఎక్కువ సేపు నానిపోయినందున తేనె కూడా కలుపుతారు. లక్ష్యం మారదు, కానీ దశలు మారుతుంటాయి. మీరు గమనిస్తారు, సర్దుబాటు చేస్తారు మరియు మళ్ళీ ప్రయత్నిస్తారు. AI ఏజెంట్లు కూడా సరిగ్గా ఇలాగే పనిచేస్తాయి.

ఏజెన్సీని సృష్టించే సైకిల్

లూప్ అనేది కేవలం ఒక అబ్‌స్ట్రాక్ట్ థియరీ కాదు. ఇది మీ తరపున పనిచేసే ఏ వ్యవస్థకైనా ఒక ఆపరేషనల్ హార్ట్‌బీట్ వంటిది. ఇది ఆచరణలో ఎలా ఉంటుందో ఇక్కడ చూడండి:

  • Think: మోడల్ లక్ష్యం గురించి ఆలోచించి దానికి ఏమి కావాలో నిర్ణయిస్తుంది. ఒక యూజర్, "నేను రేపు పోర్ట్‌ల్యాండ్‌కు గొడుగు తీసుకువెళ్లాలా?" అని అడిగితే, దానికి వాతావరణ సూచన (weather forecast) మరియు ఒక లొకేషన్ అవసరమని మోడల్ గుర్తిస్తుంది.
  • Act: మోడల్ ఒక టూల్‌ను ఉపయోగిస్తుంది. అది "Portland"ను గుర్తించడానికి ఒక geocoding APIని పిలవవచ్చు, ఆపై ఆ కోఆర్డినేట్‌లతో వాతావరణ సమాచారం కోసం ఒక endpointని సంప్రదించవచ్చు.
  • Observe: మోడల్ ఆ టూల్ యొక్క అవుట్‌పుట్‌ను చదువుతుంది. API నుండి JSON ఫారకాస్ట్ వచ్చిందా, 403 ఎర్రర్ వచ్చిందా, లేదా HTML మెయింటెనెన్స్ పేజీ వచ్చిందా?
  • Update: అది చూసిన దాని ఆధారంగా, మోడల్ తన ప్రణాళికను సవరిస్తుంది. ఒకవేళ geocoder, Portland, Oregon కి బదులుగా Portland, Maine అని తిరిగి ఇస్తే, మోడల్ దానిని స్పష్టం చేయాలి. ఒకవేళ API పనిచేయకపోతే, అది మరొక బ్యాకప్ సోర్స్‌కు మారవచ్చు లేదా యూజర్‌ని అడగవచ్చు.
  • Think Again: కొత్త సందర్భంతో (context) సైకిల్ మళ్ళీ ప్రారంభమవుతుంది.

ఇది మీరు ఒకసారి రాసి మర్చిపోయే ఐదు వేర్వేరు ఫంక్షన్లు కాదు. ఇది లక్ష్యం చేరే వరకు లేదా ఏదైనా ఆగిపోయే వరకు నడిచే నిరంతర ఇంజిన్. మోడల్ ఒక స్క్రిప్ట్ లాగా కోడ్‌ను ఎగ్జిక్యూట్ చేయడం లేదు. అది ప్రపంచ స్థితిని విశ్లేషిస్తుంది, ఒక చర్యను ఎంచుకుంటుంది, దాని ఫలితాన్ని చదువుతుంది మరియు తదుపరి ఏమి చేయాలో నిర్ణయిస్తుంది. ఒక అద్భుతమైన autocomplete కి మరియు పనిని పూర్తి చేసే ఏజెంట్‌కు మధ్య ఉన్న తేడా ఇదే.

ఫ్రేమ్‌వర్క్‌లన్నీ ఒకేలా ఎందుకు కనిపిస్తాయి?

మీరు LangGraph, CrewAI, లేదా AutoGen లతో సమయం గడిపితే, అవి ఒకేలా కనిపిస్తాయని మీరు గమనించే ఉంటారు. LangGraph ఫ్లోను నోడ్స్ (nodes) మరియు ఎడ్జెస్ (edges) కలిగిన ఒక పర్సిస్టెంట్ గ్రాఫ్‌గా మోడల్ చేస్తుంది. CrewAI ఏజెంట్లను రోల్స్ (roles) మరియు క్రూస్ (crews) గా విభజిస్తుంది. AutoGen మల్టీ-ఏజెంట్ సంభాషణలను సమన్వయం చేస్తుంది. ప్యాకేజింగ్ వేరువేరుగా ఉన్నా, నిర్మాణం (skeleton) మాత్రం ఒకటే.

ఇవన్నీ ఒకే లూపింగ్ సూత్రం (looping principle) ఆధారంగా రూపొందించబడ్డాయి కాబట్టి ఇవి ఒకేలా కనిపిస్తాయి. LangGraph ఈ సైకిల్‌ను టూల్ కాల్స్ మరియు మోడల్ ఇన్ఫరెన్స్‌ల మధ్య స్టేట్ ట్రాన్సిషన్లుగా (state transitions) స్పష్టంగా నిర్మిస్తుంది. CrewAI ఈ లూప్‌ను రోల్-ఆధారిత ఏజెంట్ల లోపల ఉంచుతుంది, కానీ ప్రతి క్రూ మెంబర్ ఇప్పటికీ ప్లానింగ్, యాక్టింగ్ మరియు అబ్జర్వింగ్ ద్వారానే వెళ్తారు. AutoGen నటుల (actors) మధ్య సందేశాలను పంపిణీ చేస్తుంది, అయినప్పటికీ ప్రతి దశ కూడా generate, execute, reflect, మరియు route యొక్క వైవిధ్యమే.

ఈ ఫ్రేమ్‌వర్క్‌లు లూప్ మీద దృష్టి పెడతాయి, ఎందుకంటే ఏజెన్సీ అనేది అక్కడే ఉంటుంది. అంతర్గత మోడల్ GPT-4, Claude, లేదా ఏదైనా fine-tuned open-weight మోడల్ కావచ్చు. లూప్ లేకపోతే, అది కేవలం చాలా ఖరీదైన సెంటెన్స్ కంప్లీటర్ మాత్రమే. లూప్ ఉంటే, అది అనేక ప్రయత్నాల ద్వారా ఒక లక్ష్యాన్ని చేరుకోగల వ్యవస్థగా మారుతుంది.

అసలైన పని ఎప్పుడు మొదలవుతుంది?

లోకల్ డెమోలు అద్భుతంగా అనిపిస్తాయి. కానీ ప్రొడక్షన్ అనేది అద్భుతాలు మరియు సమస్యలు ఎదురయ్యే చోటు. మీరు ప్రోటోటైపింగ్ దశ దాటిన తర్వాత, మీరు AI సమస్యలను పరిష్కరించడం ఆపివేసి, సిస్టమ్స్ ఇంజనీరింగ్ సమస్యలను పరిష్కరించడం ప్రారంభిస్తారు.

టూల్ వైఫల్యాలు అనివార్యం. APIs టైమ్ అవుట్ అవుతాయి. అవి తప్పుగా ఉన్న JSONలను తిరిగి ఇస్తాయి. HTMLలో చుట్టబడిన 500 ఎర్రర్‌లను ఇస్తాయి. మీ లూప్ ప్రతి టూల్ అవుట్‌పుట్‌ను గుడ్డిగా నమ్మితే, మీ ఏజెంట్ విజయం సాధించినట్లు భ్రమపడవచ్చు (hallucinate) లేదా అయోమయంలో పడిపోవచ్చు. మీకు ప్రతి రిటర్న్ పేలోడ్‌పై రీట్రై లాజిక్ (retry logic), సర్క్యూట్ బ్రేకర్లు (circuit breakers) మరియు స్కీమా వాలిడేషన్ (schema validation) అవసరం.

మెమరీ పాతబడిపోతుంది. యూజర్ యొక్క ప్రిఫర్డ్ డేటాబేస్ PostgreSQL అని మీ ఏజెంట్‌కు గుర్తుంటుంది, కానీ ఇన్‌ఫ్రాస్ట్రక్చర్ టీమ్ నిన్న రాత్రి కొత్త క్లస్టర్‌కు మారవచ్చు. సందర్భాన్ని (context) రిఫ్రెష్ చేయడానికి లేదా ఎక్స్‌పైర్ చేయడానికి యంత్రాంగం లేకపోతే, ఏజెంట్ పని చేయని ఎండ్‌పాయింట్‌లకు కూడా ధైర్యంగా కమాండ్‌లను జారీ చేస్తుంది. మెమరీకి టైమ్‌స్టాంప్‌లు, కాన్ఫిడెన్స్ స్కోర్‌లు మరియు తనను తాను ఇన్వాలిడేట్ చేసుకునే సామర్థ్యం ఉండాలి.

ఇన్ఫినిట్ లూప్‌లు నిశ్శబ్ద హంతకులు. ఒక ఏజెంట్ వెబ్‌లో వెతుకుతుంది, ఉపయోగపడేది ఏదీ దొరకదు, క్వెరీని కొంచెం మారుస్తుంది, మళ్ళీ వెతుకుతుంది, ఏదీ దొరకదు, మరియు ఇదే మళ్ళీ మళ్ళీ చేస్తుంది. గరిష్ట ఇటరేషన్ సీలింగ్ (maximum iteration ceiling) లేదా సెమాంటిక్ డూప్లికేట్ డిటెక్షన్ లేకపోతే, యూజర్ వేచి ఉండగా అది టోకెన్లను మరియు డబ్బును ఖర్చు చేస్తుంది. మీరు గార్డ్‌రైల్స్ నిర్మించాలి: రీట్రైలపై కఠినమైన పరిమితులు, డైవర్జెన్స్ చెక్‌లు మరియు హ్యూమన్ ఎస్కలేషన్ పాత్‌లు.

అసంబద్ధమైన డేటా తర్కాన్ని దెబ్బతీస్తుంది. Retrieval-Augmented Generation పైప్‌లైన్‌లు తరచుగా కాంటెక్స్ట్ విండోలోకి అస్పష్టంగా సంబంధం ఉన్న యాభై పేరాగ్రాఫ్‌ల డాక్యుమెంటేషన్‌ను పంపిస్తాయి. దీనివల్ల ఏజెంట్ అనవసరమైన సమాచారంతో (noise) ఇబ్బంది పడి, తప్పుడు టూల్‌ను ఎంచుకుంటుంది లేదా పారామీటర్‌ను తప్పుగా ఊహిస్తుంది (hallucinates). మోడల్ రిట్రీవ్ చేసిన టెక్స్ట్‌ను చూడకముందే మీకు ఫిల్టరింగ్, ర్యాంకింగ్ మరియు సంక్షిప్త సారాంశం (summarisation) అవసరం.

ఒక ఏజెంట్‌కు కేవలం మేధస్సు మాత్రమే సరిపోదు. దానికి ఒక వ్యవస్థ అవసరం: మేనేజ్డ్ మెమరీ, ఎక్స్‌ప్లిసిట్ స్టేట్ ట్రాకింగ్, కఠినమైన గార్డ్‌రైల్స్ మరియు అబ్జర్వబుల్ టెలిమెట్రీ. మోడల్ ఎంత మెరుగ్గా ఉంటే, దాని చుట్టూ ఉన్న వ్యవస్థ కూడా అంత మెరుగ్గా ఉండాలి. ఒక బలహీనమైన లూప్‌లో ఉన్న శక్తివంతమైన మోడల్ కేవలం మరింత స్పష్టమైన వైఫల్యాలను మాత్రమే సృష్టిస్తుంది.

పనిని పూర్తి చేయడం

ఏజెంట్లలో నిజమైన మేధస్సు అంటే మొదటి సమాధానాన్ని సరిగ్గా చెప్పడం మాత్రమే కాదు. ప్రణాళిక ప్రకారం ఏదీ జరగనప్పుడు, ఉద్దేశ్యానికి మరియు ఫలితానికి మధ్య ఉన్న అంతరాన్ని అధిగమించడం ముఖ్యం. మొదటి ప్రయత్నం సులభం. ఎవరైనా ఒక 'హ్యాపీ పాత్' (సులభమైన మార్గాన్ని) స్క్రిప్ట్ చేయగలరు. కానీ అసలైన సవాలు నాలుగవ ఇటరేషన్‌లో వస్తుంది—అక్కడ ప్రైమరీ API పనిచేయదు, కాంటెక్స్ట్ విండో తగ్గుతూ ఉంటుంది, యూజర్ అసహనానికి గురవుతుంటారు, మరియు ఏజెంట్ ఇంకా ఏదో ఒక ఉపయోగకరమైన విషయాన్ని అందించాల్సి ఉంటుంది.

ఆ పట్టుదలే ఒక డెమోను మరియు ఒక ప్రొడక్ట్‌ను వేరు చేస్తుంది. ఇది ప్రతి అడుగు నుండి నేర్చుకునే సామర్థ్యం—రియల్ టైమ్‌లో మోడల్ వెయిట్స్‌ను అప్‌డేట్ చేయడం ద్వారా కాదు, ప్రణాళికను (plan) అప్‌డేట్ చేయడం ద్వారా. వ్యూహాలు మారుతున్నప్పటికీ, ఏజెంట్ తన లక్ష్యాన్ని స్థిరంగా ఉంచుకుంటుంది. ఇదే 'లూపింగ్ ప్రిన్సిపల్' యొక్క అసలైన పనితీరు.

మరి భవిష్యత్తు పెద్ద మోడల్స్‌కు చెందుతుందా లేక మెరుగైన ఎగ్జిక్యూషన్ లూప్స్‌కు చెందుతుందా? స్కేల్ ఖచ్చితంగా సహాయపడుతుంది. మరింత సామర్థ్యం ఉన్న మోడల్ ప్రతి సైకిల్‌లో మెరుగ్గా ఆలోచిస్తుంది. కానీ ఒక కచ్చితమైన, అబ్జర్వబుల్ మరియు రెసిలియంట్ లూప్‌లో నడిచే చిన్న మోడల్, అన్నింటినీ ఒకే షాట్‌లో పరిష్కరించమని అడిగే ఒక భారీ మోడల్ కంటే దాదాపు ఎప్పుడూ మెరుగ్గా పనిచేస్తుంది. అంచనాను (prediction) చర్యగా (action) మార్చేది ఆ లూప్ మాత్రమే. అక్కడ పెట్టుబడి పెట్టండి.

మూలం: The Looping Principle: A Simple Mental Model for Understanding AI Agents

ఇలాంటి మరిన్ని చర్చల కోసం, GyaanSetu learning community on Telegram లో చేరండి.