मुख्य नेविगेशन

ChatGPT Apps SDK के साथ शिपिंग में हमने क्या सीखा

ChatGPT Apps SDK के साथ शिपिंग करने से हमें यह समझ आया कि इसका आर्किटेक्चर कब सही रहता है और कब ज़्यादा कंट्रोल की ज़रूरत होती है.

एग्ज़ीक्यूटिव समरी

  • अगर आपको जल्द ही ChatGPT में कोई वर्कफ़्लो लाना है, या कस्टम एजेंट स्टैक में इन्वेस्ट करने से पहले अपने टूल्स को ChatGPT में आज़माना है, तो Apps SDK एक अच्छा ऑप्शन है. लेकिन अगर आप एजेंट के काम करने के हर स्टेप पर पूरा कंट्रोल चाहते हैं, तो आम तौर पर यह सही ऑप्शन नहीं है.

  • जब आप ChatGPT को मुख्य सर्फ़ेस के तौर पर चाहें और आप पूरा चैट प्रोडक्ट बनाने की जगह बस टूल्स के साथ थोड़ा-बहुत UI चाहते हों, तो Apps SDK चुनें. लेकिन अगर आपको फ़्लो, मेमोरी, प्रॉम्प्ट और डेटा में होने वाले बदलावों पर कड़ा कंट्रोल चाहिए, तो अपना एजेंट स्टैक बनाना बेहतर है.

  • Apps SDK उन प्रोडक्ट्स के लिए सही है जिनमें चैट के साथ कुछ छोटे UI स्टेप्स हों. इससे आप जल्दी शिप करते हैं, लेकिन इसके बदले कुछ कंट्रोल छोड़ना पड़ता है.

  • हमें साफ़ टूल्स, विजेट का ठीक से चलना, और अगले स्टेप्स का साफ़-साफ़ पता होना, सबसे ज़्यादा काम आए. फ़्लो तय करने के लिए हमने इन्हीं पर भरोसा किया, LLM पर नहीं. मॉडल तब सबसे ज़्यादा काम आया जब उसे सिस्टम के पहले से तय किए गए नतीजों को समझाना था.

  • नीचे बताया गया है: चुनने का क्या तरीका होना चाहिए, क्या काम आया और क्या नहीं.

ज़्यादातर टीमें अभी भी AI पायलट चला रही हैं या AI को ऐसे छोटे कामों में इस्तेमाल कर रही हैं जिनमें जोखिम और फ़ायदा दोनों कम हैं. बहुत कम टीमें ऐसा बिज़नेस-क्रिटिकल प्रोडक्ट लॉन्च करती हैं जिसे लोग हर हफ़्ते इस्तेमाल करते हैं. अगर आपका लक्ष्य पूरा असिस्टेंट खुद बनाने के बजाय ChatGPT के अंदर अपना प्रोडक्ट लाना है, तो Apps SDK इस अंतर को कम करने का एक तरीका है.

हमने Apps SDK का इस्तेमाल क्यों किया

हमारी सीख एक क्लाइंट के साथ किए गए काम से आई है. उनकी ज़रूरतों के हिसाब से ChatGPT मुख्य सर्फ़ेस होना चाहिए था और ऐसा तेज़ तरीका चाहिए था जिसमें पूरा कस्टम चैट प्रोडक्ट बनाने के लिए पैसे न लगाने पड़ें.

इन ज़रूरतों को देखते हुए Apps SDK सही रहा, क्योंकि क्लाइंट को चाहिए था:

  • अलग चैट प्रोडक्ट बनाना और होस्ट करना न पड़े—वे ChatGPT के अंदर यूज़र्स तक पहुँचना चाहते थे, कोई अलग असिस्टेंट नहीं बनाना चाहते थे.

  • चैट के साथ छोटे, खास कामों के लिए UI—कुछ छोटे और फ़ोकस्ड विजेट स्टेप्स, न कि पूरे वर्कफ़्लो के अंदर एक दूसरा पूरा प्रोडक्ट.

  • MCP टूल्स के ज़रिए बैकएंड का काम—स्टैंडर्ड टूल कॉलिंग, न कि शुरू से अंत तक अपना एजेंट रनटाइम.

  • ChatGPT के अंदर डिस्कवरी—यूज़र्स को यह वर्कफ़्लो वहीं मिलना चाहिए जहाँ वे पहले से काम करते हैं.

काम करते समय हमने क्लाइंट के साथ इन फ़ैसलों को वैलिडेट किया. लेकिन एक बात बनी रहती है: जब ChatGPT सेशन चला रहा हो, तो बाहर के पूरे रनटाइम का कंट्रोल आपके पास नहीं रहता. आप उसे गाइड कर सकते हैं, लेकिन पूरा कंट्रोल नहीं रख सकते.

Apps SDK से आपको क्या मिलता है

Apps SDK से बना ऐप तीन चीजों को जोड़ता है:

  1. ChatGPT का एजेंट रनटाइम

  2. आपके MCP टूल्स

  3. आपका विजेट UI

असल में फ़्लो ऐसे चलता है:

  1. यूज़र ChatGPT से कुछ करने को कहते हैं.

  2. ChatGPT आपके किसी MCP टूल को कॉल कर सकता है.

  3. आपका सर्वर टूल का एक स्ट्रक्चर्ड नतीजा देता है.

  4. ChatGPT उस नतीजे को पढ़कर अगला स्टेप तय करता है: और टूल कॉल करना, यूज़र को जवाब देना या दोनों. अगर उस टूल के साथ कोई विजेट जुड़ा है, तो वह इसी टर्न में दिख सकता है.

  5. यूज़र चैट या विजेट में काम जारी रखते हैं (जैसे कुछ लिखकर, कोई ऑप्शन चुनकर या विजेट से टूल कॉल करके). इससे थ्रेड अपडेट होता है; ChatGPT अगला टर्न चलाता है और स्टेप 2–4 फिर दोहराए जाते हैं, जब तक काम पूरा न हो जाए.

चैट, बैकएंड के काम और छोटे UI स्टेप्स का यही मेल Apps SDK की खासियत है. लेकिन इसका मतलब यह भी है कि सबसे मुश्किल हिस्से चैट, टूल्स और UI के बीच के कनेक्शन हैं.

आपको चैट UI, टूल वायरिंग, ऑथ के पैटर्न या विजेट का बेसिक सेटअप खुद से नहीं बनाना पड़ता. कई प्रोडक्ट्स के लिए इससे काफ़ी बिल्ड टाइम बच सकता है, जिससे आप अपना ज़्यादा समय डोमेन लॉजिक और गार्डरेल्स पर लगा सकते हैं.

ChatGPT के अंदर बनाना और अपना एजेंट चलाना एक जैसा नहीं है. इस प्रोजेक्ट में मुश्किल हिस्सा प्रॉम्प्ट के तरीके नहीं थे. मुश्किल यह था कि टूल्स, विजेट्स और अगले स्टेप्स इतने साफ़ हों कि मॉडल और UI एक ही दिशा में काम करें.

कैसे चुनें

Apps SDK आपके आम फ़्रंटएंड से अलग तरह का प्रोडक्ट देता है, इसलिए यह समझना ज़रूरी है कि यह किन सिनारियो के लिए सही है.

Apps SDK तब इस्तेमाल करें जब आप:

  • ChatGPT में कोई वर्कफ़्लो जल्दी शिप करना चाहते हों.

  • ChatGPT को बातचीत चलाने देना चाहते हों.

  • नेचुरल लैंग्वेज को कुछ फ़ोकस्ड UI स्टेप्स के साथ जोड़ना चाहते हों.

  • अपना चैट इंटरफ़ेस, एजेंट कंटेनर और डिस्कवरी खुद बनाने से बचें.

आखिरी बात तब खास मायने रखती है, जब आपके यूज़र्स पहले से ChatGPT में काम कर रहे हों.

अपना एजेंट तब बनाएँ जब आपको चाहिए:

  • ऐसा तय स्टेप-बाय-स्टेप फ़्लो जिसे आप कोड के ज़रिए लागू कर सकें.

  • अपना कस्टम UI और ऐसा कन्फ़र्मेशन फ़्लो जिसे शुरू से आखिर तक आप खुद संभालें.

  • अपना मेमोरी और स्टेट मॉडल.

  • ऐसा व्यवहार जिसका हर बार अनुमान लगाया जा सके.

  • एजेंट के ट्रेसेज़, लॉग्स और मेट्रिक्स.

अगर प्लानर, सिस्टम प्रॉम्प्ट्स और पूरा वर्कफ़्लो ही आपके प्रोडक्ट का हिस्सा हैं, तो कस्टम स्टैक आम तौर पर आपके लिए बेहतर रहेगा.

फ़र्क एक नज़र में

सवाल

ChatGPT Apps SDK

आपके अपने एजेंट्स

यूज़र का अनुभव कहाँ होता है?

ChatGPT के अंदर

आपके प्रोडक्ट में

बातचीत के स्टेप्स कौन चलाता है?

ChatGPT, आपके टूल्स और UI के हिसाब से काम करते हुए

आपका एजेंटिक सिस्टम

आपको कितना UI बिल्ड करना पड़ता है?

चैट में फ़ोकस्ड विजेट्स

जितना आपको चाहिए

प्रॉम्प्ट्स पर कितना कंट्रोल है?

सीधा कंट्रोल नहीं

पूरा कंट्रोल

तय और बार-बार चलने वाले फ़्लो बनाना कितना आसान है?

इसके लिए सावधानी से डिज़ाइन करना पड़ता है

कोड में लागू करना आसान है

पहली बार शिप करने में लगने वाला समय

अक्सर कम

शुरुआत में अक्सर ज़्यादा समय

प्लेटफ़ॉर्म का कितना काम आपको खुद करना पड़ता है?

कम

ज़्यादा

बाद में दिशा बदलने की कितनी गुंजाइश रहती है?

कम

ज़्यादा

हमारे क्लाइंट के साथ किए गए काम में बार-बार एक ही बात सामने आई: कंट्रोल. एक तरफ़ तेज़ी और ऐसा प्लेटफ़ॉर्म था जिसे यूज़र्स पहले से जानते थे; दूसरी तरफ़ रनटाइम पर पूरा कंट्रोल नहीं था. जब क्लाइंट ने पूरे स्टैक का कंट्रोल रखने के बजाय ChatGPT में ही यूज़र्स तक पहुँचना ज़्यादा ज़रूरी माना, तो उन्होंने यही समझौता स्वीकार किया.

जहाँ मुश्किल आती है

ऊपर से आसान लगता है: यूज़र पूछता है, टूल चलता है, डेटा वापस आता है और जहाँ कुछ चुनने की ज़रूरत होती है वहाँ विजेट दिखता है.

असल मुश्किल एक हिस्से से दूसरे हिस्से तक जानकारी पहुँचाने में थी. विजेट सिर्फ़ दिखाने के लिए नहीं होता. स्क्रीन पर आने के बाद वह मॉडल को मिलने वाली जानकारी और उसके अगले काम को बदल देता है. इसलिए विजेट के एक्शन को सिर्फ़ चैट का हिस्सा न मानें, बल्कि उन्हें नाम वाले इवेंट्स की तरह रखें.

इस प्रोजेक्ट में इस्तेमाल किया गया स्टैक सीधा था: FastMCP, Pydantic, React और TypeScript. इन्हें एक साथ जोड़ने में कोई खास परेशानी नहीं हुई. असली काम यह तय करना था कि मॉडल, टूल्स और UI अगले स्टेप के बारे में एक ही तरह से समझें.

क्या काम आया

हर हैंडऑफ़ को साफ़ रखें

हमने टूल के नतीजे को सिर्फ़ बैकएंड से आया डेटा मानना बंद किया. हर नतीजे को हमने एक हैंडऑफ़ की तरह रखा.

टूल का एक अच्छा नतीजा:

  • विजेट को दिखने के लिए ज़रूरी डेटा देता है.

  • ChatGPT को जवाब देने के लिए ज़रूरी फैक्ट्स एक तय फ़ॉर्मैट में देता है.

  • जहाँ फ़्लो में ज़रूरत हो, यह भी बताता है कि अगला स्टेप क्या होना चाहिए, ताकि मॉडल को खुद अंदाज़ा न लगाना पड़े.

विजेट के एक्शन को चैट में गोलमोल टेक्स्ट नहीं भेजने चाहिए. उसे साफ़ बताना चाहिए कि यूज़र ने क्या किया और अब क्या होना चाहिए.

हैंडऑफ़ साफ़ होने के बाद भरोसेमंद तरीके से काम होने लगा.

जब टूल का नतीजा और विजेट एक्शन में छोटी और साफ़ बातें लिखी गईं, तो मॉडल ने उन्हें बेहतर तरीके से फ़ॉलो किया.

नीचे Pydantic का एक छोटा स्ट्रक्चर है जिसे हमने इस्तेमाल किया. output फ़ील्ड में विजेट को दिखाने के लिए ज़रूरी स्ट्रक्चर्ड डेटा और उस सेशन में ChatGPT को इस्तेमाल करने वाले फैक्ट्स होते हैं. agent_directions फ़ील्ड में एक छोटी लाइन होती है, जो बताती है कि असिस्टेंट को अगला काम क्या करना चाहिए. reason फ़ील्ड ज़रूरी नहीं है.

Python

from typing import Generic, TypeVar
from pydantic import BaseModel
T = TypeVar("T")
class AgentDirections(BaseModel): assistant_instruction: str reason: str | None = None
class ToolResults(BaseModel, Generic[T]): agent_directions: AgentDirections output: T

विजेट छोटे रखें

जो विजेट अच्छे रहे, वे एक फ़ैसला करवाते थे और फिर कंट्रोल वापस दे देते थे. छोटी लिस्ट, कन्फ़र्मेशन या छोटा रिव्यू स्क्रीन, विजेट को एक छोटे ऐप में बदलने से बेहतर रहे. विजेट में थोड़ा लॉजिक, जैसे आसान वैलिडेशन या तय अगला स्टेप, तब भी मददगार रहा जब हम फ़्लो को ज़्यादा तय तरीके से चलाना चाहते थे.

विजेट के मैसेज में थर्ड पर्सन का इस्तेमाल करें

हमने विजेट के अगले मैसेज को यूज़र की तरफ़ से लिखना बंद कर दिया (जैसे "मैंने चुना..." या "मैंने कन्फर्म किया..."). इसके बजाय हमने उन्हें यूज़र के किए काम की छोटी रिपोर्ट की तरह लिखा (जैसे "यूज़र ने चुना..." या "यूज़र ने कन्फर्म किया..."). हमने यह तरीका इसलिए अपनाया क्योंकि ChatGPT विजेट के मैसेजे को यूज़र मैसेजे के बजाय टूल मैसेजे की तरह जोड़ रहा था.

जब अगला स्टेप साफ़ हो, तो सीधे एक्शन लें

अगर कोई बटन अगले टूल कॉल को साफ़ तौर पर बताता है, तो विजेट से सीधे वह टूल कॉल करवाना बेहतर रहा, बजाय इसके कि एक और चैट टर्न करवाया जाए. यह तभी किया जा सकता है जब अगले टूल कॉल के लिए ChatGPT से किसी इनपुट की ज़रूरत न हो.

इससे तय फ़्लो को लागू करना आसान हुआ और एक और चैट टर्न की ज़रूरत न होने से लेटेंसी भी कम हुई.

एरर हैंडलिंग

जब कोई टूल कॉल फ़ेल हुआ, तो हमने सही MCP एरर कोड और टूल से छोटे, आसान मैसेज भेजे. इससे फ़ेल हुए कॉल पर ChatGPT के पास पढ़ने के लिए सही जानकारी रही. वह यूज़र को समस्या समझा सका और/या अगला सही स्टेप चुन सका.

टूल कॉन्टेक्स्ट मैनेजमेंट

हमने सेशन स्टेट अपने सर्वर पर रखा. ChatGPT टूल कॉल के साथ उस सेशन से जुड़ा कॉन्टेक्स्ट भेजता है. FastMCP में हमने हर टूल को एक 'कॉन्टेक्स्ट' पैरामीटर दिया, ताकि वह इस स्टेट को पढ़ और अपडेट कर सके.

  • स्टेबल ID और पहले मिले नतीजे सेशन में ही रखे गए, ताकि हर टूल कॉल में ChatGPT को उन्हें फिर से टूल आर्ग्युमेंट्स के तौर पर भेजने की ज़रूरत न पड़े.

  • जब टूल कॉल बार-बार होने लगे, तो हम एक ही कॉल को दोबारा होने से पहचान सकते थे और टूल के नतीजे के ज़रिए साफ़ एरर भेज सकते थे.

  • डिबगिंग और सपोर्ट के लिए सेशन लॉग्स हमारे पास ही रहे.

क्या काम नहीं आया

यह मान लेना कि मॉडल अगला स्टेप खुद समझ लेगा

शुरुआत में हम एक विजेट दिखाते थे, यह मान लेते थे कि मॉडल "समझ गया है", और सही अगले टूल कॉल का इंतज़ार करते थे. कुछ मौकों पर ऐसा हुआ, लेकिन अक्सर नहीं हुआ.

अगर हैंडऑफ़ साफ़ न हो, तो ChatGPT उस काम का की समरी बता सकता है, जबकि हमें एक्शन चाहिए हो, यूज़र से वही चुनाव दोबारा करने को कह सकता है, या तब भी प्लान बनाता रह सकता है जब उसे रुक जाना चाहिए.

इसका हल यह था कि स्ट्रक्चर्ड आउटपुट और विजेट पेलोड में अगला स्टेप साफ़ लिखें, न कि मॉडल के खुद समझ लेने की उम्मीद करें.

अलग-अलग लेयर्स में जानकारी बाँटना

हमने Apps SDK के डॉक्यूमेंटेशन के हिसाब से टूल आउटपुट, छिपा हुआ मेटाडेटा और चैट टेक्स्ट के बीच जानकारी बाँटकर इसे बेहतर बनाने की कोशिश की. लेकिन हम विजेट में छिपा हुआ मेटाडेटा पढ़ नहीं सके. इसलिए हम यह तरीका इस्तेमाल नहीं कर पाए.

मॉडल से टूल्स छिपाना

Apps SDK के डॉक्यूमेंटेशन में बताया गया है कि कुछ टूल्स को एजेंट की टूल लिस्ट से हटाया जा सकता है, ताकि एजेंट उन्हें खुद न चुने, लेकिन विजेट से उन्हें फिर भी कॉल हो सके. जब हमने विज़िबिलिटी को 'सिर्फ़ ऐप के लिए' किया, तो वे टूल्स विजेट से भी हट गए. हमें ऐसा सेटअप नहीं मिला जिसमें एजेंट को टूल दिखाई न दे, लेकिन विजेट उसे इस्तेमाल कर सके.

कमज़ोर एरर्स

जब कुछ काम का नहीं हुआ, तब कुछ न बताना या सिर्फ़ "सक्सेस" कहना, सीधे एरर बताने से भी खराब था. इसलिए हमने टूल और विजेट की गड़बड़ियों को साफ़ आउटपुट की तरह लिया: अगर कोई स्टेप आगे नहीं बढ़ सकता, तो हमने आसान भाषा में यह बताया और साफ़ एरर भेजा. यूज़र को ऐसे विजेट पर छोड़ने के बजाय जो दिख तो रहा था, लेकिन आगे नहीं बढ़ रहा था. इससे इस्तेमाल करना आसान हुआ और मॉडल का व्यवहार भी ज़्यादा भरोसेमंद रहा.

आखिरी बातें

अगर आप पूरा प्लेटफ़ॉर्म खुद बनाए बिना ChatGPT में कोई वर्कफ़्लो लाना चाहते हैं, तो Apps SDK एक अच्छा तरीका है. इसके बदले आपको कुछ कंट्रोल छोड़ना पड़ता है, लेकिन आप जल्दी काम शुरू कर सकते हैं और यूज़र्स तक वहाँ पहुँच सकते हैं जहाँ वे पहले से काम करते हैं.

अगर आपको फ़्लो की हर ब्रांच, UI और हर स्टेप का फैसला कौन करेगा, इन सब पर पूरा कंट्रोल चाहिए, तो शुरुआत से ही अपना एजेंट स्टैक बनाने की तैयारी करें. बाद में आपको ChatGPT के बाहर भी अपना एजेंट स्टैक बनाना पड़ सकता है.

आप ChatGPT के अंदर अपना MCP सर्वर चलाने के लिए भी Apps SDK इस्तेमाल कर सकते हैं. इससे पहले Chat, ऑथ और एजेंट से जुड़ा पूरा सेटअप खुद बनाने की ज़रूरत नहीं पड़ेगी. बाद में जब प्रोडक्ट की ज़रूरत बढ़े, तो आप अपने स्टैक पर जा सकते हैं.

इसी तरह की ज़रूरत वाली टीमों के लिए अगला कदम: ऐसा एक वर्कफ़्लो चुनें जिसका नतीजा साफ़ हो. चैट, टूल्स और विजेट्स के बीच हर हैंडऑफ़ को लिखकर साफ़ करें. इसके बाद रिट्राई और एरर्स को अच्छी तरह टेस्ट करें, इससे पहले कि आप प्रॉम्प्ट को बेहतर बनाने में ज़्यादा समय लगाएँ.

लेखक

Malan Evans