AI agent handoff: रातभर सक्रिय sessions पर नियंत्रण

AI agent handoff तब विफल होता है, जब outgoing engineer कस्टडी सौंपने के बजाय सिर्फ एक कहानी सुनाता है। «Agent अभी भी deploy पर काम कर रहा है» कहने से अगले व्यक्ति को लगभग कुछ पता नहीं चलता। उसे जानना होगा कि किस प्रोसेस के पास अभी अधिकार है, वह किन चीजों तक पहुंच सकता है, किस अनुरोध में मानव की मंजूरी बाकी है, सबूत कहां रखा है और काम को रोकने या recover करने का तरीका क्या है।

मुश्किल यह है कि terminal पर कोई नजर न रख रहा हो, तब भी agent काम कर सकता है। उसके पास live SSH connection, durable background task, environment में मौजूद token, laptop पर approval prompt का इंतजार या आंशिक remote change हो सकता है, जो बाद में दिखाई देगा। अच्छा handoff इन सबको सीमित और स्पष्ट operational state में बदल देता है। खराब handoff अनिश्चितता आगे भेजता है और उसे continuity कहता है।

Handoff के लिए chat summary नहीं, custody record चाहिए

उपयोगी handoff में authority और state को अलग-अलग दर्ज करें, क्योंकि दोनों अलग तरीके से विफल होते हैं। State बताती है कि agent ने क्या किया है और आगे क्या करने वाला है। Authority बताती है कि agent अभी भी क्या कर सकता है। Teams अक्सर पहली चीज दर्ज करती हैं और दूसरी छोड़ देती हैं। इसी तरह harmless दिखने वाला continuation बिना समीक्षा के production write बन जाता है।

Record तब लिखें, जब outgoing engineer अभी मशीन की जांच कर सकता हो और फैसलों की वजह समझा सकता हो। किसी page से कोई जागने के बाद इसे याददाश्त से दोबारा न बनाएं। सटीक identifiers वाला छोटा document, आत्मविश्वास से भरी लंबी कहानी से बेहतर होता है।

हर active run के लिए ये बातें दर्ज करें:

• Agent process ID, session ID, working directory और start time।
• Shift छोड़ रहे human owner, जिम्मेदारी लेने वाले human owner और जिम्मेदारी बदलने का समय।
• Intended task, आखिरी पूरी हुई external action और अगली प्रस्तावित external action।
• हर reachable target, जैसे host alias, API base URL, repository, ticket या deployment environment।
• Stop command, recovery command और evidence location।

जब आप साफ-साफ लिख सकते हैं कि «process 4182 approved session S-204 के जरिए staging deployment API को call कर सकता है», तब «has staging access» न लिखें। Broad labels उस जानकारी को छिपा देते हैं, जिससे successor यह तय कर सकता है कि काम सुरक्षित रूप से जारी रखा जा सकता है या नहीं।

Custody record में हर run के लिए स्पष्ट disposition भी होना चाहिए: continue, pause, cancel या inspect before action। «Monitor» कोई disposition नहीं है। इससे अगले engineer को खुद अनुमान लगाना पड़ता है कि उसे हस्तक्षेप करने की अनुमति है या नहीं।

Handoff तभी पूरा होता है, जब incoming engineer record स्वीकार कर ले और live process खुद ढूंढ सके। Busy channel में भेजा गया message delivery है, transfer नहीं। अगर कोई custody स्वीकार नहीं करता, तो outgoing engineer को जहां संभव हो, काम pause करना चाहिए या external authority revoke करनी चाहिए।

Owner बदलने से पहले live authority खोजें

जिस session का पता ही नहीं है, उसका control ट्रांसफर नहीं किया जा सकता। पहले local process tree देखें, फिर connections, environment exposure और immediate terminal के बाहर बनाए गए jobs की जांच करें। Agent interface task को complete बता सकता है, जबकि child process, shell multiplexer pane या SSH master connection अब भी सक्रिय हो।

macOS या Linux पर सरल commands से शुरुआत करें और उनका output handoff evidence में सुरक्षित रखें। Example identifiers की जगह वास्तविक agent process या account इस्तेमाल करें।

ps -axo pid,ppid,user,lstart,command | grep -E '[a]gent|[c]laude|[m]cp'
pgrep -P 4182 -alf
lsof -nP -p 4182

पहली command इस तरह की process row दिखाएगी:

4182  901 alex  Tue Mar 18 22:14:07 2025  agent-runner --task deploy-api

दूसरी child processes दिखाती है। तीसरी open files और network endpoints दिखाती है। Inherited shells, open Unix sockets, TCP connections, local credential files और approval helpers तक जाने वाले pipes खोजें। Secrets वाला command output ticket में paste न करें। इसे approved incident record में सुरक्षित रखें या संवेदनशील value redact करें, लेकिन file path और connection details बनाए रखें।

SSH की अलग से जांच जरूरी है, क्योंकि उसका connection model किसी एक command से अधिक समय तक चल सकता है। OpenSSH ssh_config manual बताता है कि ControlPersist शुरुआती client के बाहर निकलने के बाद भी master connection को खुला रख सकता है। बार-बार commands चलाने में यह समय बचाता है। Handoff के दौरान इसका अर्थ है कि «command पूरा हो गया» कहने से यह साबित नहीं होता कि remote access खत्म हो गया।

Master sockets और forwarding processes जांचें:

ps -axo pid,ppid,command | grep '[s]sh'
find ~/.ssh -type s -name '*control*' -print
lsof -nP -iTCP -sTCP:ESTABLISHED | grep '[s]sh'

फिर «क्या यह connected है?» से ज्यादा महत्वपूर्ण सवाल पूछें: remote side अभी क्या execute कर सकती है? Local client गायब होने के बाद भी remote build चल सकता है। Deployment command एक बदलाव लागू करके अगली सूचना देने से पहले विफल हो सकता है। Resume करना है या नहीं तय करने से पहले remote job identifier, deployment record या service status सुरक्षित करें।

Open port को malicious activity न मानें। लेकिन हर ऐसे खुले channel को, जिसकी वजह स्पष्ट नहीं है, unresolved authority मानें। Incoming engineer को या तो उसे समझना, बंद करना या escalate करना होगा।

Pending approvals के लिए परिणाम और expiry तय करें

Pending approval प्रस्तावित कार्रवाई है, outgoing engineer की बनाई हुई कोई reservation नहीं। Shift संभालने वाले व्यक्ति को कभी ऐसा approval prompt नहीं मिलना चाहिए जिसके साथ सिर्फ «दिखे तो इसे click कर देना» लिखा हो। यह वाक्य उससे संदर्भ के बिना किसी फैसले को मंजूरी देने को कहता है।

हर pending request के साथ पांच बातें जोड़ें:

1. Exact action, जिसमें method और target शामिल हों। «Update service» पर्याप्त नहीं है। «production-api के deployment endpoint पर POST» से शुरुआत करने के लिए स्पष्ट target मिलता है।
2. कार्रवाई की वजह और वह condition, जिसके कारण इसकी जरूरत पड़ी।
3. अपेक्षित परिणाम और उसे confirm करने वाला observable evidence।
4. वह deadline, जिसके बाद request expire होनी चाहिए और फिर से generate करनी होगी।
5. Approval या rejection की अनुमति वाले व्यक्ति का नाम।

इन विवरणों के बिना approval expire होना चाहिए। किसी request को दोबारा जारी करना blind write से recover करने की तुलना में सस्ता है। शांत shift के दौरान यह नियम जरूरत से ज्यादा सावधानी जैसा लग सकता है। लेकिन approval card के laptop lock, reconnect और incident scope बदलने के बाद भी मौजूद रहने पर इसकी जरूरत साफ दिखती है।

Handoff के बहाने approval authority न बढ़ाएं। अगर outgoing engineer staging change approve कर सकता था, तो इसका मतलब यह नहीं कि incoming engineer उसके production version को approve कर सकता है। Request के पड़े रहने के दौरान scope बदल सकता है। Human action से पहले target, payload और current incident state फिर से जांचें।

Timing भी महत्वपूर्ण है। अगर कोई tool agent के request बनाने के काफी देर बाद action के लिए prompt दे सकता है, तो request design में expiry शामिल करें। Stale approval ऐसे system पर काम कर सकता है जो recover, fail over या manually बदल चुका हो। Prompt में बताई operation technically valid हो सकती है, लेकिन अब operational decision के रूप में सही नहीं होगी।

मैं लंबे transcript को attach करने के बजाय छोटा approval note पसंद करता हूं। अगले engineer को एक मिनट से कम समय में तीन सवालों का जवाब मिल जाना चाहिए: क्या होगा, कहां होगा और अभी क्यों होना चाहिए? अगर जवाब नहीं मिल सकता, तो उसे reject करें और agent से current state inspect करने के बाद नया action प्रस्तावित करने को कहें।

Session ownership और secret ownership अलग रखें

Session की निगरानी करने वाले व्यक्ति को session द्वारा इस्तेमाल किए जा सकने वाले हर credential की copy की जरूरत नहीं होती। इन दोनों भूमिकाओं को मिलाने से एक जाना-पहचाना और महंगा mess बनता है: कोई «सिर्फ handoff के लिए» token को shell profile में export करता है, फिर token incident, engineer की भूमिका और उसके अस्तित्व की वजह की याद से भी अधिक समय तक बना रहता है।

सही transfer से यह बदलता है कि कौन action को supervise, approve, pause या revoke कर सकता है। इससे API tokens, SSH private keys, browser cookies या temporary cloud credentials chat, notes या agent prompt के जरिए आगे नहीं भेजे जाते। Successor को session reference और उसे operate करने के लिए जरूरी evidence मिलता है। Secret action executor के पास रहता है।

यह अंतर तब सबसे अधिक मायने रखता है, जब outgoing engineer terminal खुला छोड़ देता है। Unlocked shell transfer का वैध तरीका नहीं है। इससे अगले व्यक्ति को inherited state का ढेर मिलता है: exported variables, command history, cached credentials, shell functions, port forwards और आधे-अधूरे commands। इसमें कुछ state उपयोगी हो सकती है। लेकिन इनमें से कोई भी स्पष्ट custody नहीं है।

इनमें से एक तरीका अपनाएं:

• Existing session तभी जारी रखें, जब active operation समझ में आ रही हो, scope सीमित हो, incoming engineer ने उसे स्वीकार कर लिया हो और रोकने से अधिक खराब operational outcome पैदा होगा।
• Old session रोककर incoming engineer के तहत fresh session शुरू करें, जब task investigative हो, authority broad हो, prompt history महत्वपूर्ण हो या agent idle हो गया हो।

दूसरा तरीका अक्सर teams के अनुमान से अधिक सुरक्षित होता है। लोग context खोने के डर से इसका विरोध करते हैं। Context को uninspected process के भीतर रखने के बजाय handoff packet में सुरक्षित रखें। Fresh process की approval boundary साफ होती है और नए owner की जिम्मेदारी स्पष्ट रहती है।

Sallyport इस्तेमाल करने वाली teams के लिए agent underlying secrets पाए बिना HTTP और SSH actions कर सकता है। इसलिए shift change में credential material के बजाय supervision ट्रांसफर की जा सकती है। इसका vault gate locked होने पर actions को रोकता है और incoming engineer को continuation authorize करने से पहले एक स्पष्ट pause point देता है।

Separation को immunity न समझें। अगर successor session पर actions approve कर सकता है, तो उसे scope और evidence के बारे में वही अनुशासन रखना होगा। Secret को prompt से बाहर रखने से एक तरह की विफलता रुकती है। इससे unsafe request सुरक्षित नहीं बनती।

Recovery की शुरुआत containment से करें, continuation से नहीं

जब agent run शांत हो जाए या outgoing engineer unreachable हो जाए, तो incoming engineer को पहले नई external changes रोकनी चाहिए। Background process लिखना जारी रखे और आप दस मिनट तक exact conversational context वापस पाने की कोशिश करते रहें, ऐसा न करें।

Recovery के दो tracks हैं: evidence सुरक्षित रखना और current state स्थापित करना। Process या host के गायब होने की थोड़ी भी संभावना हो, तो इन्हें इसी क्रम में चलाएं। Session identifiers, terminal output, task definitions, approvals, process listings और audit references incident record में कॉपी करें। फिर system के सामान्य controls के अनुसार action path को stop, revoke या lock करें।

Containment के बाद target system की जांच करें। Agent का «call failed» कहना target-side record से कमजोर evidence है। HTTP timeout का अर्थ हो सकता है कि server ने request reject की, एक बार स्वीकार की या स्वीकार करके response खो दिया। Idempotency mechanism के बिना retry करने से action दोहर सकती है।

Target का स्वाभाविक evidence इस्तेमाल करें:

• API write के लिए object, change record, request ID या idempotency record देखें।
• SSH work के लिए remote process, service state, package manager history या deployment marker देखें।
• Code change के लिए repository diff, commit, CI run और deployment state अलग-अलग देखें।
• Queued operation के लिए दूसरा job submit करने से पहले queue और worker status जांचें।

Request retry करने और operation recover करने में अंतर महत्वपूर्ण है। Retry transport attempt दोहराता है। Recovery पहले यह तय करती है कि underlying state बदली या नहीं, फिर अगली action चुनती है। जब agent timeout को «run again» click करने का निमंत्रण बताता है, तब teams इन दोनों को मिला देती हैं। ऐसा नहीं करना चाहिए।

Recovery note में agent की आखिरी बात नहीं, बल्कि आखिरी भरोसेमंद observation लिखें। उदाहरण के लिए: «Agent deploy D42 का अनुरोध करने के बाद timeout हुआ। Deployment service में D42 दो instances पर running दर्ज है। 02:17 पर नई submissions रोक दी गईं।» इससे अगला operator तथ्यात्मक स्थिति से काम शुरू कर सकता है।

अगर state स्थापित नहीं हो पा रही है, तो incident raise करें और authority सीमित रखें। Stalled deploy अक्सर सहने योग्य होता है। Duplicate schema migration, दोबारा payment action या accidental production deletion शायद नहीं।

Record स्वीकार करने से पहले उसे evidence से मिलाएं

Handoff document operator की interpretation है। Audit record system द्वारा दर्ज की गई चीजों का evidence है। दोनों जरूरी हैं, लेकिन इन्हें एक जैसा न मानें।

Incoming engineer के live session को स्वीकार करने से पहले custody record की तुलना ऐसे evidence से करें जिसे outgoing engineer ने हाथ से edit न किया हो। Session start और end times, target names, actions का क्रम और बताई गई approval disposition जांचें। कोई mismatch मिले, तो run जारी रखने से पहले उसकी जांच करें।

Hash chain यहां मदद करती है, क्योंकि इससे record हटाने और क्रम बदलने का पता लगाया जा सकता है। लेकिन यह intent, correctness या approval की समझदारी साबित नहीं करती। इस सीमा को साफ तौर पर बताना उपयोगी है। Cryptographic continuity यह जवाब देती है कि «क्या दर्ज sequence intact रही?» यह नहीं बताती कि «क्या हमें वह request भेजनी चाहिए थी?»

Sallyport के साथ teams इस command से encrypted audit chain को offline verify कर सकती हैं:

sp audit verify

Verifier result को handoff record के साथ सुरक्षित रखें और यह भी लिखें कि verification कब चलाया गया तथा किस log range की समीक्षा हुई। Verification के लिए vault access जरूरी नहीं है। इससे incoming engineer किसी action authority को unlock करने से पहले continuity जांच सकता है।

बड़े audit excerpts को chat में कॉपी करने की आदत न बनाएं। Secrets न होने पर भी logs में sensitive operational metadata हो सकता है। Approved record का reference रखें, handoff समझाने के लिए जरूरी छोटा हिस्सा quote करें और incoming engineer को सामान्य incident path से access दें।

Audit review एक साधारण लेकिन गंभीर समस्या भी पकड़ती है: engineer ने मिलते-जुलते tasks वाले दो agents शुरू किए और एक को भूल गया हो सकता है। Process list दिखाती है कि अभी क्या चल रहा है। Audit sequence दिखाती है कि हर run ने पहले क्या प्रयास किया। जिम्मेदारी स्वीकार करने से पहले दोनों पढ़ें।

Handoff packet ऐसा हो जिसे incident याद न रहने पर भी समझा जा सके

उपयोगी packet उस engineer को सुरक्षित फैसला लेने देता है जो पांच मिनट पहले सो रहा था। उसे सैकड़ों chat messages scroll करने या बिना सीमा वाले prompt transcript को फिर से खोलने की जरूरत नहीं होनी चाहिए। Packet को incident record के पास रखें, हर बार fields का वही क्रम इस्तेमाल करें और authority बदलने पर उसे update करें।

इस template से शुरुआत करें:

Incident or change:
Outgoing owner / incoming owner / transfer time:

Agent run:
- Session ID and local PID:
- Workspace and task reference:
- Current state: continue | pause | cancel | inspect
- Last confirmed external action:
- Next proposed action:

Authority:
- Targets reachable by this run:
- Approval status and expiry:
- Session revoke or stop method:
- Credentials remain held by:

Evidence:
- Activity or audit record reference:
- Target-side evidence checked:
- Process and connection capture:

Recovery:
- Known partial state:
- Safe first action for incoming owner:
- Escalation owner and trigger:

«Safe first action» वाली line बहुत महत्वपूर्ण है। ऐसी action लिखें जो impact बढ़ाए बिना state इकट्ठी करे, जैसे deployment record देखना, queue depth पढ़ना या service version की तुलना करना। «Continue investigation» न लिखें। इस phrase की कोई operational boundary नहीं है।

Packet में यह भी लिखा होना चाहिए कि agent शुरू होने के बाद क्या बदला है। शायद release freeze शुरू हुआ हो, database replica lag कर रही हो, customer ने कोई symptom बताया हो या किसी दूसरे engineer ने manual correction की हो। Agents मिले हुए context पर काम करते हैं। Incoming human को prompt शुरू होने के बाद आया context भी चाहिए।

भाषा factual रखें। «Agent seems confused» successor को उस पर अविश्वास करने को कहता है, लेकिन जांचने के लिए कुछ नहीं देता। «Service ने request ID 7f3 स्वीकार करने के बाद agent ने वही POST फिर प्रस्तावित किया» duplicate-risk condition स्पष्ट करता है और अगली सही जांच का संकेत देता है।

Timing को नजरअंदाज करने पर shift change authorization gap बनाता है

Gap तब बनता है, जब outgoing engineer मानसिक रूप से shift छोड़ चुका हो, लेकिन उसका session अब भी action कर सकता हो। यह gap तब और बढ़ता है, जब incoming engineer ने ownership स्वीकार न की हो, approval state न देख पा रहा हो या मान रहा हो कि agent सिर्फ data पढ़ रहा है। उस समय process के पास authority होती है, लेकिन उसके इस्तेमाल की जिम्मेदारी लेने वाला attentive human नहीं होता।

एक आम failure इस तरह दिखता है। Shift के अंत में engineer agent से failing deployment repair करने को कहता है। Agent SSH connection खोलता है, configuration file edit करता है और service restart करने के approval का इंतजार करता है। Engineer chat में लिखता है «restart pending, should be fine» और sign off कर देता है।

अगला engineer एक घंटे बाद prompt देखता है। उस दौरान manual mitigation से service topology बदल चुकी होती है। Pending restart अब ऐसे node को प्रभावित करता है, जो traffic संभाल रहा है और जिसके बारे में पिछले engineer को पता नहीं था। Approval में command अब भी technically valid है, लेकिन उसे सही ठहराने वाली स्थिति बदल चुकी है।

इस failure के लिए compromised tool या careless person जरूरी नहीं है। यह तब होता है, जब operational context बदलते रहने के बावजूद authorization को permanent माना जाता है। Approval short-lived request और current owner से जुड़ा होना चाहिए। इनमें से कोई condition मौजूद न हो, तो session को authority खो देनी चाहिए।

Explicit transfer deadline तय करें। अगर उस समय तक incoming engineer session स्वीकार नहीं करता, तो agent pause करें और outstanding approvals invalidate करें। कोई task सुरक्षित रूप से pause नहीं हो सकता, तो incident से पहले runbook में यह तथ्य लिखें, बताएं कि उसे कौन स्वीकार कर सकता है और direct escalation route तय करें। Shift change के दौरान exception खोजने की कोशिश न करें।

Teams कभी-कभी हर session को इसलिए alive रखती हैं, क्योंकि agents restart करने में समय लगता है। यह सलाह लोकप्रिय है, क्योंकि local context बचा रहता है और task फिर से समझाना नहीं पड़ता। Broad या uncertain authority के मामलों में यह गलत है। Clean session शुरू करने में लगे कुछ मिनट उस कोशिश की तुलना में सस्ते हैं, जिसमें समझाना पड़े कि owner के offline होने के बाद abandoned process ने system क्यों बदल दिया।

Incoming engineer को जिम्मेदारी एक तय क्रम में स्वीकार करनी चाहिए

Handoff के समय ध्यान बंटा होता है, इसलिए incoming engineer को repeatable acceptance sequence चाहिए। यह शांत दिन के लिए bureaucracy नहीं है। यह उस व्यक्ति को action approve करने से रोकता है जो page से जागा है और अभी यह नहीं जानता कि कौन-सी authority live है।

यह क्रम अपनाएं:

1. Current incident state और custody record पढ़ें, फिर outgoing engineer और transfer time की पुष्टि करें।
2. Named process या session खोजें और active connections, child processes तथा pending requests की जांच करें।
3. Record की तुलना audit evidence और target-side state से करें।
4. Continue, pause या cancel चुनें। हर उस pending approval को reject करें जिसकी स्पष्ट और वर्तमान वजह नहीं बची है।
5. Acceptance, first safe action और next review time दर्ज करें।

क्रम महत्वपूर्ण है। पहले approve करके बाद में inspect करेंगे, तो सबसे बड़ा risk पहले ही स्वीकार कर चुके होंगे। Session record सुरक्षित करने से पहले target inspect करेंगे, तो process exit या machine restart होने पर evidence खो सकते हैं। Fixed sequence «बस इसे चलने दो» वाली स्वाभाविक जल्दबाजी से बचाती है।

Outgoing engineer की भी एक तय जिम्मेदारी है: successor के custody स्वीकार करने या session रुकने तक उपलब्ध रहना। इससे पहले coverage खत्म हो जाए, तो running agent को चुपचाप छोड़ने के बजाय escalate करें। On-call schedule किसी व्यक्ति को नियुक्त करता है, इस उम्मीद को नहीं कि कोई prompt देख लेगा।

इन नियमों को overnight failure से पहले incident practice का हिस्सा बनाएं। शुरुआत एक मौजूदा handoff note में custody fields जोड़कर करें और हर agent run के लिए disposition अनिवार्य करें। पहली बार जब आपको unexplained SSH connection या बिना owner का approval मिले, तब आपको theoretical नहीं, वास्तविक gap मिला होगा।