टिकाऊ AI एजेंटों को वर्कफ़्लो चाहिए, सिर्फ़ चैट लूप नहीं

एक एजेंट डेमो एक लूप होता है:

text1 line

prompt -> model -> tool -> model -> answer

प्रोडक्शन एजेंट लंबे समय तक चलने वाला वितरित वर्कफ़्लो है। उसमें मॉडल की calls का परिणाम निश्चित नहीं होता, tools बाहरी बदलाव करते हैं, कोई व्यक्ति कई घंटे बाद काम मंज़ूर कर सकता है, credentials की अवधि समाप्त हो सकती है, deployment कोड बदल सकता है और कोई भी process “बदलाव हो गया” तथा “state दर्ज हुई” के बीच crash कर सकता है।

आर्किटेक्चर का मुख्य सवाल यह नहीं है कि कौन-सा framework tools को call कर सकता है। सवाल है: कौन-सी टिकाऊ state सिस्टम को हर कदम समझाने, फिर से शुरू करने और सुरक्षित ढंग से उसके प्रभाव की भरपाई करने देती है?

तर्क और execution को अलग रखें

मॉडल को अगली कार्रवाई सुझाने वाला planner मानें, पूरी हो चुकी कार्रवाइयों का प्रामाणिक रिकॉर्ड नहीं।

Architecture / inspect the boundariesReasoning proposes. Durable execution decides.

Read left to right on the top row, then right to left below. Persist intent before the external effect; record its evidence afterward. Retrying the effect still requires a stable idempotency key.

Pan, zoom, and select a node. Layout changes stay in your browser.

Read the components and connections

Goal: A durable run ID ties the request, budget, and evidence together.
Model planner: Record model output. Do not repeat model calls inside deterministic replay.
Policy gate: Check permission, remaining budget, and any required human approval before execution.
Durable intent: Persist the proposed operation and stable operation ID before invoking the tool.
Tool effect: A timeout is ambiguous. Retry under the same identity; do not assume the first attempt failed.
Recorded outcome: Persist the outcome before planning again. The target system must enforce effect deduplication.

Goal → Model planner: propose
Model planner → Policy gate: authorize
Policy gate → Durable intent: persist
Durable intent → Tool effect: execute
Tool effect → Recorded outcome: record

text7 lines

goal
  -> planner proposes action
  -> policy checks authority and budget
  -> workflow records intent
  -> tool executor performs effect
  -> workflow records evidence
  -> planner receives normalized result

जीवनचक्र की state का नियंत्रण वर्कफ़्लो के पास है। केवल किसी tool को ईमेल भेजने के लिए कह देने से मॉडल यह तय नहीं कर सकता कि ईमेल भेज दिया गया है।

न्यूनतम state model ऐसा हो सकता है:

ts9 lines

type RunState = {
  runId: string
  goal: string
  status: 'running' | 'waiting_approval' | 'completed' | 'failed'
  policyVersion: number
  modelPolicy: { provider: string; model: string; maxTokens: number }
  budget: { tokens: number; toolCalls: number; moneyCents: number }
  steps: StepEvidence[]
}

Prompts और मॉडल के outputs को स्पष्ट गोपनीयता नीति के अनुसार रखें। कई प्रणालियों में हर पूरी बातचीत को अनिश्चितकाल तक रखने की तुलना में structured decisions, hashes, संवेदनशील हिस्से हटाए हुए arguments और tool के प्रमाण रखना अधिक सुरक्षित होता है।

Durable execution विफलता का मॉडल बदलता है

Temporal जैसी वर्कफ़्लो प्रणालियाँ घटनाओं का इतिहास सुरक्षित रखती हैं और worker के विफल होने पर उससे वर्कफ़्लो की state दोबारा बनाती हैं। महत्वपूर्ण गुण यह नहीं है कि “process हमेशा चलता रहे।” गुण यह है कि orchestration अधूरी बदली हुई database row से अनुमान लगाने के बजाय दर्ज इतिहास से फिर चल सके।

वर्कफ़्लो का logic deterministic रखें। Network calls, मॉडल को बुलाना, घड़ियाँ, randomness और बाहरी बदलाव activities में रखें:

text6 lines

workflow (replayable decisions)
  activity: call model
  activity: fetch account
  wait: human approval signal
  activity: update CRM
  activity: send notification

यदि worker बाहरी बदलाव करने के बाद, लेकिन completion दर्ज करने से पहले crash हो जाए, तो activity एक से अधिक बार चल सकती है। इसलिए durable orchestration आइडेमपोटेंसी की आवश्यकता खत्म नहीं करता; वह बताता है कि उसकी आवश्यकता ठीक कहाँ है।

हर प्रभाव को स्थिर पहचान दें

Tool calls के लिए operation ID वर्कफ़्लो की टिकाऊ state से निकलनी चाहिए, हर प्रयास में नई नहीं बननी चाहिए:

text1 line

operation_id = run_id + step_number + tool_contract_version

इसे downstream प्रणालियों तक idempotency key के रूप में पहुँचाएँ। Request का fingerprint और परिणाम सुरक्षित रखें:

sql3 lines

INSERT INTO tool_effects(operation_id, tool, request_hash, status)
VALUES ($1, $2, $3, 'started')
ON CONFLICT (operation_id) DO NOTHING;

यदि बाहरी tool आइडेमपोटेंसी नहीं देता, तो अस्पष्ट परिणामों के लिए नीति तय करें:

प्रमाण खोजने के लिए दूर की प्रणाली से पूछें;
इंसान के द्वारा मिलान और समाधान आवश्यक करें;
बदलाव को append-only रखें और उसकी भरपाई संभव बनाएँ;
या automatic retry रोक दें।

“Tool को फिर चला दो” हर परिस्थिति के लिए recovery policy नहीं है।

Authorization execution के समय होना चाहिए

मॉडल के सुझाए arguments अविश्वसनीय input हैं। Tool descriptions और खोजकर लाए गए दस्तावेज़ भी अविश्वसनीय हैं, क्योंकि उनमें prompt injection हो सकता है।

Execution के ठीक पहले वास्तविक कार्रवाई की अनुमति जाँचें:

text7 lines

principal: sales_rep_17
tenant: acme
tool: crm.update_contact
resource: contact/882
fields: [next_follow_up]
reason: approved campaign workflow
policy_version: 42

Model Context Protocol का authorization specification संरक्षित servers के लिए OAuth-आधारित तरीके इस्तेमाल करता है और resource server का व्यवहार स्पष्ट करता है। प्रोटोकॉल चाहे जो हो, मॉडल को सामान्य उपयोग वाला bearer token न दें। Credentials executor के पास होने चाहिए; उसे उन्हें भरोसेमंद service identity से बाँधना चाहिए और केवल policy से छनकर आई क्षमताएँ उपलब्ध करानी चाहिए।

लंबे इंतज़ार के बाद अनुमति फिर जाँचें। कल किसी कार्रवाई को मंज़ूर करने वाले व्यक्ति की पहुँच आज हट चुकी हो सकती है; ग्राहक integration रद्द कर चुका हो सकता है; policy बदल सकती है।

मानवीय अनुमोदन भी टिकाऊ state है

अनुमोदन को ऐसे HTTP request की तरह लागू न करें जो किसी button के क्लिक होने का इंतज़ार करता रहे। State transition दर्ज करें:

text3 lines

proposed -> awaiting_approval -> approved -> executing -> evidenced
                        \-> rejected
                        \-> expired

अनुमोदन माँगते समय असली प्रभाव दिखना चाहिए: प्राप्तकर्ता, राशि, बदले जाने वाले fields, सिस्टम से बाहर जाने वाला डेटा और लागत। सिर्फ़ “जारी रखें” की अनुमति लेना सूचित सहमति नहीं है।

अनुमोदन को प्रस्तावित कार्रवाई के hash से बाँधें। यदि अनुमोदन के बाद planner arguments बदल दे, तो नया निर्णय माँगें। समाप्ति का समय तय करें और दर्ज करें कि किसने, किस भूमिका और policy version के तहत अनुमति दी।

चल रहे runs को बिगाड़े बिना वर्कफ़्लो version करें

एजेंट runs किसी deployment से अधिक समय तक चल सकते हैं। नया prompt, tool schema या branching rule replay का रास्ता बदल सकता है या पुरानी state का अर्थ बदल सकता है।

कम-से-कम इनका version रखें:

वर्कफ़्लो के code paths;
system prompt और model policy;
tool contracts;
authorization policy;
structured output schemas;
मूल्यांकन के मानदंड।

मौजूदा runs का व्यवहार compatible रहना चाहिए या उन्हें स्पष्ट migration से गुज़रना चाहिए। “Deploy कर दो और आशा करो कि कोई run दो steps के बीच न हो”—यह release strategy नहीं है।

Temporal replay और versioning की सीमाएँ इसलिए बताता है क्योंकि nondeterministic code changes state को दोबारा बनाने की प्रक्रिया तोड़ सकते हैं। यही समस्या अपने बनाए orchestrators में भी होती है; recovery विफल होने तक बस कम दिखाई देती है।

लूप घटना बनने से पहले उनका बजट तय करें

हर बढ़ सकने वाली मात्रा की सीमा रखें:

मॉडल के tokens और calls;
वास्तविक बीता हुआ समय;
हर वर्ग की tool calls;
बाहरी खर्च;
retrieval से आए bytes;
state बदले बिना बार-बार planning;
सौंपे गए child agents;
अनुमोदन का इंतज़ार।

चक्रों को उनके अर्थ से पहचानें। अलग शब्दों में लिखी तीन योजनाएँ यदि उसी tool को उन्हीं arguments से बुलाती हैं, तो वे एक ही अटके हुए लूप का हिस्सा हैं।

text2 lines

if same_effect_fingerprint >= 2 and no_new_evidence:
    stop(reason="non-progressing loop")

बजट planner को दिखना चाहिए, लेकिन उसे लागू करने की ज़िम्मेदारी planner के बाहर होनी चाहिए।

प्रमाण देखें, chain-of-thought नहीं

एजेंट चलाने के लिए उसके निजी reasoning traces आवश्यक नहीं हैं। आवश्यक हैं structured प्रमाण:

run और step IDs;
model और prompt policy versions;
input/output token counts;
प्रस्तावित tool और normalized arguments;
policy decision और reason code;
अनुमोदन की state;
tool latency, retries और परिणाम;
बाहरी प्रभाव की पहचान;
अंतिम परिणाम और मूल्यांकन।

OpenTelemetry की generative-AI semantic conventions मॉडल और एजेंट telemetry के लिए विकसित होती शब्दावली देती हैं। इन्हें बदलती conventions समझें और संवेदनशील सामग्री रिकॉर्ड करना opt-in रखें।

CTO समीक्षा के प्रश्न

कौन-सा टिकाऊ रिकॉर्ड साबित करता है कि हर बाहरी प्रभाव हुआ?
कौन-से operations एक से अधिक बार चल सकते हैं और उनके duplicates कैसे रोके जाते हैं?
क्या execution के समय वास्तविक कार्रवाई के लिए authorization जाँचा जाता है?
क्या व्यक्ति सटीक प्रभाव देखकर उसे मंज़ूर कर सकता है?
क्या चल रहे runs deployment और policy change के बाद भी सुरक्षित चल सकते हैं?
आगे न बढ़ने वाले लूप को क्या रोकता है?
क्या अनावश्यक निजी reasoning रखे बिना किसी incident को दोबारा समझा जा सकता है?

भरोसेमंद एजेंट वह नहीं है जिसका लूप सबसे चालाक हो। वह है जिसकी प्रगति टिकाऊ हो, अधिकार सीमित हों, प्रभावों का प्रमाण हो और जिसकी विफलता रहस्य छोड़ने के बजाय ऐसी state छोड़े जिससे उबरा जा सके।

टिकाऊ AI एजेंटों को वर्कफ़्लो चाहिए, सिर्फ़ चैट लूप नहीं

तर्क और execution को अलग रखें #

Durable execution विफलता का मॉडल बदलता है #

हर प्रभाव को स्थिर पहचान दें #

Authorization execution के समय होना चाहिए #

मानवीय अनुमोदन भी टिकाऊ state है #

चल रहे runs को बिगाड़े बिना वर्कफ़्लो version करें #

लूप घटना बनने से पहले उनका बजट तय करें #

प्रमाण देखें, chain-of-thought नहीं #

CTO समीक्षा के प्रश्न #

संदर्भ #

यह लेख साझा करें