Skip to content
··9 मिनट पढ़ने का समय

Agencies को AI से वास्तव में जो चाहिए, वह ज़्यादा content नहीं है

मैं बार-बार AI tools को agencies को content volume बेचते देखता हूँ। लेकिन अगर आपने कभी real client relationships handle की हैं, तो आप जानते हैं कि असली मुश्किल problem trust है: isolation, permissions, context, और एक client की thinking को दूसरे client के काम में leak न होने देना।

मुझे तब समझ आया कि मैं गलत चीज़ बना रहा हूँ, जब मैंने खुद को यह imagine करते पकड़ा कि कोई agency owner "10 seconds में 50 LinkedIn post ideas" सुनकर excited हो रहा है।

ऐसा नहीं कि content ideas useless हैं। वे नहीं हैं।

लेकिन अगर आपने agencies के आसपास सच में time बिताया है, तो आपको पता है कि job का scary हिस्सा वह नहीं है।

Scary हिस्सा trust है।

वह account manager है जो सोच रहा है कि कहीं system गलती से Client A और Client B को mix न कर दे।

वह strategist है जो पूछ रहा है, "क्या मैं इसे किसी competitive account पर safely use कर सकता हूँ?"

वह agency owner है जो AI homepage वाले किसी भी sexy सवाल से कम sexy, लेकिन कहीं ज़्यादा important सवाल पूछ रहा है:

अगर यह चीज़ एक client की intelligence दूसरे client के काम में leak कर दे तो क्या होगा?

यह सवाल "यह कितने captions generate कर सकता है?" से कहीं ज़्यादा matter करता है।

मुझे लगता है AI software market का एक बड़ा हिस्सा अभी भी agencies को misunderstand करता है, क्योंकि वह actual work को misunderstand करता है। Agencies को words की shortage नहीं मारती। उन्हें complexity मारती है:

  • multiple clients
  • multiple brands
  • multiple internal roles
  • multiple approval layers
  • multiple versions of "किसे क्या देखने की permission है"

तो जब कोई AI vendor आकर कहता है, "Good news, अब आप और ज़्यादा content faster बना सकते हैं," तो मेरा एक हिस्सा पूछना चाहता है: क्या आपने कभी सच में agency workflow के अंदर बैठकर काम देखा है?

क्योंकि STRAŦUM बनाते-बनाते मेरे लिए यह और clear होता गया कि agencies को सबसे पहले ज़्यादा content नहीं चाहिए।

उन्हें trust के लिए बेहतर infrastructure चाहिए।

Agency problem volume नहीं है। Risk है।

मुझे लगता है इसे समझना आसान है, अगर आपने कभी real client work के लिए responsibility ली हो।

जब आप सिर्फ एक brand handle कर रहे होते हैं, life simple होती है। आपकी notes आपकी notes हैं। आपकी positioning work एक lane में रहती है। आपकी mistakes painful तो होती हैं, लेकिन कम से कम local होती हैं।

Agencies वहाँ नहीं रहतीं।

Agencies juggling करती हैं:

  • अलग-अलग brand voices
  • अलग-अलग categories
  • अलग-अलग approval chains
  • success की अलग-अलग definitions
  • ऐसे clients जो शायद आपस में compete भी करते हों

इसका मतलब यह है कि mistake की cost सिर्फ "हमने mediocre draft बना दिया" नहीं होती।

कई बार cost यह होती है:

  • हमने गलत चीज़ गलत client को भेज दी
  • हमने गलत workspace में गलत context expose कर दिया
  • हमने platform को unsafe feel करवाया
  • अब client सोच रहा है कि backstage में और क्या sloppy है

और एक बार client ने वह आख़िरी सवाल पूछ लिया, तो आप पहले ही expensive territory में पहुँच चुके होते हैं।

इसीलिए जब agency AI सिर्फ output examples के ज़रिए बेची जाती है, तो मैं skeptical हो जाता हूँ। Generated content की demo यह साबित करती है कि model content generate कर सकती है। Fine. लेकिन agencies के लिए ज़्यादा important proof architectural होता है।

मुझे दिखाओ:

  • data कहाँ रहती है
  • client context कैसे isolate होती है
  • किसे क्या access मिलता है
  • approvals built-in हैं या नहीं
  • क्या एक client का काम दूसरे को contaminate कर सकता है

यही वह product story है जिसकी agencies को सच में परवाह होती है, भले ही launch video में वह कम मज़ेदार लगे।

मुझे लगता है मेरा advertising background होने से यह बात जल्दी समझ आई

शायद advertising से आने की वजह से मैंने कभी पूरी तरह इस story पर विश्वास नहीं किया कि agencies के लिए "content ही bottleneck है।"

गलत मत समझिए, agencies content produce करती हैं। बहुत करती हैं। और हाँ, वहाँ real efficiency gains भी हैं।

लेकिन agency work को hard बनाने वाली चीज़ आम तौर पर first draft की कमी नहीं होती।

Hard हिस्सा वह operating environment है जो draft के आसपास होता है।

किसने review किया? यह किस client के लिए है? किस context ने यह recommendation shape की? क्या यह सही brand constraints के साथ generate हुई? क्या किसी ने गलत assumptions reuse कर लीं? किसे approve करने की authority है?

अगर आप in-house हैं, तो इसमें से कुछ अब भी matter करता है।

अगर आप agency हैं, तो यह सब हर दिन matter करता है।

इसीलिए STRAŦUM के शुरुआती life में मैंने एक थोड़ा unreasonable decision लिया: मैंने multi-tenancy लगभग तुरंत build करनी शुरू कर दी। Day 2 पर, basically. पीछे मुड़कर देखता हूँ तो वह disciplined भी थी और थोड़ा insane भी, इस पर निर्भर करता है कि आप कितनी charity दिखा रहे हैं।

उस वक्त मेरे पास बस एक working agent थी। इतनी जल्दी client isolation build करना premature feel हो रहा था।

लेकिन वही सही निकला।

क्योंकि एक बार जब आप agencies को साफ़ देखते हैं, तो आपको realize होता है कि वे "SMEs with more users" नहीं हैं। उनका operating model fundamentally अलग होता है।

वह दिन जब मुझे समझ आया कि org_id मुझे नहीं बचाएगी

मेरी पहली multi-tenancy version classic optimistic-builder version थी।

हर चीज़ में org_id जोड़ दो। Policies लिख दो। Filters पर trust कर लो। और काम done मान लो।

यह approach surprisingly बहुत software में काम भी कर जाती है। और यह आपको comforting illusion भी देती है कि आपने isolation solve कर लिया, जबकि असल में आपने सिर्फ basic scoping solve की होती है।

STRAŦUM के लिए यह enough नहीं था।

क्योंकि agencies के पास सिर्फ एक organizational layer नहीं थी। Organization के नीचे clients थीं। और हर client को अपना context, अपने outputs, अपनी history, और अपनी safety boundaries चाहिए थीं।

मतलब मैं दो अलग data models को एक mental shortcut में fit करने की कोशिश कर रहा था:

  • SME: एक org, एक business context
  • Agency: एक org, उसके नीचे multiple client contexts

आप थोड़ी देर तक इसे application logic में fake कर सकते हैं। लोग करते हैं। लेकिन जितना ज़्यादा मैंने इसे देखा, उतना ज़्यादा मुझे realize हुआ कि मैं ऐसा system बना रहा हूँ जो बाहर से correct लग सकती है, लेकिन structurally ज़रूरत से ज़्यादा trusting है।

यह खराब combination है।

इसे सही करने के लिए rebuild करनी पड़ी। Separate routing. Separate schema logic. Database level पर ज़्यादा guardrails. Context handling को ज़्यादा explicit बनाना। और "बस हर जगह सही filter लगाना याद रखना" पर कम depend करना।

Annoying? हाँ।

Worth it? यह भी हाँ।

हालाँकि honest रहूँ — rebuild के बाद भी, कुछ हफ़्ते बाद मुझे एक और gap मिला जहाँ specific clients को assign किए गए users फिर भी एक अलग query path के ज़रिए दूसरे clients का data देख सकते थे। Architecture बेहतर थी लेकिन complete नहीं। मैं अब भी पूरी तरह confident नहीं हूँ कि सब कुछ airtight है।

क्योंकि agency trust किसी developer की 11:30 PM पर हर if/else branch याद रखने की ability पर depend नहीं करनी चाहिए।

AI trust problem को बेहतर नहीं, और बदतर बनाती है

मुझे लगता है category अभी भी इस हिस्से को understate करती है।

AI सिर्फ agency work के ऊपर एक और UI layer नहीं है। यह risk profile बदल देती है क्योंकि अब आपके पास ऐसा system है जो context को synthesize कर सकती है, सिर्फ store नहीं।

यह powerful है।

और इसी वजह से bad boundaries unacceptable हैं।

अगर AI system के पास wrong context का access हो, तो वह सिर्फ raw data expose नहीं करती। वह उसे remix भी कर सकती है। वह चुपचाप Client A के insights को Client B की strategy में leak कर सकती है। वह isolation mistakes को polished-looking outputs में बदल सकती है, जो honestly visible bug से भी worse है क्योंकि पकड़ना मुश्किल होता है।

इसीलिए general-purpose AI tools मुझे agency environments में nervous करती हैं, खासकर जब लोग उन्हें casually multiple accounts में use करना शुरू कर देते हैं।

कुछ समय तक आप इससे बच निकलेंगे।

फिर एक दिन कोई note करेगा कि language कुछ जानी-पहचानी लग रही है।

या किसी recommendation में competitor framework आ जाएगी जो उस workspace में होनी ही नहीं चाहिए थी।

या client कुछ ऐसा देख लेगा जिससे उसे यह doubt हो जाए कि आपके systems compartmentalized हैं भी या नहीं।

और एक बार यह doubt relationship में घुस गया, तो आप content workflow fix नहीं कर रहे होते। आप belief repair कर रहे होते हैं।

कुछ extra blog captions के साथ उसके लिए good luck.

Agencies को वास्तव में क्या चाहिए

अगर मैं AI theater हटा दूँ, तो मुझे लगता है agencies को कुछ unglamorous चीज़ें कहीं ज़्यादा urgently चाहिए:

1. Client-safe context isolation

सिर्फ account switching नहीं।

सिर्फ folders नहीं।

सिर्फ "we take privacy seriously" वाली copy नहीं।

Real separation — database level पर, application level पर नहीं। मेरा मतलब है separate schemas या separate routing, न कि एक shared table जिसमें client_id column हो और उम्मीद कि हर query सही से filter करेगी।

2. Role-aware permissions

अलग-अलग लोगों को अलग-अलग level की access चाहिए:

  • strategist
  • account manager
  • approver
  • client stakeholder
  • admin

इसके बिना tool demo में "collaborative" लग सकती है और reality में chaotic।

3. Approval workflows

Agencies solo creators नहीं होतीं जो ideas सीधे दुनिया में फेंक दें। यहाँ drafts, comments, reviews, approvals, revisions, और politics होती है। बहुत politics :P

अगर AI system इसका सम्मान नहीं करती, तो वह agency work का सम्मान नहीं करती।

4. Right boundary के भीतर shared memory

यह बहुत matter करता है।

किसी एक client context के भीतर system को समय के साथ ज़रूर smarter होना चाहिए। वहीं AI useful बनती है। लेकिन यह compounding सही fence के भीतर होनी चाहिए, पूरे काम में indiscriminately नहीं।

5. Execution से पहले strategic intelligence

फिर से, मैं anti-content नहीं हूँ। बस पूरी story को content-first बना देने के खिलाफ हूँ।

Agencies को मदद चाहिए समझने में:

  • client को क्या कहना चाहिए
  • client को किस बात पर जोर देना चाहिए
  • competitive landscape में क्या हो रहा है
  • strategy कहाँ weak है
  • team को किसी recommendation के आसपास कैसे align करना है

यह generic deliverables का एक और ढेर produce करने से कहीं ज़्यादा valuable है।

इसी वजह से STRAŦUM वैसी दिखती है जैसी दिखती है

STRAŦUM में बहुत-सी product decisions इस lens से देखेंगे तो ज़्यादा sense बनाएँगी।

Why progressive learning?

क्योंकि agencies पहले से ही context बहुत बार repeat करती हैं।

Why multi-tenant routing?

क्योंकि client context सिर्फ polite suggestion नहीं हो सकती।

Why approvals and collaboration?

क्योंकि agency work कोई एक इंसान और bot के बीच vacuum में होने वाली chat नहीं है।

Why intelligence over execution?

क्योंकि agencies को अधिक noise पैदा करने के लिए usually पैसे नहीं मिलते। उन्हें confidence, direction, और clients के लिए better decisions create करने के लिए pay किया जाता है।

मैं उनके लिए यही तरह का AI product बनाना चाहता हूँ।

वह नहीं जो कहे: "देखो, अब तुम कितनी faster churn कर सकते हो।"

वह जो कहे: "देखो, अब तुम्हारा strategic work कितना safer और sharper हो सकता है।"

मैं यह नहीं कह रहा कि मैंने यह सब सही किया। मैं कह रहा हूँ कि इन problems ने specific architectural decisions force कीं जो ज़्यादातर general-purpose AI tools को अभी तक लेनी नहीं पड़ीं — या उन्होंने लेने का चुनाव नहीं किया।

वह बात जो मैं चाहता हूँ कि ज़्यादा AI vendors admit करें

Agency buyers अक्सर एक साथ दो products evaluate कर रहे होते हैं:

  1. demo वाला product
  2. future problem जो यह product create कर सकता है

इसीलिए glossy AI output alone convincing नहीं होती।

Buyer सिर्फ यह नहीं पूछ रहा होता: "क्या यह हमारी मदद कर सकती है?"

वह यह भी पूछ रहा होता है: "क्या यह बाद में हमें hurt कर सकती है?"

और अगर आप उस दूसरे सवाल का अच्छा जवाब नहीं दे सकते, तो आपका beautiful generated output ज़्यादातर decoration है।

मुझे नहीं लगता agencies को और decoration चाहिए।

मुझे लगता है उन्हें ऐसे systems चाहिए जिन पर वे clients के सामने trust कर सकें।

यह कहीं ज़्यादा hard product है।

और मेरे हिसाब से कहीं ज़्यादा honest भी।

मेरी तरफ़ से बस इतना।

मैं खास तौर पर agency folks से इस पर सुनना चाहूँगा। जो AI tooling आपने देखी है, उसने risk सच में reduce किया है, या बस आपकी team के content volume को बढ़ाया है जबकि असली operational headaches वहीं की वहीं हैं?

Cheers, Chandler

पढ़ना जारी रखें