2024 చివరిలో Anthropic Building Effective Agents ను ప్రచురించినప్పుడు, అది పరిశ్రమలో అరుదైన పని చేసింది: ఇంజనీర్లకు ఒక ఉమ్మడి పదజాలాన్ని అందించింది. ఆర్టిఫిషియల్ జనరల్ ఇంటెలిజెన్స్ గురించి మరొక మేనిఫెస్టో ఇవ్వడానికి బదులుగా, ఈ గైడ్ LLM సిస్టమ్లను రూపొందించడానికి ఆరు స్పష్టమైన పద్ధతులను (patterns) అందించింది. ఏడాదిన్నర తర్వాత, అంటే 2026లో, ఈ రంగం పూర్తిగా మారిపోయింది. Model Context Protocol ఒక సార్వత్రిక ప్రమాణంగా మారింది. Claude కొత్త సామర్థ్యాలను పొందింది. ప్రస్తుతం చాలా సంస్థలు కనీసం ఒక ఏజెంట్ను ప్రొడక్షన్లో వాడుతున్నాయి. ఈ నేపథ్యంలో, ఆ ఆరు పద్ధతులు ఇప్పటికీ ముఖ్యమేనా, లేదా అవి గత ఏడాది మోడల్ వెయిట్స్ (model weights) పక్కన ఆర్కైవ్లో ఉండిపోవాలా అని అడగడం సమంజసమే.
తెలుసుకోవడానికి నేను ఒక సైడ్ రిపోజిటరీలో లోకల్ మోడల్తో ఆ ఆరు పద్ధతులను పరీక్షించాను. సమాధానం 'అవును'. అవి ఇప్పటికీ నిలబడుతున్నాయి. కానీ అవి మార్చలేని నియమాలు కాబట్టి కాదు. గత పద్దెనిమిది నెలల ప్రొడక్షన్ అనుభవం ఈ ఫ్రేమ్వర్క్ యొక్క ప్రధాన తర్కాన్ని (core logic) ధృవీకరించింది కాబట్టే అవి నిలబడుతున్నాయి.
ఆ ఫ్రేమ్వర్క్ మనకు నిజంగా ఏమి అందించింది
ఆ ఆరు పద్ధతులను ఖచ్చితంగా గుర్తుంచుకోవాలి: Prompt Chaining, Routing, Parallelization, Evaluator-Optimizer, Orchestrator-Workers, మరియు Autonomous Agents. చివరిది ప్రాథమికంగా ఒక లూప్, ఇందులో మోడల్ ఒక నిబంధన నెరవేరే వరకు ప్లాన్ చేస్తుంది, పనిచేస్తుంది, గమనిస్తుంది మరియు మళ్ళీ మళ్ళీ చేస్తుంది.
ఈ గైడ్ రాకముందే చాలా మంది ఇంజనీర్లు ప్రాంప్ట్లను చైన్ చేయడం లేదా వర్కర్ థ్రెడ్లకు పనులను అప్పగించడం చేస్తున్నారు. Anthropic అందించింది ఒక వర్గీకరణను (taxonomy). ఒకరి దృష్టిలో "agent" అయినది, మరొకరి దృష్టిలో "workflow," మరియు మూడవ వ్యక్తి దృష్టిలో "multi-step tool call." ఈ గైడ్ ఆ గందరగోళాన్ని స్పష్టమైన సరిహద్దులతో కూడిన వర్గీకరణలుగా విభజించింది. దీనివల్ల ఒకరినొకరు అర్థం చేసుకోలేక పోకుండా, వివిధ అంశాల మధ్య ఉన్న లాభనష్టాల (trade-offs) గురించి చర్చించడం సాధ్యమైంది. అతిశయోక్తులతో నిండిన ఈ రంగంలో, స్పష్టమైన భాష ఒక రకమైన మౌలిక సదుపాయం (infrastructure) వంటిది.
పరిశ్రమ దాని చుట్టూ కాకుండా, దానిపైనే నిర్మించుకుంది
2026 నాటికి, టీమ్లు సిస్టమ్లను ఎలా డిజైన్ చేయాలనే దానిలో ఈ వర్గాలు అంతర్భాగమయ్యాయి. Anthropic ఇప్పటికీ వాటిని తమ అకాడమీ కోర్సులలో బోధిస్తోంది. పరిశోధనా పత్రాలు మరియు ఇంజనీరింగ్ బ్లాగులు కొత్త ఆర్కిటెక్చర్లను వివరించడానికి ఇప్పటికీ అదే ఆరు వర్గాలను ఉపయోగిస్తున్నాయి. ప్రతి త్రైమాసికంలోనూ తన టెక్నాలజీ స్టాక్ను మార్చుకునే ఈ రంగంలో, ఇటువంటి దీర్ఘకాలికత అసాధారణం.
దీనికి కారణం సరళమైనదే. పరిశ్రమ ఆ ఫ్రేమ్వర్క్ను భర్తీ చేయలేదు. దానిపైనే కొత్త వాటిని నిర్మించుకుంది. MCP మరియు కొత్త Agent Skills ప్రమాణాలు వంటి కొత్త సాధనాలు ప్లంబింగ్ (plumbing) లాగా పనిచేస్తాయి. అవి మోడల్ను డేటాబేస్కు అనుసంధానించడం, ఒక టూల్ను అందుబాటులోకి తీసుకురావడం లేదా స్టేట్ను (state) నిర్వహించడం సులభతరం చేస్తాయి. కానీ ఒక ఆర్కెస్ట్రేటర్ (orchestrator) బదులుగా రూటర్ (router) ను ఎప్పుడు ఉపయోగించాలనే తర్కాన్ని అవి మార్చవు. మెరుగైన పైపు అనేది ఇంటి ప్లాన్ను మార్చదు.
2026 నాటి ప్రొడక్షన్ డేటా దీనిని ధృవీకరిస్తోంది. అత్యంత సాధారణ డిప్లాయ్మెంట్ పద్ధతి ఇప్పటికీ మానవ సమీక్షతో కూడిన సింగిల్ టూల్-యూజ్ కాల్ (single tool-use call). రెండవ అత్యంత సాధారణ పద్ధతి, ఒక వ్యక్తికి సరిగ్గా ఒకసారి పనులను అప్పగించే (handoff) మల్టీ-స్టెప్ వర్క్ఫ్లో. ఈ రెండూ Prompt Chaining మరియు Routing నుండి వచ్చినవే. లైవ్ సిస్టమ్స్లో పూర్తి స్వయంప్రతిపత్తి కలిగిన లూప్లు (Full autonomous loops) కేవలం మినహాయింపులుగా మాత్రమే ఉన్నాయి, అవి సాధారణ నియమం కాదు.
సంయమనం మార్కెట్లో విజయం సాధించింది
అసలు గైడ్ ఇచ్చిన ఉత్తమ సలహా, 2024లో తరచుగా విస్మరించబడిన సలహా కూడా: పనిచేసే అత్యంత సరళమైన పద్ధతిని ఉపయోగించండి. ఒక హార్డ్కోడెడ్ మార్గం (hardcoded path) ద్వారా పని పూర్తవుతుంది అనుకుంటే, పూర్తి స్వయంప్రతిపత్తి కలిగిన ఏజెంట్ను డిప్లాయ్ చేయకండి.
మార్కెట్ చివరికి దీనిని అర్థం చేసుకుంది. చాలా ఏజెంట్ పైలట్ ప్రాజెక్టులు ఇప్పటికీ విఫలమవుతున్నాయి, మరియు అవి ఊహించదగిన ఒకే కారణం వల్ల విఫలమవుతున్నాయి. నిర్ణయ ప్రక్రియను (decision boundary) ఎవరూ గుర్తించలేనంత వరకు టీమ్లు ఒకదానిపై ఒకటి అబ్స్ట్రాక్షన్లను (abstraction) పేరుకుపోస్తారు. సిస్టమ్ తప్పుదారి పట్టినప్పుడు, డీబగ్గింగ్ చేయడం పురావస్తు శాస్త్రంలా (archaeology) క్లిష్టంగా మారుతుంది. ప్రొడక్షన్లో విజయం సాధించిన కంపెనీలు సంయమనాన్ని ప్రదర్శించినవే. అవి సింగిల్-టర్న్ టూల్ యూస్ను ప్రాధాన్యతగా తీసుకున్నాయి. సింగిల్ ప్రాంప్ట్ సరిగ్గా పనిచేయకపోతేనే అవి రూటింగ్ లేయర్ను జోడించాయి. అవి స్వయంప్రతిపత్తిని (autonomy) ఒక గొప్ప ఫీచర్గా కాకుండా, సమర్థించుకోవాల్సిన ఒక బాధ్యతగా (liability) పరిగణించాయి.
ఇది ఆశయానికి వ్యతిరేకమైన వాదన కాదు. ఇది కాంపోజిషన్ (composition) కోసం చేసే వాదన. మెనూలో ఉన్న అత్యంత సంక్లిష్టమైన ఎంపికను వెంటనే ఎంచుకోవడం కంటే, వాటిని ఆలోచించి కలిపి ఉపయోగించినప్పుడు ఈ పద్ధతులు ఉత్తమంగా పనిచేస్తాయి.
లోపాలు ఎక్కడ బయటపడటం ప్రారంభిస్తాయి
ఈ ఫ్రేమ్వర్క్ అన్ని సమస్యలకు పరిష్కారం కాదు. మీరు ప్రోటోటైప్ దశ నుండి బయటకు రాగానే కొన్ని కఠినమైన పరిమితులు ఎదురవుతాయి.
అధిక ఫ్రీక్వెన్సీ, తక్కువ ఖర్చుతో కూడిన పనుల కోసం, డిటర్మినిస్టిక్ కోడ్ (deterministic code) ఇప్పటికీ ఉత్తమమైనది. pandas మిల్లీసెకన్లలో హాలూసినేషన్ (hallucination) లేకుండా చేయగలిగినప్పుడు, ఒక LLM ఒక CSV కాలమ్ను నార్మలైజ్ చేయకూడదు. మీరు స్పష్టమైన మూల్యాంకన లక్ష్యాన్ని (evaluation goal) నిర్వచించలేకపోతే, ఆటోనమస్ లూప్స్ (autonomous loops) ను నివారించండి. స్పష్టమైన స్టాపింగ్ కండిషన్ (stopping condition) లేకపోతే, ఆగిపోవడానికి ఒక కారణాన్ని సృష్టించుకునే వరకు మోడల్ పునరావృతం (iterate) అవుతూనే ఉంటుంది. ఎక్స్టర్నల్ గ్రౌండింగ్ (external grounding) అవసరమయ్యే కీలకమైన నిర్ణయాల కోసం, కేవలం మోడల్ యొక్క అంతర్గత జ్ఞానంపై మాత్రమే ఆధారపడకండి. మరియు డేటా రిట్రీవల్లో (data retrieval) వచ్చే అడ్డంకులను (bottlenecks) గమనించండి. మీ డేటాబేస్ నెమ్మదిగా ఉన్నా లేదా మీ కాంటెక్స్ట్ విండో (context window) అనవసరమైన చంక్స్తో నిండిపోయినా, వెక్టర్ సెర్చ్ (vector search) లేదా ఎక్స్టర్నల్ APIs పై ఆధారపడే ఏ ప్యాటర్న్ అయినా ఆగిపోయే ప్రమాదం ఉంది.
ఇవి కేవలం ఊహాజనిత ఎడ్జ్ కేసులు (edge cases) మాత్రమే కాదు. ఇవి ఒక పని చేసే డెమోను, వారాంతం వరకు కూడా నిలబడగలిగే సిస్టమ్ను వేరు చేసే పరిమితులు.
ఒక కఠినమైన తనిఖీ మరియు తప్పుడు వైఫల్యం
నా టెస్ట్ రిపోజిటరీని నిర్మిస్తున్నప్పుడు ఈ ఫ్రేమ్వర్క్ యొక్క ఆచరణాత్మక విలువను నేను తెలుసుకున్నాను. నేను Evaluator-Optimizer ప్యాటర్న్ను అమలు చేస్తున్నాను. నా ఎవాల్యుయేటర్ (evaluator) మొదట మోడల్ అవుట్పుట్లో నిర్దిష్ట కీవర్డ్ల కోసం స్కాన్ చేసే ఒక హార్డ్కోడెడ్ regex గా ప్రారంభమైంది. మోడల్ సరైన, తార్కికమైన సమాధానాన్ని ఇచ్చింది, కానీ నేను వెతుకుతున్న ఖచ్చితమైన పదాలకు బదులుగా పర్యాయపదాలను (synonyms) ఉపయోగించింది. ఎవాల్యుయేటర్ దానిని వైఫల్యంగా గుర్తించింది.
మోడల్ చెప్పింది నిజం. నా తనిఖీ చాలా కఠినంగా ఉంది.
దీనిని సరిదిద్దడానికి కేవలం పదాల జాబితాను పెంచడం కంటే ఎక్కువ అవసరమైంది. నేను ఎవాల్యుయేటర్ను స్వయంగా LLM-ఆధారిత తీర్పుగా మార్చాను. దీనివల్ల అదనపు టోకెన్లు మరియు మరికొన్ని మిల్లీసెకన్లు ఖర్చయ్యాయి, కానీ ఇది మూల్యాంకనాన్ని సరైన అబ్స్ట్రాక్షన్ (abstraction) స్థాయికి తీసుకువచ్చింది. ప్యాటర్న్自体 (pattern itself) సరైనదే. నేను ఆ పని కోసం తప్పుడు ఇంప్లిమెంటేషన్ను ఎంచుకున్నాను. ఈ ఫ్రేమ్వర్క్ సరిగ్గా ఇటువంటి తప్పులను నివారించడానికే ఉద్దేశించబడింది. కొన్ని మూల్యాంకనాలకు కోడ్ అవసరం. మరికొన్నింటికి మోడల్ అవసరం. ఏది దేనికి అవసరమో తెలుసుకోవడమే దీని ముఖ్య ఉద్దేశ్యం.
వాటిని ఇప్పుడు ఎలా ఉపయోగించాలి
ఈ ఆరు ప్యాటర్న్లను ఒక ప్రారంభ బిందువుగా పరిగణించండి, వీటిని ఖచ్చితమైన నియమాలుగా భావించకండి. ఒకే ఒక ప్రాంప్ట్తో ప్రారంభించండి. ఇన్పుట్ రకాలను బట్టి నాణ్యత స్థిరంగా లేకపోతే, వివిధ అభ్యర్థనలను ప్రత్యేక ప్రాంప్ట్లకు పంపడానికి ఒక రూటింగ్ లేయర్ను (routing layer) జోడించండి. ఒక నిర్ణయం తీసుకునే ముందు మీకు బహుళ స్వతంత్ర దృక్పథాలు కావాలంటే, Parallelization ఉపయోగించండి. పని పెద్దదిగా మరియు విభజించదగినదిగా ఉంటే, Orchestrator-Workers ప్రయత్నించండి. సమస్య యొక్క పరిధి ముందుగా మ్యాప్ చేయడానికి వీలులేనంత విస్తృతంగా ఉన్నప్పుడు మరియు మీకు నమ్మకమైన