एक agency AI stack वे पाँच layers हैं जिन पर एक एजेंसी अपना AI काम चलाती है: client memory, orchestration, production, review और measurement। यह subscriptions से भरा एक folder नहीं है। Stack इसलिए है ताकि एजेंसी कम accountable हुए बिना तेज़ हो, और ख़रीदने के बजाय बनाने लायक़ अकेली layer वही है जो एजेंसी अपने clients के बारे में जो जानती है उसे रखती है।
मैंने agencies को एक AI कहानी में अपना रास्ता ख़रीदते और एक ऐसी tool list के साथ ख़त्म होते देखा है जो एक pitch में प्रभाव डालती है और delivery में उलझन पैदा करती है। Stack का सवाल असल में technology की पोशाक पहने एक operating-model सवाल है, इसलिए ख़र्च करने से पहले दोनों को अलग करना worth है।
Tool count ग़लत frame क्यों है
Default instinct tools गिनना है। बारह platforms, पाँच models, एक design tool, एक scraping tool, एक reporting tool। Tool count दिखाना आसान है और ज़्यादातर अर्थहीन, क्योंकि वही subscriptions वाली दो agencies के results बिलकुल अलग हो सकते हैं। एक ने उन्हें एक client-सत्य के साथ एक workflow में जोड़ा है; दूसरे के पास बारह tabs हैं और कोई memory नहीं।
जो stack मायने रखता है वह इससे तय होता है कि layers के बीच क्या बहता है, इससे नहीं कि हर एक में क्या बैठता है। अगर एक brief एक बार आता है और एक plan, एक activation, एक report और एक learning produce करता है जो अगले brief को feed करती है, तो आपके पास एक stack है। अगर हर tool शून्य से शुरू करता है, तो आपके पास एक ढेर है। वह फ़र्क़ पूरा खेल है, और यह एक procurement spreadsheet में अदृश्य है।
पाँच layers
हर काम करने वाला agency stack जो मैंने देखा वह उन्हीं पाँच layers में बैठता है। वे products नहीं हैं; वे किए जाने वाले काम हैं, और आप हर एक को size के हिसाब से build, buy और process के अलग मिश्रण से भर सकते हैं।
| Layer | काम | Buy या build |
|---|---|---|
| Client memory | Briefs, पिछला काम, brand rules, results रखना | Build — यही moat है |
| Orchestration | Work route करना, context रखना, loop चलाना | Buy, फिर configure |
| Production | Copy, creative, plans, code लिखना | Buy — सबसे तेज़ चलने वाली layer |
| Review | Errors पकड़ना, brand enforce करना, facts check करना | Rubric build करें, tooling buy करें |
| Measurement | Output को outcomes से ईमानदारी से जोड़ना | Data के लिए buy, frame build |
क्रम मायने रखता है। Memory सब के नीचे बैठती है, क्योंकि हर दूसरी layer ज़्यादा उपयोगी होती है जब वह पढ़ सके कि एजेंसी पहले से क्या जानती है। Review production के ऊपर बैठता है, क्योंकि बिना review की production वह तरीक़ा है जिससे agencies आत्मविश्वासी ग़लतियाँ speed पर भेजती हैं।
Layer एक: client memory
यह वह layer है जिसे मैं पहले बनाऊँगा और सबसे सख़्ती से defend करूँगा। यह वह जगह है जहाँ एजेंसी हर client की जमा समझ रखती है: brief history, brand rules, जीतने और हारने वाला creative, measurement readouts, decisions और वे क्यों लिए गए। इसमें से कुछ भी विदेशी नहीं है। यह सब copy करना मुश्किल है, क्योंकि यह उस काम के लिए specific है जो आपने किया।
एक generic model category जानता है। आपके stack को आपका client जानना चाहिए। वह फ़र्क़ कारण है कि एक एजेंसी एक दोपहर में वह कर सकती है जो एक client की in-house tooling बिलकुल नहीं कर सकती, और जितने महीने आप इसे रखते हैं उतना compound करती है। अगर आप यह लंबा version चाहते हैं कि यह layer क्यों टिकती है, तो मैंने अलग से client-memory data moat पर लिखा है।
Layer दो: orchestration
Orchestration वह plumbing है जो एक काम को stack से गुज़ारती है जबकि context साथ ले जाती है। यह ऐसे सवालों का जवाब देती है: जब एक brief उतरे, क्या चले, किस क्रम में, किस memory के साथ, और कुछ भेजे जाने से पहले एक व्यक्ति कहाँ देखे। छोटी agencies में यह अक्सर एक व्यक्ति और एक checklist है, और वह एक वैध जवाब है। बड़ी में यह एक workflow tool या एक पतला internal app है।
Trap है एक orchestration platform ख़रीदना इससे पहले कि आप अपनी workflow जानें। Software ख़ुशी से एक ऐसी process encode करेगा जिसे आपने design नहीं किया, जिससे agencies अपनी मौजूदा गड़बड़ को automate कर देती हैं। Loop को पहले काग़ज़ पर design करें, एक महीना हाथ से चलाएँ, और तभी इसे उठाने के लिए कुछ ढूँढें।
Layer तीन: production
Production commodity बनती layer है, और वह जहाँ ख़रीदना लगभग हमेशा बनाने से जीतता है। Copy लिखने, creative generate करने, plans assemble करने और code लिखने वाले models और tools किसी भी एजेंसी के internally keep up कर पाने से तेज़ सुधर रहे हैं। यहाँ आपका काम engine बनाना नहीं; यह कुछ engine चुनना और उन्हें गहराई से सीखना है।
हर हफ़्ते एक नया generator जोड़ने की इच्छा का विरोध करें। Production में depth breadth को हराती है, क्योंकि casual तरीक़े से इस्तेमाल किए गए tool और एक tuned prompt और ज्ञात failure mode वाले tool के बीच quality का फ़र्क़ ख़ुद tools के बीच के फ़र्क़ से बड़ा है। दो-तीन चुनें, लिखें कि वे किसमें अच्छे और बुरे हैं, और उस सूची को तिमाही revise करें।
जिस trap पर नज़र रखें वह वह tool है जो तेज़ लगता है और चुपचाप team का judgement कमज़ोर करता है — एक failure जिस पर मैंने तेज़-पर-judgement-कमज़ोर-करने वाले tool के trap में लिखा। उस तरह का tool अपनी subscription से ज़्यादा महँगा है, क्योंकि drafting समय की बचत उन errors की तरह वापस आती है जिन्हें किसी ने नहीं पकड़ा।
Layer चार: review और QA
Review वह जगह है जहाँ एक एजेंसी ख़ुद को अलग करती है, क्योंकि यह वह layer है जिसके लिए clients पैसे देते हैं और जिसे ज़्यादातर stacks neglect करते हैं। AI production को सस्ता और review को महँगा बनाता है, जिसका मतलब है कि bottleneck review step पर चला जाता है जिस पल आप scale करते हैं। बिना review layer वाला stack scale नहीं करता; यह review debt जमा करता है जब तक कुछ शर्मनाक चला न जाए।
Rubric बनाएँ, भले tooling ख़रीदें। क्या on-brand गिना जाता है, क्या एक factual claim जिसे source चाहिए, क्या एक hard stop जिससे पहले कुछ भी किसी client के करीब न जाए। Rubric एजेंसी का judgement है जो स्पष्ट किया गया है, और यह वह चीज़ है जो एक junior operator को senior-quality check चलाने देती है बिना एक senior को उसके कंधे पर बिठाए।
Layer पाँच: measurement
Measurement loop बंद करती है, और उसका काम volume के बजाय ईमानदारी है। Stack को बता पाना चाहिए कि किसी काम को क्या बदलना था, असल में क्या हिला, और आप कितने आश्वस्त हैं कि काम ने उसे पैदा किया। यह outputs गिनने से मुश्किल है, और यही एक ऐसी एजेंसी को अलग करती है जो अपनी fees defend कर सकती है उससे जो सिर्फ़ activity दिखा सकती है।
Data plumbing ख़रीदें, क्योंकि attribution data उन platforms में रहता है जिन्हें आप control नहीं करते। Frame बनाएँ, क्योंकि frame वहाँ है जहाँ judgement रहता है। एक पतला, अनुशासित frame — एक business outcome, कुछ leading signals, एक ईमानदार नोट कि आप क्या attribute कर सकते हैं और नहीं — बीस-metric dashboard को हराता है जिसे कोई नहीं पढ़ता।
Build को कैसे sequence करें
Memory और हाथ से चलने वाले loop से शुरू करें। Client knowledge को एक जगह लाएँ, एक काम जो steps लेता है वे लिखें, और उसे मैन्युअल चलाएँ जब तक steps बदलना बंद करें। फिर production tools को उन steps पर जोड़ें जो सबसे ज़्यादा चुभते हैं। Review तब जोड़ें जब production review pressure बनाने लायक़ तेज़ हो। Measurement तब जोड़ें जब आपके पास मापने लायक़ कुछ हो।
वह क्रम पहले महीने धीमा लगता है और एक साल का rework बचाता है, क्योंकि हर layer तब जोड़ी जाती है जब उसके नीचे की layer स्थिर हो। जो agencies struggle करती हैं वे आमतौर पर वे हैं जिन्होंने पहले production ख़रीदा, फिर memory और review को बग़ल में जोड़ने की कोशिश की। Stack को एजेंसी जो जानती है उससे ऊपर की तरफ़ बढ़ना है।
एक किया हुआ stack review
साल में एक बार, stack को एक असली काम को उससे शुरू से आख़िर तक गुज़ारकर audit करें। शुरू करें जहाँ एक brief आता है, उसे orchestration और production से follow करें, नाम लें कि एक व्यक्ति कहाँ review करता है, और measurement readout पर ख़त्म करें। हर handoff पर, दो सवाल पूछें: context आगे चला या नहीं, और क्या एक नया joiner इसे बिना पूछे follow कर सकता? अगर context दो layers के बीच खो जाए, तो वही पहले ठीक करने वाली layer है, क्योंकि stages के बीच memory leak होना वह चीज़ है जो पाँच tools को पाँच असंबंधित tasks में बदल देती है। अगर कोई एक result को उस brief तक trace न कर सके जिसने उसे बनाया, तो measurement layer सजावट है। Review में एक दोपहर लगती है और यह एक subscription audit से ज़्यादा बताती है, क्योंकि यह सूची के बजाय connections test करती है।
FAQ
क्या हमें अपने models चाहिए?
लगभग कभी नहीं। एक agency stack का value memory, orchestration और judgement में है, training में नहीं। Fine-tuning तभी worth है जब आपके पास एक बड़ा, स्थिर, proprietary dataset हो और एक ऐसा task जिसे general models ख़राब handle करते हैं। ज़्यादातर agencies के पास न तो है, और उन्हें effort memory layer पर लगाना चाहिए।
कितना build करें बनाम buy?
वे layers ख़रीदें जो तेज़ सुधर रही हैं और जिन्हें दूसरी firms भी इस्तेमाल करती हैं, क्योंकि उनमें आप बाज़ार से ज़्यादा invest नहीं कर सकते। वे layers बनाएँ जो आपका specific knowledge रखती हैं और आपका specific judgement encode करती हैं, क्योंकि वे अकेली हैं जिन्हें competitor ख़रीद नहीं सकता। Memory और review build layers हैं; production और data buy layers हैं।
सबसे बड़ी stack ग़लती क्या है?
Tools जोड़ना इससे पहले कि workflow design करें जो उन्हें जोड़ती है। यह progress जैसा लगता है, एक renewal list produce करता है, और एजेंसी को वही bottlenecks plus ज़्यादा subscriptions के साथ छोड़ देता है। Stack को operating model follow करना चाहिए, कभी उलटा नहीं।
इन सब में client data कैसे सुरक्षित रखें?
Memory layer को boundary मानें। Client data आपके controlled store में रहता है, tools सिर्फ़ वह पढ़ते हैं जो एक task को चाहिए, और आप एक record रखते हैं कि क्या अंदर गया और क्या बाहर आया। यह governance की बातचीत है उतनी ही जितनी technical, और इसे stack scale होने से पहले तय करना चाहिए।
Short version
एक agency AI stack पाँच layers हैं — client memory, orchestration, production, review और measurement — जो operating model के इर्द-गिर्द जोड़ी जाती हैं। Commodity बनती layers ख़रीदें, वह एक बनाएँ जो आपका ज्ञान रखती है, और stack को memory से ऊपर की तरफ़ बढ़ाएँ। Execution guide वह workflow cover करता है जिसे यह stack serve करता है, और for agencies track इसे agency operating model के ज़रिए चलाती है।
अगर आपकी एजेंसी ने stack उलटे तरीक़े से बनाया — पहले tools — तो मैं सुनना चाहूँगा कि किसने redesign मजबूर किया।
शुभकामनाओं सहित, Chandler
यह लेख हिंदी में उपलब्ध है, लेकिन कोर्स सामग्री (वीडियो, टेम्पलेट्स और सपोर्टिंग गाइड्स) अंग्रेज़ी और जापानी में उपलब्ध है। यह साइट 13 भाषाओं में उपलब्ध है।