AI एजेंट feature flags बदल रहे हैं: हर write पर नियंत्रण रखें

AI एजेंट द्वारा feature flags में बदलाव को प्रोडक्शन राइट की तरह संभालना चाहिए, क्योंकि वे वास्तव में वही हैं। कोई फ्लैग deployment pipeline से बाहर हो सकता है, फिर भी वह कुछ ही सेकंड में ग्राहकों के लिए कोड चालू कर सकता है, पेमेंट पथ रोक सकता है, किसी experiment का दायरा बढ़ा सकता है या safety check बंद कर सकता है।

मैं बार-बार एक गलती देखता हूँ। एजेंट को flag provider का access इसलिए दे दिया जाता है क्योंकि काम मामूली लगता है: "नया flow internal users के लिए चालू कर दो" या "rollout को zero कर दो।" बदलाव सही भी हो सकता है। ख़तरा उस रिकॉर्ड के न होने में है। आउटेज के बाद लोगों को पता होना चाहिए कि एजेंट ने क्या माँगा, अनुरोध किसने स्वीकार किया, प्रोवाइडर ने क्या किया और अंतिम स्थिति अनुरोध से मेल खाती थी या नहीं। Chat transcript यह ज़िम्मेदारी नहीं उठा सकता।

Flag mutation एक production write है

Feature flag update का operational असर production database setting बदलने या live routing rule संपादित करने जैसा ही होता है। API call छोटी हो सकती है, लेकिन उसका प्रभाव व्यापक और तत्काल हो सकता है।

Flags को harmless configuration मानने से एक परिचित समस्या पैदा होती है। एजेंट बढ़ी हुई error rate की जाँच करता है, हाल की feature से जुड़ा फ्लैग ढूँढ़ता है और उसे false कर देता है। इससे उपयोगकर्ताओं की रक्षा हो सकती है। लेकिन targeting rule इस्तेमाल होने पर यह किसी असंबंधित code path को भी बंद कर सकता है, या एजेंट ने गलत environment चुन लिया हो सकता है। अगर कोई exact requested mutation और उसे मंज़ूरी देने वाले व्यक्ति की पहचान नहीं कर सकता, तो टीम service बहाल करने के बजाय incident के दौरान इतिहास पर बहस करती रहती है।

Martin Fowler के Feature Toggles लेख में एक ऐसा अंतर बताया गया है जिसे टीमें अक्सर मिटा देती हैं। Release toggles, experiment toggles, operational toggles और permissioning toggles की अवधि और गतिशीलता अलग होती है। इस अंतर से एजेंट की कार्रवाई पर लागू नियंत्रण भी बदलना चाहिए। किसी failing integration को बंद करने वाला operational toggle तेज़ human approval माँग सकता है। Regulated data तक पहुँच बदलने वाला permissioning toggle कहीं अधिक कड़े रास्ते का हकदार है। दोनों को "एक flag" कहने से जोखिम के बारे में बहुत कम पता चलता है।

Flag बदलाव उन controls को भी bypass करते हैं जिन्हें engineers code deployments से जोड़ते हैं। Pull request में peer review दिख सकता है, build में test results और release में artifact version। Flag provider call में शायद केवल token name और timestamp दिखे। अगर autonomous process token का मालिक है, तो वह token name भी कई runs में साझा हो सकता है।

हर production write से पहले पूछे जाने वाला यही सवाल यहाँ भी पूछें: यह अनुरोध कौन-सी exact state बदलेगा, किसके अधिकार के तहत बदलेगा और हम resulting state का प्रमाण कैसे देंगे?

Read और write अलग हैं। एजेंट recommendation तैयार करने के लिए flag, उसके environment और मौजूदा rules को देख सकता है। Write किसी external system को बदलता है। केवल इसलिए इन permissions को साथ न दें कि integration ऐसा करना आसान बनाता है।

Intent, authorization, execution और observed state अलग रखें

Feature flag action का वर्णन करने के लिए एक event पर्याप्त नहीं है। विश्वसनीय रिकॉर्ड में चार अलग तथ्य होते हैं। उन्हें मिला देने से वह failure छिप जाता है जिसकी बाद में जाँच करनी पड़ेगी।

Intent वह है जो एजेंट करवाना चाहता था। इसमें stable flag identifier, environment, requested value या rule change, reason और scope होना चाहिए। इसे provider call से पहले दर्ज करें।

Authorization बताता है कि उस intent की अनुमति किसने दी। Human approval को सटीक proposed change से जुड़ना चाहिए, न कि "एजेंट को flags manage करने दो" जैसे अस्पष्ट अनुरोध से। निर्णय लेने के लिए approver को target environment, current state, proposed state, affected segment, expiry और उससे जुड़े task या incident की पर्याप्त जानकारी चाहिए।

Execution outbound request और provider response दर्ज करता है। यह प्रमाण है कि gateway ने approved action करने की कोशिश की। यह इस बात का प्रमाण नहीं कि desired state मौजूद है।

Observed state write के बाद flag को पढ़ने से मिलती है। इससे malformed payload, partial update, defaulting behavior और गलत project या environment को भेजी गई call पकड़ी जा सकती है। Read-back की भी सीमाएँ हैं। Cached SDK clients ने बदला हुआ configuration शायद fetch न किया हो, और इससे यह साबित नहीं होता कि flag के पीछे का code सही व्यवहार कर रहा है। वे अलग observations हैं, जिन्हें deployment telemetry और application monitoring में दर्ज करना चाहिए।

Rollback के समय यह अंतर महत्वपूर्ण हो जाता है। मान लें कि एजेंट checkout_v2=false का अनुरोध करता है, मानव उसे मंज़ूर करता है और provider success लौटाता है। अगर एजेंट के read-back से पहले दूसरा operator flag बदल दे, तो साधारण log एक साफ़ लेकिन झूठी कहानी बताएगा। सही रिकॉर्ड कहेगा कि approved request API boundary पर सफल हुआ, फिर वह observed state भी बताएगा, जिसमें provider उपलब्ध कराए तो version या revision शामिल होगी।

इन fields की जगह free-form reason का इस्तेमाल न करें। "Checkout errors कम करें" उपयोगी context है। यह target, पुराना मान, approved नया मान या final result नहीं है।

Provider call से पहले mutation envelope दर्ज करें

एजेंट को flag provider के लिए मनमाना HTTP request बनाने के बजाय structured change request भेजना चाहिए। Fixed envelope ऐसा रिकॉर्ड बनाता है जिसे reviewer पढ़ सकता है और gateway validate कर सकता है।

यह उदाहरण Boolean flag का है, लेकिन यही shape JSON configuration, percentage rollouts और targeting rules पर भी लागू होती है। Rule changes को scalar value changes से अलग रखें। Targeting rule exposure को किसी एक true या false मान से कहीं अधिक बदल सकता है।

{
  "request_id": "ffchg_01J8KQ4W6D7P",
  "correlation_id": "incident_INC-1842",
  "operation": "set_boolean_flag",
  "flag": {
    "project": "storefront",
    "environment": "production",
    "name": "checkout_v2"
  },
  "expected": {
    "value": true,
    "revision": "481"
  },
  "requested": {
    "value": false
  },
  "reason": "Reduce checkout failures while payment timeout is investigated",
  "rollback": {
    "value": true,
    "expires_at": "2025-03-08T18:00:00Z"
  }
}

expected block शांत overwrite रोकता है। इसका अर्थ है: mutation तभी करें जब current value और revision अभी भी उस स्थिति से मेल खाते हों जिसे requester ने देखा था। अगर agent के पढ़ने के बाद किसी मानव या automation ने flag बदल दिया है, तो request अस्वीकार करें और नई state दिखाएँ। बिना सोचे retry करना गलत है। एजेंट को फिर से पूछना होगा, क्योंकि कार्रवाई का उसका आधार अब मौजूद नहीं है।

request_id idempotent होना चाहिए। Provider को request मिलने और caller को response मिलने के बीच network failure हो सकता है। Idempotency के बिना agent retry duplicate audit events बना सकता है या percentage rule को दो बार लागू कर सकता है, जब provider updates को patches की तरह model करता हो। Request ID को store करें और दोबारा भेजे गए submission पर मूल outcome लौटाएँ।

Gateway इस तरह का result लौटा सकता है:

{
  "request_id": "ffchg_01J8KQ4W6D7P",
  "status": "applied",
  "provider_request_id": "p_9d3ab",
  "authorization": {
    "approver": "[email protected]",
    "approved_at": "2025-03-08T17:18:32Z"
  },
  "observed": {
    "value": false,
    "revision": "482",
    "read_at": "2025-03-08T17:18:35Z"
  }
}

इनमें से किसी record में provider tokens शामिल न करें। Credentials वाला request log अंततः दूसरा secret store बन जाता है, अक्सर access controls और अधिक copies के साथ।

Approval में blast radius साफ़ दिखना चाहिए

केवल flag name देखकर कोई मानव सुरक्षित बदलाव को मंज़ूरी नहीं दे सकता। नाम बदल सकते हैं, flags अपने मूल उद्देश्य से अधिक समय तक बने रह सकते हैं और Boolean किसी सरल label के पीछे बड़ा targeting rule छिपा सकता है।

Approval card या review screen में current representation और requested representation को साथ दिखाएँ। Percentage rollout के लिए exact पुराने और नए प्रतिशत, population या segment, prerequisite flag और environment दिखाएँ। Rule edit के लिए readable canonical form में पूरा before और after rule दिखाएँ। किसी clause को दोहराव समझकर diff से हटाना ही वह गलती है जिससे "region A के employees" अनजाने में "all users" बन जाते हैं।

Approver को reason और expiry भी चाहिए। Temporary operational changes अक्सर permanent बन जाते हैं, क्योंकि incident खत्म होते ही सब आगे बढ़ जाते हैं। Expiry कोई जादुई rollback नहीं है। यह operator को flag का फिर से मूल्यांकन करने का तय समय देता है और action record में एक स्पष्ट commitment बनाता है।

Approval scope agent से नहीं, mutation से मेल खाना चाहिए। "बाकी session के लिए इस process को approve करें" बार-बार inspection या predefined non-production actions के लिए ठीक हो सकता है। Production rollout के लिए यह खराब scope है, जहाँ हर action अलग customer population बदलता है।

जब इनमें से कोई condition लागू हो, मैं हर production mutation के लिए अलग approval रखूँगा:

• बदलाव operational control, payments, authentication, authorization या data retention को प्रभावित करता हो।
• Request एक Boolean value के बजाय targeting rule, segment, prerequisite या percentage बदलता हो।
• Action production या real customer traffic से जुड़े environment को target करता हो।
• Agent ऐसा value प्रस्तावित करता हो जो approved rollback plan से अलग हो।

यह approval theater नहीं है। Human का काम request को फिर से टाइप करना नहीं। उसका काम यह तय करना है कि बताई गई scope और मौजूदा operational स्थिति write को उचित ठहराती हैं या नहीं। अगर card scope छिपा देता है, तो व्यक्ति केवल बिना जाँच के मंज़ूरी दे सकता है।

"Agent को feature flags manage करने की अनुमति है" जैसी standing approval से बचें। यह आकर्षक है क्योंकि interruptions खत्म हो जाते हैं। लेकिन इससे हर बाद का mutation unreviewed production write बन जाता है, जिसमें वह असामान्य बदलाव भी शामिल है जो stale context या भ्रामक tool result से confused agent के दौरान हो सकता है।

Concurrency के कारण automated rollback डिफ़ॉल्ट रूप से unsafe है

एजेंट किसी flag को तभी rollback कर सकता है जब वह साबित करे कि वह अपना ही बदलाव वापस कर रहा है। "Failure पर agent को हमेशा revert करने दें" जैसी आम सलाह concurrent operators को नज़रअंदाज़ करती है और unsafe है।

यह क्रम देखें। 10:00 बजे current value true, revision 481 है। Agent को इसे false करने की approval मिलती है और provider revision 482 दर्ज करता है। 10:06 बजे on-call engineer अलग symptom देखकर जानबूझकर flag को true, revision 483 कर देता है। 10:08 बजे agent की monitoring condition trigger होती है और वह अपना planned rollback करके true कर देता है।

इस मामले में duplicate value harmless लगती है, लेकिन targeting rule के साथ यही pattern नुकसान कर सकता है। On-call engineer ने शायद किसी path को एक tenant तक सीमित करने के लिए rule बदला हो। Agent पुराना broad rule वापस रख देता है क्योंकि उसे pre-change snapshot याद था। उसने बिना देखे जानबूझकर किए गए human intervention को overwrite कर दिया।

Rollback request में original action द्वारा बनाई गई revision को expected state के रूप में शामिल करें। Gateway rollback तभी लागू करे जब provider अभी भी वही revision या agent द्वारा लिखी गई exact canonical configuration रिपोर्ट करे। Condition fail होने पर current configuration के साथ needs_review लौटाएँ। Agent conflict को human के सामने समझा सकता है, लेकिन खुद उसका समाधान नहीं करना चाहिए।

Rollback payload में parent action रखें:

{
  "request_id": "ffrb_01J8KR0Y8J2M",
  "operation": "rollback_boolean_flag",
  "parent_request_id": "ffchg_01J8KQ4W6D7P",
  "flag": {
    "project": "storefront",
    "environment": "production",
    "name": "checkout_v2"
  },
  "expected": {
    "value": false,
    "revision": "482"
  },
  "requested": {
    "value": true
  }
}

कुछ providers revisions या conditional update APIs उपलब्ध नहीं कराते। ऐसे में contested production flag के लिए automatic rollback को पर्याप्त सुरक्षित नहीं बनाया जा सकता। State पढ़ें, अंतर दिखाएँ और restoring write के लिए human approval माँगें। इस सीमा को स्वीकार करना उस भ्रम से बेहतर है जिसमें timestamp को concurrency control समझ लिया जाए।

Feature flag rollback और user state recovery को भी अलग रखें। Flag बंद करने से आगे का exposure रुक सकता है, लेकिन इससे data migrations, queued work या feature चलने के दौरान बनाए गए records वापस नहीं होते। जब कोई flag writes नियंत्रित करता हो, approval context में यह बात साफ़ लिखें।

Verbs, targets और credentials सीमित रखें

Agent के पास provider का administrator access नहीं, बल्कि flag actions की सीमित vocabulary इस्तेमाल करने की अनुमति होनी चाहिए। Provider token या API credential agent के context से बाहर रहना चाहिए।

Allowed verbs की सूची से शुरू करें। get_flag और list_flag_metadata reads हैं। set_boolean_flag एक narrow write है। set_rollout_percentage, replace_targeting_rule, create_flag, archive_flag और edit_segment के प्रभाव बहुत बड़े हैं, इसलिए इन्हें अलग operations होना चाहिए। Generic PATCH /flags/{id} action उपलब्ध न कराएँ और यह न मानें कि instructions agent को सावधान रखेंगी। Generic patch endpoints ऐसे fields को आमंत्रित करते हैं जिनकी किसी reviewer ने अपेक्षा नहीं की थी।

फिर targets सीमित करें। जहाँ provider ऐसी scope देता हो, credential को project और environment से बाँधें। Action gateway में उस खास job के लिए flag identifiers और operations की allowlist रखें। checkout_v2 का मालिक release agent organization के हर flag तक पहुँच नहीं चाहता।

अगर request unapproved verb, unknown environment, missing expected revision या disallowed target का प्रयास करे, तो provider तक पहुँचने से पहले ही fail हो जाना चाहिए। Validation deterministic होनी चाहिए। "केवल safe changes करें" जैसी natural-language policy agent को व्याख्या करने के लिए वाक्य देती है, लागू करने के लिए सीमा नहीं।

Sallyport HTTP credentials को अपने encrypted vault में रखता है और secret agent को दिए बिना API request करता है। इस pattern के लिए यह उपयोगी है, क्योंकि agent action माँग सकता है और credential controlling Mac पर रह सकता है।

Provider credential को agent की अपनी identity से अलग रखें। Provider audit trail में शायद केवल एक service account दिखे, लेकिन आपका action record agent session, source task और exact write को मंज़ूरी देने वाले मानव की पहचान कर सकता है। इससे revocation भी व्यावहारिक बनता है: legitimate human workflow में इस्तेमाल credential को rotate किए बिना एक agent run रोका जा सकता है।

"Incident के लिए बस अभी" API token को agent configuration file में न रखें। Agent context को transcripts, shell history, generated patches और tool arguments में आपकी अपेक्षा से कहीं अधिक आसानी से copy कर देते हैं। बाद में token rotate करने से वे copies मिटती नहीं हैं।

Control path को happy path नहीं, failures के साथ test करें

Feature flag integration तभी तैयार मानी जानी चाहिए जब आप यह test कर लें कि assumptions fail होने पर वह कैसे व्यवहार करती है। Happy path, value पढ़ना, approve करना, value update करना, बहुत कम साबित करता है।

Non-production environment पर controlled test चलाएँ और जानबूझकर ये outcomes उत्पन्न करें:

1. Agent के पढ़ने के बाद flag बदलें और मूल request भेजें। Gateway को stale expected revision अस्वीकार करनी चाहिए।
2. Lost response का simulation करने के बाद वही request ID दो बार भेजें। दूसरी call को नया mutation करने के बजाय पहला recorded outcome लौटाना चाहिए।
3. Approval अस्वीकार करें। Provider को कोई write नहीं मिलना चाहिए और audit record में अस्पष्ट timeout के बजाय rejection दिखना चाहिए।
4. Agent की action के बाद human से flag edit कराएँ, फिर automatic rollback का प्रयास करें। Rollback review के लिए रुक जाना चाहिए।
5. Pending request के दौरान agent session lock या revoke करें। Credential इस्तेमाल होने से पहले action fail होना चाहिए।

इन tests से एक सूक्ष्म design समस्या सामने आती है: कई टीमें केवल successful changes log करती हैं। Failed और denied requests भी उतने ही महत्वपूर्ण हैं। Denied request बताती है कि agent ने ऐसी scope आज़माई जिस तक उसकी पहुँच नहीं थी। Stale-write rejection बताती है कि system ने overwrite रोका। दोनों records समझाते हैं कि जब operator को provider state बदलने की उम्मीद थी, तब वह क्यों नहीं बदली।

Canonicalization भी test करें। दो JSON targeting rules का अर्थ एक ही हो सकता है, भले ही fields अलग क्रम में हों। अगर compare-and-set code raw JSON की तुलना करता है, तो false conflicts आएँगे। अगर normalization बहुत आक्रामक हो, तो semantic difference छूट सकता है। Provider model के लिए canonical representation चुनें, उसे record करें और reordered fields, omitted defaults तथा equivalent segment references के साथ test करें।

Provider success लौटाए लेकिन read-back fail हो, तब का path भी test करें। execution=accepted और observed=unknown record करें, पूरे request को successful न कहें। Agent कोई dependent change करने से पहले किसी व्यक्ति को provider state जाँचनी होगी।

Audit trail को disputed incident में भी टिकना चाहिए

एक उपयोगी feature flag record को संदेह करने वाले व्यक्ति के सवाल का जवाब देना चाहिए: "हमें कैसे पता कि बदलाव की यह कहानी बाद में edit नहीं की गई?" सामान्य application logs debugging के लिए पर्याप्त हो सकते हैं, लेकिन जब logging system तक बहुत लोगों की पहुँच हो, तब वे शायद ही यह सवाल सुलझाते हैं।

Append-only action events लिखें, जिनमें sequence number, timestamp, request envelope, authorization result, execution result और observed state हों। Request IDs और parent request IDs से संबंधित events जोड़ें। Hash chaining बाद में किए गए बदलाव को दिखाई देने योग्य बनाती है: हर event में अपनी सामग्री का digest और पिछले event का digest शामिल होता है। Verification क्रम से chain की जाँच करती है।

Hash chaining log को सच नहीं बनाती। इससे यह साबित नहीं होता कि request मंज़ूर करने वाले व्यक्ति ने उसे समझा था, और जो records कभी लिखे ही नहीं गए उन्हें यह वापस नहीं ला सकती। लेकिन chain को सुरक्षित रखकर और स्वतंत्र रूप से verify करके बाद में किए गए deletion या modification का पता चल सकता है। यही सही दावा है और बिना mechanism बताए log को "immutable" कहने से कहीं अधिक उपयोगी है।

Flag provider की native history को supporting evidence की तरह रखें, एकमात्र record की तरह नहीं। जहाँ provider उपलब्ध कराए वहाँ provider request IDs मिलाएँ। Action correlation_id को incident record या deployment change से मिलाएँ। जब कोई पूछे कि flag क्यों बदला, तो chat messages और human memory से इतिहास फिर से बनाने के बजाय decision तक पहुँचना संभव होना चाहिए।

Sallyport encrypted hash-chained audit log से session और individual-call records project करता है, और sp audit verify vault key के बिना offline chain जाँचता है। इससे team यह verify कर सकती है कि controlling action record internally consistent है, भले ही vault locked हो।

Denied actions और stale-write conflicts की समीक्षा सामान्य operational work का हिस्सा बनाएँ। ये noise नहीं हैं। Conflicts बढ़ने से पता चल सकता है कि कई automations उन्हीं flags की owner हैं। बार-बार denied target requests बता सकती हैं कि agent की task scope बहुत व्यापक या अस्पष्ट है।

पहले agent से change proposal बनवाएँ

सबसे सुरक्षित operational pattern सरल है: agent को inspect, diagnose और mutation draft करने दें, फिर controlled write path से उसे execute कराएँ। Proposal इतना विस्तृत होना चाहिए कि दूसरा engineer पूरा agent transcript पढ़े बिना उसे approve कर सके।

हर production request में agent से current observed state, exact desired state, expected revision, बदलाव से होने वाला लाभ, प्रभावित हो सकने वाली चीज़ें और rollback condition बताने को कहें। अगर वह ये तथ्य नहीं दे सकता, तो उसे write करने की अनुमति नहीं मिलनी चाहिए।

लंबा essay न माँगें। Complete request माँगें। दोनों में अंतर है। लंबी prose अक्सर छिपा देती है कि agent ने target environment जाँचा ही नहीं या current rule fetch नहीं किया। Structured envelope कमी तुरंत दिखा देता है।

इस discipline को अपनाने वाली teams पाती हैं कि बहुत-से proposed changes को execute करने की ज़रूरत ही नहीं होती। Agent देख सकता है कि flag में पहले से desired value है, failing cohort rule से match नहीं करता या असली remedy deployment rollback है। पहले पढ़ना और expected state दर्ज करना agent को केवल task पूरा दिखाने के लिए ceremonial write करने से रोकता है।

Feature flag live behavior पर तेज़ control है। AI agent को यह control तभी दें जब system उसका request record करे, human decision को exact mutation से बाँधे, stale overwrites रोके और provider द्वारा संग्रहीत state की पुष्टि करे। इससे कम व्यवस्था में आपका सबसे सुविधाजनक production switch ऐसे account से जुड़ा रहता है जिसे कोई पूरी तरह समझा नहीं सकता।