ల్యాప్‌టాప్ మూసిన తర్వాత: ఇన్‌ఫ్రాస్ట్రక్చర్ AI ఏజెంట్లకు నిజంగా ఏమి కావాలి

గంటల తరబడి పనిచేసే AI agent కు నడవడానికి ఒక చోటు మాత్రమే సరిపోదు. పురోగతిని నిలిపి ఉంచే durable రికార్డ్, tools కు పరిమితమైన access, మరియు ఏమి జరిగిందో వ్యాపారానికి అనిశ్చితి మిగల్చకుండా ఆగిపోయే మార్గం కూడా కావాలి.

పని సంభాషణను దాటి కొనసాగుతుంది

ఒక కల్పిత తయారీ కంపెనీ డెలివరీ ఆలస్యాన్ని ఎదుర్కొంటోందని అనుకుందాం. ఒక పర్చేజింగ్ మేనేజర్ AI agent ను ప్రత్యామ్నాయ సరఫరాదారులను పరిశీలించమని, డెలివరీ తేదీలను పోల్చమని, మరుసటి ఉదయానికి ఒక సిఫారసును సిద్ధం చేయమని అడుగుతారు. మేనేజర్ ల్యాప్‌టాప్ మూసివేస్తారు. పని మాత్రం కొనసాగుతుంది.

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

Google అక్టోబర్ 8 నాటి Gemini at Work ప్రకటన గంటలు లేదా రోజుల పాటు persistent cloud execution ను, agents మధ్య సమన్వయాన్ని వివరిస్తుంది. ఇది ఎంటర్‌ప్రైజ్ సాఫ్ట్‌వేర్‌కు ఉపయోగకరమైన దిశను చూపుతుంది. అయితే ఒక ప్రకటన అనేది, ఒక నిర్దిష్ట workload విశ్వసనీయత లేదా ఖర్చు అవసరాలను తీరుస్తుందని చెప్పే ఆధారం కాదు.

అసలు ప్రశ్న ఆ అనుభవం కింద సంస్థకు ఏమి అవసరం అన్నదే. Article 1 agent సిఫారసుకూ, చర్య తీసుకునే అనుమతికీ మధ్య ఉన్న సరిహద్దును పరిశీలించింది. ఇక్కడ దృష్టి, ఆ అసైన్‌మెంట్ యంత్రాల మధ్య కదులుతూ, ఆమోదాల కోసం వేచి ఉంటూ, వనరులను వినియోగిస్తున్నప్పుడు దాన్ని నిర్వహించదగినదిగా ఉంచేది ఏమిటి అన్నదానిపై.

వ్యాపార పని జీవితకాలం, ప్రస్తుతం దానిపై పనిచేస్తున్న process జీవితకాలంపై ఆధారపడకూడదు.

నడుస్తున్న process అంటే durable పని కాదు

సరఫరాదారుల పరిశోధన డెలివరీ అంచనాలను సేకరించడంతో మొదలవుతుంది. ఒక గంట తర్వాత, దాన్ని నడుపుతున్న worker విఫలమవుతుంది. కొత్త worker ను ప్రారంభించడం వల్ల కంప్యూటింగ్ సామర్థ్యం తిరిగి వస్తుంది. కానీ ఏ సరఫరాదారులను తనిఖీ చేశారో, ఏ ఫలితాలు సేవ్ అయ్యాయో, ఏ చర్యను ఇప్పటికే అభ్యర్థించారో ఆ worker కు అది స్వయంగా చెప్పదు.

ఈ దృష్టాంతంలో, అప్లికేషన్ worker బయట ఒక durable task record ను నిర్వహించాలి. ఆ రికార్డ్‌కు స్థిరమైన గుర్తింపు, అసలు లక్ష్యం, ప్రస్తుత దశ, సేవ్ చేసిన ఫలితాలకు సూచనలు, మరియు స్పష్టమైన స్థితి ఉండాలి. అప్పుడు worker ఆ పనిలో ఒక భాగస్వామి మాత్రమే అవుతుంది, పని ఉనికిలో ఉన్న ఏకైక చోటు కాదు.

ఈ తేడా, browser డిస్కనెక్ట్ అయిన తర్వాత కొనసాగడాన్ని, process వైఫల్యం తర్వాత కోలుకోవడాన్ని వేరు చేస్తుంది. Microsoft long-running hosted-agent డాక్యుమెంటేషన్ background execution కూ, resilience కూ తేడా చూపుతుంది. దాని డాక్యుమెంట్ చేసిన recovery యంత్రాంగం process పోయిన తర్వాత ఒక handler లోకి మళ్లీ ప్రవేశించగలదు, అయితే అర్థవంతమైన పురోగతిని భద్రపరచే బాధ్యత అప్లికేషన్‌దే. వివరించిన hosted-agent సామర్థ్యాలు preview లో ఉన్నాయి, production కు అవి తగినవా అని అంచనా వేసేటప్పుడు ఇది ముఖ్యం.

ఆమోదిత సరఫరాదారుల శోధన పూర్తయి, విస్తృత శోధనకు అనుమతి ఇవ్వమని మేనేజర్ కోసం పరిశోధన వేచి ఉందని అనుకోండి. ఉపయోగకరమైన checkpoint ఆ సరిహద్దును, దాని వెనుక ఉన్న ఆధారాలను భద్రపరుస్తుంది. సంభాషణ transcript ను మాత్రమే సేవ్ చేస్తే, ఆమోదం అభ్యర్థించారా, అందిందా, లేక ఇంకా పెండింగ్‌లో ఉందా అని కోలుకుంటున్న అప్లికేషన్ ఊహించాల్సి వస్తుంది.

Durable workflow వ్యవస్థలు మరో యంత్రాంగాన్ని అందిస్తాయి. Temporal workflow డాక్యుమెంటేషన్ నమోదు చేసిన event history, replay ఉపయోగించి కోలుకోవడాన్ని వివరిస్తుంది. అది ఒక నిర్దిష్ట execution నమూనా, workflow కోడ్‌పై పరిమితులు కలిగినది. ప్రతి agent runtime ను అది వివరిస్తుందని, లేదా ఏకపక్ష model calls ను పునరుత్పత్తి చేయదగినవిగా చేస్తుందని భావించకూడదు.

కాబట్టి రూపకల్పన నిర్ణయం స్పష్టమైనది: పురోగతి ఏ భాగానికి చెందుతుంది, పూర్తైన దశలను అది ఎలా నమోదు చేస్తుంది, భర్తీ worker తదుపరి సురక్షిత సరిహద్దును ఎలా కనుగొంటుంది అనేది నిర్ణయించాలి. persistent అని వర్ణించిన సేవను కొనడం వల్ల, మొత్తం అప్లికేషన్‌కు ఈ ప్రశ్నలకు సమాధానం దొరకదు.

వేచి ఉండటాన్ని, పని చేయడాన్ని వేరు చేయండి

Agent రెండు సంభావ్య సరఫరాదారులను కనుగొంటుంది, కానీ ఒకరికి ఇంజనీరింగ్ సమీక్ష అవసరం. ఇప్పుడు పని ఉదయం వరకు వేచి ఉండవచ్చు. ఆ వేచి ఉండే సమయమంతా ఒక worker ను చురుకుగా నడుపుతూ ఉంచితే, పరిశోధన ముందుకు సాగకపోయినా, ఆ వేచి ఉండే కాలం కంప్యూటింగ్ ఖర్చులో భాగమవుతుంది.

ఈ అసైన్‌మెంట్‌కు తగిన రూపకల్పన, నిల్వ చేసిన పనిని దాన్ని ముందుకు నడిపే వనరుల నుండి వేరు చేస్తుంది. సమీక్ష వచ్చినప్పుడు ఒక durable event లేదా షెడ్యూల్ చేసిన తనిఖీ ఆ పనిని తిరిగి కొనసాగించడానికి అర్హమైనదిగా చేయగలదు. అప్పుడు ఒక worker సంబంధిత state ను లోడ్ చేసి కొనసాగిస్తుంది. పని ఇంకా ఆలోచిస్తోంది అనే అస్పష్ట సూచన బదులు, పని ఇంజనీరింగ్ కోసం వేచి ఉందని interface చూపాలి.

మినహాయింపులు ఉన్నాయి. Browser session, లోడ్ అయిన స్థానిక model, లేదా ప్రత్యేక tool ను మళ్లీ సృష్టించడం ఖరీదైనది కావచ్చు. ఆ వాతావరణాన్ని నిలిపి ఉంచడం విలువైనదే కావచ్చు. ప్రతి agent కు శాశ్వతంగా నడిచే యంత్రం కావాలనే ఊహ కాకుండా, కొలిచిన setup ఖర్చు, workload అవసరాలు ఆ నిర్ణయాన్ని నడిపించాలి.

సమాంతర పనికీ ఇదే క్రమశిక్షణ వర్తిస్తుంది. అనేక స్వతంత్ర సరఫరాదారులను ఒకేసారి తనిఖీ చేస్తే గడిచే సమయం తగ్గవచ్చు, కానీ అదనపు workers వల్ల downstream వ్యవస్థలకు ఒకేసారి వచ్చే అభ్యర్థనలు కూడా పెరుగుతాయి. సరఫరాదారు API ఇప్పటికే అడ్డంకి అయితే, workers సంఖ్యను పెంచడం వల్ల పోటీ మాత్రమే పెరుగుతుంది.

పర్చేజింగ్ పని కోసం, నేను concurrency పరిమితులను పని స్థాయిలో, షేర్డ్ సేవల స్థాయిలో రెండింటిలోనూ నిర్ణయిస్తాను. కేవలం మరిన్ని శాఖలను కనుగొన్నందుకే సరఫరాదారుల పరిశోధన అందుబాటులో ఉన్న సామర్థ్యమంతా వాడేయకూడదు. అత్యవసర పనికి queue లో చోటు కావాలి, తక్కువ ప్రాధాన్యత పనికి ఆలస్యంపై స్పష్టమైన విధానం కావాలి.

ఇది వ్యాపార పర్యవసానం ఉన్న ఇన్‌ఫ్రాస్ట్రక్చర్ ఎంపిక. ఎక్కువ సామర్థ్యం స్పందనను మెరుగుపరచవచ్చు, కానీ ప్రవేశ నియమాలు లేని సామర్థ్యం వల్ల ఎవరి పని సమయానికి పూర్తవుతుందో ముందుగా చెప్పడం కష్టమవుతుంది.

పనికి బడ్జెట్‌ను, ఆపే నియమాన్ని ఇవ్వండి

Agent సరఫరాదారులను పోల్చింది, కానీ ఆధారాలు అసంపూర్ణంగా ఉన్నాయి. అది మళ్లీ వెతకాలని నిర్ణయిస్తుంది, ప్రత్యామ్నాయాలను సమీక్షించమని మరో agent ను అడుగుతుంది, ఒక డాక్యుమెంట్ విశ్లేషణను పునరావృతం చేస్తుంది. ప్రతి దశ విడిగా చూస్తే సమర్థనీయంగా అనిపించవచ్చు. కలిపి చూస్తే, అవి ఎప్పటికీ నిర్ణయానికి చేరని పరిశోధనగా మారవచ్చు.

ఈ workload కోసం, బడ్జెట్ model tokens కంటే ఎక్కువ అంశాలను కవర్ చేయాలి. పని tool calls, తాత్కాలిక కంప్యూటింగ్ వాతావరణాలు, నిల్వ, మానవ సమీక్షను వినియోగించవచ్చు. చౌకైన model వల్ల మొత్తం ప్రక్రియ చౌక అవుతుందని చెప్పే ముందు, ఈ ఖర్చులన్నింటినీ కలిపి కొలవాలి.

Google ప్రకటన model routing ను, పరిమితి చేరినప్పుడు agent పనిని ఆపే project spend caps ను వివరిస్తుంది. ఇవి vendor వివరించిన నియంత్రణలు, ఈ పర్చేజింగ్ workflow లో పొదుపుపై స్వతంత్ర కొలత కావు. Project cap వల్ల అప్లికేషన్ స్థాయిలో ఒక ప్రశ్న కూడా మిగులుతుంది: ఈ నిర్దిష్ట అసైన్‌మెంట్ కొనసాగలేనప్పుడు దానికి ఏమి జరగాలి?

నేను పనికి గడిచే సమయం, పునరావృత ప్రయత్నాలు, అప్పగించిన పని, ఖర్చు కోసం పరిమితులను, స్పష్టమైన escalation మార్గంతో కలిపి ఇస్తాను. మిగిలిన బడ్జెట్ మరో ఉపయోగకరమైన శోధనకు సరిపోనప్పుడు, agent తన వద్ద ఉన్న ఆధారాలను తిరిగి ఇవ్వాలి, ఏది పరిష్కారం కాలేదో గుర్తించాలి, నిర్ణయం కోరాలి.

విరామానికి కూడా durable స్థితి కావాలి. బయటి అభ్యర్థన ఇంకా నడుస్తుంటే, interface అదే చెప్పాలి. Cancellation, అప్పటికే జరుగుతున్న ఆపరేషన్ల ఫలితాన్ని అప్లికేషన్ నిర్ధారిస్తున్నప్పుడు, ఇంకా అర్హమైన పనిని నిరోధించాలి. వాటిని వివరించడానికి అవసరమైన రికార్డ్‌ను అది తొలగించకూడదు.

అసౌకర్యకరమైన రాజీ ఏమిటంటే, పరిమితులు ఉన్న agent కోరుకున్న సమాధానం ఇవ్వకముందే ఆగిపోవచ్చు. అది సరైన ఫలితం కూడా కావచ్చు. ఆటోమేషన్ తన ఆధారాలు లేదా వనరుల పరిమితికి చేరిందో లేదో సంస్థకు తెలియాలి, పురోగతిలా కనిపించే కొనసాగుతున్న కార్యకలాపం కోసం చెల్లిస్తూ ఉండకూడదు.

యంత్రాలను మాత్రమే కాదు, అసైన్‌మెంట్‌ను నిర్వహించండి

మరుసటి ఉదయం, ప్రతి server dashboard పచ్చగా ఉండవచ్చు, కానీ సరఫరాదారుల పని ఇంకా నిలిచిపోయి ఉండవచ్చు. ఇన్‌ఫ్రాస్ట్రక్చర్ లభ్యత, భాగాలు చేరుకోదగినవిగా ఉన్నాయని ఆపరేషన్స్ బృందానికి చెబుతుంది. కానీ అసైన్‌మెంట్ ముందుకు సాగుతోందా, ఆమోదం కోసం వేచి ఉందా, లేక కొనసాగలేకపోతోందా అని పర్చేజింగ్ మేనేజర్‌కు చెప్పదు.

ఈ దృష్టాంతంలో, నేను పని చివరి అర్థవంతమైన పురోగతి, వేచి ఉండే కారణం, ప్రయత్నాలు, ఖర్చు, బయటి ఆపరేషన్ల సూచనలను ట్రాక్ చేస్తాను. సాంకేతిక logs ఇదే పని గుర్తింపుకు అనుసంధానం కావాలి, తద్వారా ఆపరేటర్ మేనేజర్ ప్రశ్న నుండి సంబంధిత ఆధారాలకు వెళ్లగలరు. ఆ రికార్డులకు access, సరఫరాదారు మరియు కాంట్రాక్ట్ సమాచారం సున్నితత్వాన్ని ప్రతిబింబించాలి.

వ్యవస్థపై ఆధారపడే ముందు, అర్థవంతమైన సరిహద్దుల వద్ద అంతరాయాలను పరీక్షించండి. Client ను డిస్కనెక్ట్ చేయండి. ఫలితం సేవ్ అయిన తర్వాత ఒక worker ను ఆపండి. ఆమోదాన్ని ఆలస్యం చేయండి. పని బడ్జెట్‌ను ఖాళీ చేయండి. Tool అభ్యర్థన పెండింగ్‌లో ఉండగా రద్దు చేయండి. ప్రతి పరీక్ష అర్థమయ్యే పని స్థితిని, నిర్వచించిన recovery లేదా escalation మార్గాన్ని ఇవ్వాలి.

అంటే ప్రతి అప్లికేషన్‌కు ప్రత్యేక agent platform కావాలని కాదు. చిన్న, పునరావృతమయ్యే డాక్యుమెంట్ శోధనకు సంప్రదాయ job queue, database సరిపోవచ్చు. ఆమోదాలు, బయటి ఆపరేషన్లతో కూడిన పర్చేజింగ్ పరిశోధనకు మరింత సంపన్నమైన orchestration అవసరం కావచ్చు. అదనపు యంత్రాంగానికి దాని స్వంత నిర్వహణ ఖర్చు ఉంటుంది, కాబట్టి సంక్లిష్టత వైఫల్య పర్యవసానాలను అనుసరించాలి.

అవకాశం ఏమిటంటే, పనిని సంభాషణను దాటి కొనసాగనివ్వడం, కానీ దాని పురోగతిని కనిపించకుండా చేయకుండా, వనరుల వినియోగాన్ని అపరిమితంగా వదలకుండా. నమ్మదగిన agent ఇన్‌ఫ్రాస్ట్రక్చర్, దాన్ని నడుపుతున్న worker అదృశ్యమైనప్పటికీ ఒక అసైన్‌మెంట్‌కు సంస్థ లెక్క చెప్పగలిగేలా చేస్తుంది.

మరింత లోతుగా

ప్రతి మూలాన్ని 9 October 2026న తెరిచి తనిఖీ చేశాం. ఉత్పత్తుల ప్రవర్తన, లభ్యత మారవచ్చు, కాబట్టి వాటిపై ఆధారపడే ముందు మళ్లీ చూడండి.

1. Google Cloud: Gemini at Work 2026. 2026 అక్టోబర్ 8న ప్రచురితం. Persistent execution, delegation, ఖర్చు నియంత్రణలను వివరించే vendor ప్రకటన. ఇది స్వతంత్ర విశ్వసనీయత మూల్యాంకనం కాదు.
2. Microsoft: Resilience for Long-Running Hosted Agents. Runtime recovery కూ, అప్లికేషన్ స్వంతం చేసుకునే పురోగతికీ మధ్య సరిహద్దును వివరిస్తుంది. డాక్యుమెంట్ చేసిన సామర్థ్యాలు preview లో ఉన్నాయి.
3. Temporal: Workflow Execution Overview. Temporal యొక్క durable execution నమూనాలో event history, replay ఎలా పనిచేస్తాయో వివరిస్తుంది.