AI इंसिडेंट स्वीकृति खुले इंसिडेंट को कैसे बचाए

किसी पेज को स्वीकार करने वाला एजेंट केवल एक उपयोगी दावा करता है: किसी व्यक्ति या सिस्टम ने जाँच की जिम्मेदारी ले ली है। एजेंट ने यह साबित नहीं किया कि ग्राहकों की सेवा बहाल हो गई, अलर्ट की शर्त हट गई या अगले उत्तरदाता को अब तैयार रहने की जरूरत नहीं है। जो इंटीग्रेशन स्वीकृति को सीधे बंद करने में बदल देता है, वह इस अंतर को मिटाता है और इंसिडेंट रिकॉर्ड में गलत बात लिखता है।

इंसिडेंट की कार्रवाइयों को अलग स्थिति बदलाव और अलग अनुमतियों के रूप में रखें। पेजर इंटरफेस में acknowledge, resolve, suppress और route एक दूसरे के पास दिख सकते हैं, लेकिन वे अलग संचालन प्रश्नों का जवाब देते हैं। एजेंट को सबसे सीमित कार्रवाई बुलानी चाहिए, नीति के अनुसार असरदार बदलाव को इंसान से मंजूर कराना चाहिए और ऑडिट रिकॉर्ड में दोनों भूमिकाओं की पहचान होनी चाहिए।

स्वीकृति जिम्मेदारी दर्ज करती है, बहाली नहीं

स्वीकृति का मतलब है कि किसी उत्तरदाता ने पेज ले लिया और जाँच शुरू कर दी। इससे यह बदलता है कि अब किससे कार्रवाई की उम्मीद है और अक्सर escalation का व्यवहार भी बदलता है। इससे यह पता नहीं चलता कि खराबी अभी मौजूद है या नहीं।

PagerDuty का Incidents दस्तावेज इस अंतर को साफ करता है: स्वीकार किया गया इंसिडेंट वह है जिस पर काम चल रहा है, लेकिन जो अभी हल नहीं हुआ। स्वीकृति जिम्मेदारी लेती है और acknowledgement timeout तक escalation रोकती है; resolution का अर्थ है कि समस्या ठीक हो गई। यह timeout जरूरी है। अगर उसके खत्म होने से पहले इंसिडेंट हल नहीं होता, तो PagerDuty उसे फिर triggered स्थिति में ला सकता है और escalation दोबारा शुरू कर सकता है। स्वीकृति पर इंसिडेंट बंद करने वाला एजेंट इस सुरक्षा को चुपचाप हटा देता है।

Google Cloud Monitoring के शब्द कुछ अलग हैं, पर सीमा वही है। उसका दस्तावेज Acknowledged को ऐसा खुला इंसिडेंट बताता है जिसे जाँच के दौरान किसी ने हाथ से स्वीकार किया हो। दस्तावेज यह भी कहता है कि स्वीकृति से बार बार आने वाली सूचनाएँ बंद नहीं होतीं। snooze या policy बदलाव सूचनाओं को नियंत्रित करता है, जबकि closure रिकवरी के अवलोकन, हाथ से बंद करने या automatic close condition से आता है। यह व्यवहार याद दिलाता है कि पेजर के हर क्रिया शब्द के एक जैसे दुष्प्रभाव नहीं होते।

व्यावहारिक अनुबंध सीधा होना चाहिए: acknowledge assignee, स्वीकृति का समय और काम लेने वाले actor को दर्ज करता है। अगर पेजर ऐसा करता है, तो यह escalation path को रोक सकता है। इसे recovery status खुला रखना चाहिए, active alerts को बचाना चाहिए और notification या routing rules को तब तक नहीं बदलना चाहिए जब तक caller किसी अलग नियंत्रण से अलग कार्रवाई न माँगे।

यह सीमा इंसिडेंट के मापों को भी बचाती है। अगर स्वीकृति रिकॉर्ड को बंद कर देती है, तो स्वीकार करने का समय और सेवा बहाल करने का समय एक ही timestamp बन जाता है। टीम तेज बटन दबाने को अच्छा प्रदर्शन समझने लगती है, जबकि वह माप खो देती है जो बताता था कि उपयोगकर्ताओं ने असल में कितनी देर तक परेशानी झेली। postmortem में भी वही गलती आती है, क्योंकि timeline mitigation होने से पहले ही recovery दिखाती है।

एजेंट का एक क्रिया शब्द केवल एक बदलाव करे

एजेंट के हर tool को एक संचालन क्रिया और एक मुख्य असर देना चाहिए। शांत design review में bundled actions सुविधाजनक लगते हैं, पर असली खराबी के दौरान उन्हें समझना मुश्किल हो जाता है।

Acknowledge इस प्रश्न का जवाब देता है कि काम किसने लिया। उसका मुख्य असर जिम्मेदारी और स्वीकृति का समय दर्ज करना है; उसे service recovery या alert clearance नहीं मानना चाहिए। Resolve बताता है कि इंसिडेंट खत्म हुआ या नहीं। यह recovery evidence के बाद रिकॉर्ड बंद करता है और साथ में भविष्य के पेज mute या ownership नहीं बदलता।

Suppress पूछता है कि चुना हुआ signal इंसिडेंट बनाए या सूचना भेजे। वह तय scope के लिए कुछ notifications या incident creation रोकता है, लेकिन पहले से खुले इंसिडेंट को recover नहीं करता। Route पूछता है कि काम किसे मिलना चाहिए। वह service, team, escalation path या assignee बदलता है, लेकिन यह दावा नहीं करता कि destination ने काम स्वीकार या हल कर दिया।

ये परिभाषाएँ authorization boundary बनाती हैं। कोई इंसान अपने team को दिए गए हर पेज को agent से स्वीकार कराने में सहज हो सकता है, पर resolution के लिए इंसानी मंजूरी माँग सकता है। वही व्यक्ति suppression केवल घोषित maintenance window में और routing केवल दो services के बीच अनुमति दे सकता है। एक चौड़ी manage_incident capability छिपी शाखाओं के बिना इन विकल्पों को व्यक्त नहीं कर सकती।

ack, mute, assign और close flags वाला handle_page tool न बनाएँ। इससे model लिखे हुए निर्देश के आधार पर actions का bundle चुनेगा, और एक गलत समझा वाक्य कई बदलाव कर सकता है। अलग tools caller को अपना इरादा साफ करने पर मजबूर करते हैं और gateway हर transition को अलग authorize कर सकता है।

यह अलगाव vendor adapters में भी रहना चाहिए। एक provider शांत करने की कार्रवाई को snooze और दूसरा downtime कह सकता है। adapter दोनों नामों को साझा suppress_notifications intent में map कर सकता है। केवल इसलिए suppression और resolution को एक जैसा न बनाएँ कि दोनों से pager शांत हो सकता है।

सुरक्षित API गलत जोड़ को व्यक्त ही न करने दे

सीमित request schema किसी चतुर prompt से ज्यादा दुर्घटनाएँ रोकता है। नीचे का request केवल एक मौजूदा incident स्वीकार कर सकता है; वह close, mute या reassignment को छिपाकर साथ नहीं भेज सकता।

{
  "operation": "incident.acknowledge",
  "incident_id": "inc_01JQ8K4Q6M",
  "expected_version": 17,
  "actor": {
    "type": "agent",
    "session_id": "ses_01JQ8JY2P3"
  },
  "reason": "Accepted investigation after the database latency page"
}

जिन पहचान तथ्यों की जाँच हो सकती है, उन्हें server जोड़े, agent नहीं। Model कारण लिख सकता है, लेकिन उसके अपने executable hash, code-signing identity, user account या approval result के दावे पर भरोसा नहीं करना चाहिए। Gateway ये values authenticated process और approval channel से निकाले।

सफल response को सही transition और बची हुई स्थिति दोनों बतानी चाहिए:

{
  "operation_id": "op_01JQ8K5D7A",
  "incident_id": "inc_01JQ8K4Q6M",
  "transition": "triggered_to_acknowledged",
  "incident_status": "acknowledged",
  "recovery_status": "open",
  "version": 18,
  "approved_by": "usr_2048",
  "approved_at": "2026-07-24T02:14:31Z"
}

recovery_status: open लौटाना दोहराव लग सकता है, फिर भी इसे रखें। Agent अक्सर मिले हुए आखिरी response के आधार पर आगे सोचते हैं, और provider semantics का अनुमान model से लगवाने से explicit state सस्ती है। Response orchestrator को स्थिर test assertion भी देता है: acknowledgement सफल हुआ और recovery खुली रही।

Acknowledgement request में resolve_if_healthy, mute_for या route_to जैसे उलझे convenience fields स्वीकार न करें। ये fields एक endpoint को फिर bundle बना देते हैं। Workflow को दूसरी कार्रवाई चाहिए तो वह दूसरा request भेजे, अलग decision पाए और अलग audit event छोड़े।

मंजूरी उसी बदलाव से बँधी हो

मंजूरी एक साफ बताए गए state change को authorize करे, agent को सामान्य रूप से सही न ठहराए। Session approval यह साबित कर सकती है कि जाना पहचाना process चल सकता है, लेकिन बाद में मिले हर incident mutation की अनुमति अपने आप नहीं देनी चाहिए।

हर transition के लिए proposed operation, target incident, decision से पहले दिखी state, requested scope, requester agent session, approving human, decision time और approval method दर्ज करें। Approver ने जो state version या provider event identifier देखा, वह भी जोड़ें। इस binding के बिना incident A का approval card incident B पर दोबारा इस्तेमाल हो सकता है, या triggered state में दी गई मंजूरी तब चल सकती है जब कोई दूसरा व्यक्ति incident resolve कर चुका हो।

Approval screen को संचालन की सीधी भाषा इस्तेमाल करनी चाहिए। Database latency incident inc_01JQ8K4Q6M स्वीकार करें और जाँच Payments Duty को दें review किया जा सकता है। Allow agent action नहीं। Resolution के लिए agent का दिया recovery evidence और अभी active चीजें दिखाएँ। Suppression के लिए सही signal scope, अवधि और expiry दिखाएँ। Routing के लिए मौजूदा और सुझाया destination दोनों दिखाएँ।

एक अस्पष्ट actor field में सबको मिलाने की बजाय चार identities रखें:

• Requester वह agent session है जिसने बदलाव सुझाया।
• Approver वह इंसान है जिसने जरूरत पड़ने पर अनुमति दी।
• Executor वह gateway या integration identity है जिसने provider को call किया।
• Subject वह incident, alert, service या route है जो बदला।

Review में ये identities अलग सवालों के जवाब देती हैं। Requester बताता है automation क्यों शुरू हुआ। Approver इंसानी authority स्थापित करता है। Executor event को credential और provider logs से जोड़ता है। Subject सही decision को किसी दूसरे resource पर जाने से रोकता है।

Sallyport सुरक्षित key के हर इस्तेमाल पर HTTP API और SSH action को per-call approval के पीछे रख सकता है, जबकि credential encrypted vault में रहता है और agent को कभी नहीं मिलता। यह व्यवस्था incident transitions के लिए सही बैठती है, क्योंकि approval model के स्वतंत्र वादे के बजाय असली provider request से बँध सकता है।

रेस भरोसेमंद दिखती automation को झूठी timeline बनाती है

Agent के सोचने, approval की प्रतीक्षा करने या network call retry करने के दौरान incident state बदलती रहती है। इस देरी को अनदेखा करने वाला design किसी resolved incident को acknowledge करेगा, active responder से काम दूसरी ओर भेजेगा या maintenance खत्म होने के बाद पुरानी suppression लागू करेगा।

Optimistic concurrency इस्तेमाल करें। Agent version 17 पढ़ता है, version 17 पर acknowledgement प्रस्तावित करता है और gateway तभी चलाता है जब provider record अभी भी जरूरी state से मेल खाता हो। कोई responder पहले incident बदल दे तो operation को नई state पर चुपचाप लागू न करें; mismatch बताने वाला conflict लौटाएँ।

{
  "error": "state_conflict",
  "incident_id": "inc_01JQ8K4Q6M",
  "expected_version": 17,
  "actual_version": 19,
  "actual_status": "resolved",
  "retryable": false
}

Agent को हर conflict retry करना न सिखाएँ। Transport timeout उसी operation identifier के साथ idempotent retry की अनुमति दे सकता है। State conflict के लिए नया read और आम तौर पर नया decision चाहिए। Incident पहले से resolved हो तो acknowledgement बेकार है। वह किसी और team को route हो चुका हो तो पुरानी approval नए destination पर लागू नहीं हो सकती।

एक आम failure धीमी approval से शुरू होता है। Agent triggered database page पढ़कर Alice से acknowledgement मंजूर करने को कहता है। Card इंतजार करता है और उसी समय Bob समस्या कम करके incident resolve कर देता है। फिर Alice stale card मंजूर करती है। कमजोर adapter acknowledge भेजता है, provider का खास success लेता है या incident को फिर active करता है, और खत्म हो चुके काम का owner Alice को लिख देता है। Version binding timeline गलत होने से पहले action रोकती है।

Idempotency दूसरी समस्या हल करती है। हर proposed transition को immutable operation ID दें और result save करें। Provider acknowledgement लागू कर दे, लेकिन gateway HTTP response खो दे, तो retry saved result लौटाए। वह दूसरी timeline entry या एक और notification नहीं बनाए। Concurrency guard बदली state से intent को बचाता है; idempotency एक intent को duplicate execution से बचाती है।

Routing और suppression की अपनी अनुमति हो

Routing बदलती है कि जिम्मेदारी किसकी है, suppression बदलती है कि कौन से signals शोर पैदा करते हैं। कोई भी recovery साबित नहीं करती और किसी को acknowledgement के अंदर छिपना नहीं चाहिए।

मौजूदा service साफ तौर पर गलत हो और किसी ने काम न लिया हो, तो acknowledgement से पहले route करें। Acknowledgement के बाद route करने में सावधानी रखें, क्योंकि responder जाँच शुरू कर चुका हो सकता है। Transition बताए कि ownership बदलती है या नहीं, पुराना responder subscribed रहता है या नहीं और destination की escalation policy शुरू होती है या नहीं। Agent को team name से इन असर का अनुमान नहीं लगाना चाहिए।

Suppression का साफ scope और expiry होना चाहिए। PagerDuty का Event Management दस्तावेज कहता है कि suppressed alerts forensics के लिए रहते हैं, पर incident नहीं बनाते। उसका Event Orchestration दस्तावेज यह भी बताता है कि unmatched events को service में route किया जा सकता है या catch-all path में suppress किया जा सकता है। ये ingestion decisions हैं, खुले incident को बंद करने के दूसरे नाम नहीं।

Datadog का Downtimes दस्तावेज एक और उपयोगी सीमा बताता है: downtime alerts और notifications शांत करता है, लेकिन monitor state transitions नहीं रोकता। Downtime खत्म होने पर monitor अभी alert state में हो, तो notification फिर शुरू हो सकती है। Maintenance में अक्सर यही चाहिए। System unhealthy state याद रखता है, केवल notification रोकने के लिए उसे healthy नहीं लिखता।

Suppression request में signal selector, start और end times, reason, creator और expiry behavior होने चाहिए। पूरे service जैसे broad selector को एक monitor group से मजबूत approval चाहिए। Indefinite suppression को reject करें या साफ exception path माँगें। Agent ऐसा शांत failure न बनाए जिसका कोई owner न हो।

केवल इसलिए acknowledgement के बाद suppression न करें कि responder ने पेज ले लिया। कुछ systems acknowledgement पर escalation रोकते हैं, दूसरे repeated notifications जारी रखते हैं। Google Cloud Monitoring साफ कहता है कि acknowledgement repeated notifications नहीं रोकता। Provider behavior बचाएँ या suppression अलग request करें, ताकि reviewer देख सके कि शोर क्यों बंद हुआ।

Resolution agent के भरोसे नहीं, evidence के बाद हो

Incident तभी resolve करें जब recovery evidence घोषित condition से मेल खाए। Remediation command की सफलता केवल यह साबित करती है कि action चला; यह service recovery का प्रमाण नहीं।

यह फर्क automation की परिचित गलती पकड़ता है। Agent process restart करता है, exit code zero पाता है और incident बंद कर देता है। Process शुरू होता है, readiness check में fail होता है और तीस सेकंड बाद फिर crash हो जाता है। Command सफल था, service कभी recover नहीं हुई। Command success पर close करने से एक लगातार घटना के बजाय दो incidents, दो pages और गलत recovery time बनते हैं।

Incident type के पास resolution evidence परिभाषित करें। Availability incident में alert condition clear होकर एक evaluation window तक clear रहना जरूरी हो सकता है। Queue incident में backlog और सबसे पुराने message की उम्र, दोनों thresholds से नीचे होनी चाहिए। Certificate page तभी resolve हो जब deployed endpoint expected certificate दिखाए, केवल किसी host पर file लिखे जाने पर नहीं।

Agent evidence इकट्ठा कर सकता है और resolution propose कर सकता है। Gateway observations, timestamps, sources और data gaps approval के साथ लगाए। Monitor अभी active condition बताए तो close reject करें। Google Cloud Monitoring metric incidents के साथ यही करता है: उसके दस्तावेज में recent data policy तोड़ने पर Unable to close incident with active conditions error आता है।

Manual resolution की जरूरत फिर भी रहती है। Monitor में देर हो सकती है, telemetry fail हो सकती है या responder जानता हो कि प्रभावित service जानबूझकर बंद की गई। Override को reason और approver के साथ साफ दर्ज करें और आखिरी unhealthy observation रखें। Override जिम्मेदार exception है, सामान्य transition कमजोर करने का बहाना नहीं।

Reopening behavior भी contract का हिस्सा है। बताएँ कि लौटता signal उसी incident को खोलता है या नया बनाता है, और दोनों में correlation identifiers रखें। Agent यह न माने कि resolve अगला event mute करेगा। PagerDuty कहता है कि जरूरत पर resolved incident दोबारा खुल सकता है, जबकि Datadog बताता है कि manual resolve monitor को केवल अगले evaluation तक OK करता है। अगला unhealthy evaluation फिर alert कर सकता है।

Audit trail को decision बचाना चाहिए

Provider activity logs बताते हैं कि API credential ने endpoint call किया। वे आम तौर पर यह समझाने के लिए पर्याप्त context नहीं रखते कि agent ने क्या सुझाया, व्यक्ति ने क्या मंजूर किया और उस समय कौन सी state दिखी। अलग decision record रखें और उसे provider event से जोड़ें।

पूरा transition event immutable operation ID, request payload hash, normalized action, target, before और after state, requester identity, approver identity, executor identity, approval method, decision timestamps, provider response identifier और result रखता है। Rejected और expired proposals भी दर्ज करें। Denied suppression समझाती है कि notifications क्यों जारी रहीं, और expired approval बताती है कि proposed acknowledgement क्यों नहीं चला।

Sequence को चुपचाप edit होने से बचाएँ। Append-only storage, सीमित writers, retention controls और cryptographic chaining अलग threats रोकते हैं। Sallyport एक encrypted hash-chained audit log से Sessions और Activity journals बनाता है, और sp audit verify बिना decryption key के ciphertext chain को offline जाँच सकता है। Incident integration credential agent को दिए बिना agent run और हर external call का evidence रख सकती है।

केवल agent की prose explanation न रखें। Models आत्मविश्वासी लेकिन गलत summaries बना सकते हैं, इसलिए structured facts साथ रखें। latency page accepted जैसा reason timeline पढ़ने में मदद करता है; incident ID, state version, HTTP request hash और approval identity investigator को उसे verify करने देते हैं।

Integration बदलते समय audit readers को stable semantics चाहिए। Event schema और normalized action names version करें। Adapter provider mapping बदले तो हर call के साथ adapter version दर्ज करें। वरना नई release के side effects बदलने के बाद पुराना acknowledge event अस्पष्ट हो जाएगा।

Audit trail का access incident credentials का access नहीं होना चाहिए। Event order verify करने की क्षमता और sensitive payload fields decrypt करने की क्षमता अलग रखें। Secrets record में पहुँचने से पहले हटाएँ, बाद में हर reader से सुरक्षित handling की उम्मीद न करें।

बदलावों को विरोधी workflow की तरह जाँचें

Happy path tests केवल यह साबित करते हैं कि शांत परिस्थिति में endpoint काम करता है। Incident automation को हर read, approval, call और response के बीच workflow रोककर test करना चाहिए।

पहले पाँच invariants रखें:

1. Acknowledgement recovery को open से closed कभी नहीं बदलती।
2. Resolution suppression बनाती या बढ़ाती नहीं।
3. Routing यह नहीं मानती कि destination ने incident स्वीकार किया।
4. हर approved mutation requester, approver, executor और subject बताती है।
5. Stale approval अलग state version या target पर नहीं चल सकती।

फिर adapter को fake provider के साथ चलाएँ जो calls के बीच state बदल सके। Acknowledgement approval का इंतजार करे तब incident resolve करें। Suppression से पहले route बदलें। Request स्वीकार करके timeout लौटाएँ, फिर वही operation ID भेजें। Approval के बाद लेकिन execution से पहले agent session revoke करें। हर case deterministic result और audit event दे।

Provider differences को मिटाने की जगह test करें। एक pager acknowledgement पर escalation रोक सकता है; दूसरा repeated notifications जारी रख सकता है। Normalized response escalation_paused और notifications_suppressed अलग facts के रूप में दिखा सकता है। Adapter जिसे verify नहीं कर सकता, ऐसा universal side effect promise न करें।

Tool descriptions को code जैसी शंका से review करें। इस incident को संभालो model को outcome चुनने देता है। दर्ज करो कि Payments Duty team ने जाँच ली है; recovery खुली रखो सीमित transition बताता है। Tool text control surface का हिस्सा है, क्योंकि वही agent के request को आकार देता है।

अंत में authority न होने का test करें। केवल acknowledge permission वाला agent resolve, route या suppress call करे तो साफ denial मिले। Denial ऐसा automatic fallback न दे जो कोई अलग mutation कर दे। सुरक्षित failure incident को visible और unchanged रखता है।

असर बढ़ने के साथ agent की authority घटे

Permission design हर action के असर से बने, उसे call करने वाले workflow की सुविधा से नहीं। Incident पढ़ना, assigned work स्वीकार करना, जिम्मेदारी बदलना, signal शांत करना और recovery घोषित करना अलग असर रखते हैं, इसलिए grants भी क्रमशः सख्त होनी चाहिए।

Verb और scope दोनों बताने वाली capabilities से शुरू करें। Payments service के लिए incident.acknowledge, पूरे production के incident.write से सीमित है। Route grant destinations को उसी group के services तक सीमित कर सकती है। Suppression grant selectors और duration सीमित कर सकती है। Resolve grant approved evidence profile माँग सकती है। Gateway restrictions को structured request fields से जाँचे, agent explanation से नहीं।

Grant में समय और process identity भी हों। एक coding task के लिए शुरू हुई agent session, process exit के बाद incident authority न रखे। Approval के इंतजार में व्यक्ति session revoke करे तो execution fail हो, भले पहले decision उस समय valid था। Approval proposed transition की पुष्टि है; वह खत्म authority वाले requester को वापस नहीं लाती।

Permission और approval अलग रखें। Permission बताती है requester इस action class को try कर सकता है या नहीं। Approval बताती है यह specific attempt अभी आगे जा सकती है या नहीं। Approval की जरूरत broad permission को ठीक नहीं करती, क्योंकि reviewers में approval fatigue आती है, खासकर जब cards scope छिपाएँ। इसी तरह narrow permission consequential transition की human approval को replace नहीं करती, अगर organization यही चाहता है।

Visibility घटाने वाली actions पर सख्ती बढ़ाएँ। Acknowledgement owner जोड़ती है और fault visible रखती है। Routing page को मौजूदा team की नजर से हटा सकती है। Suppression जारी failure की खबर रोक सकती है। Resolution active queues से incident हटा सकती है और performance reports बदल सकती है। यह क्रम हर जगह एक नहीं होगा, पर लिखने से मतभेद रात की घटना से पहले सामने आते हैं।

Credentials वही boundaries मानें। Provider अलग roles या tokens देता है तो executor को केवल acknowledgement के लिए schedules और services manage करने वाला account न दें। Provider केवल broad credential देता हो तो operation gateway में सीमित करें और threat model में सीमा साफ लिखें। Provider audit बताएगा credential क्या कर सकता था; gateway record बताए कि इस request में उसे क्या करने दिया गया।

Revocation का नतीजा predictable हो। Agent session revoke करने पर उस process के हर नए operation को रोकें। Execution शुरू न हुआ हो तो approval revoke करने पर bound operation रोकें। Route या suppression grant revoke करने पर बाद के requests रुकें, और existing suppressions को साफ cancellation transition से संभालें। पहले decision के evidence को चुपचाप delete न करें।

Teams अक्सर incident शुरू होते समय एक human approval देकर agent को बाकी सब करने देना चाहती हैं। विचार लोकप्रिय है क्योंकि repeated prompts responder को रोकते हैं, लेकिन mixed consequences के लिए गलत है। Routine access के लिए agent session एक बार approve करें, फिर broad suppression, दूसरी team में routing और resolution जैसी actions के लिए transition approval रखें। Low risk काम चलता रहेगा और शुरुआती जल्दबाजी का click एक घंटे बाद incident बंद करने का अधिकार नहीं बनेगा।

Deployment से पहले actions को rows और scopes को columns बनाकर authority matrix लिखें। हर cell में तय करें agent read, propose, बिना नए decision execute या approval के बाद execute कर सकता है। Maximum suppression duration, allowed route destinations, acceptable resolution evidence और approver के जवाब न देने पर behavior जोड़ें। Empty cell action deny करे, broad label से permission inherit न करे।

Matrix को असली provider credential के साथ exercise करें। Gateway policy resolution deny करती है, लेकिन exposed generic HTTP tool provider endpoint को सीधे call कर सकती है, तो policy अधूरी है। Pager तक हर रास्ते की inventory बनाएँ, जिसमें generic request tools, command runners, webhook relays और saved scripts हों। Gateway bypass करने वाले credentials agent process को उपलब्ध न हों।

Approval prompts पर rate controls भी चाहिए, लेकिन rate limit safe तरीके से fail हो। Agent reviewer को समान acknowledgement requests भेजे तो identical proposals जोड़ें या extras expire करें। Approval overload के जवाब में auto-approve, auto-resolve या incident hide न करें। Extra requests दर्ज करें ताकि team उन्हें बनाने वाला loop ठीक कर सके।

शांत पेजर भी खुले इंसिडेंट को दिखा सकता है

Pager noise, responder ownership, service health और team routing अलग dimensions हैं। उन्हें एक status में मिलाने से interface सरल दिखता है, लेकिन ambiguity automation, metrics और postmortems में चली जाती है।

Agent acknowledgement सही करे तब भी उसे सीमित रखें। उसे work claim करने दें, इस claim की approval दर्ज करने दें और incident खुला रखने दें। Workflow को नया route, temporary suppression या verified recovery के बाद resolution चाहिए तो हर action को अलग visible request और decision बनाएँ।

इस design में कुछ extra tool calls लगती हैं। बदले में रात दो बजे incident commander को भरोसेमंद timeline मिलती है: page किसने लिया, transition किसने मंजूर किया, उस समय system ने क्या दिखाया और incident आखिर क्यों बंद हुआ।