ChatGPT Apps SDK দিয়ে শিপ করে আমরা যা শিখেছি

• শিগগিরই ChatGPT-তে কোনো ওয়ার্কফ্লো দরকার হলে, অথবা কাস্টম এজেন্ট স্ট্যাকে বিনিয়োগের আগে সেখানে আপনার টুলগুলো পরীক্ষা করতে চাইলে, Apps SDK একটি বাস্তবসম্মত বিকল্প. এজেন্ট কীভাবে আচরণ করবে তার প্রতিটি ধাপ নিজের নিয়ন্ত্রণে রাখতে চাইলে, সাধারণত এটি উপযুক্ত নয়.

• ChatGPT-ই প্রধান ব্যবহারস্থল হওয়া উচিত এবং পূর্ণাঙ্গ চ্যাট পণ্য না বানিয়ে টুলের সঙ্গে অল্প কিছু UI দরকার হলে Apps SDK বেছে নিন. ফ্লো, মেমোরি, প্রম্পট এবং রাইটের ওপর কড়া নিয়ন্ত্রণ দরকার হলে নিজের এজেন্ট স্ট্যাক বেছে নিন.

• চ্যাটের সঙ্গে কয়েকটি ছোট UI ধাপ মেশানো পণ্যের জন্য Apps SDK মানানসই. আপনি দ্রুত শিপ করেন; বিনিময়ে কিছু নিয়ন্ত্রণ ছাড়েন.

• আমাদের ক্ষেত্রে কাজ দিয়েছিল স্পষ্ট টুল, স্পষ্ট উইজেট আচরণ এবং স্পষ্ট পরবর্তী ধাপ. ফ্লো নির্ধারণে আমরা এগুলোর ওপর ভরসা করেছি, LLM-এর ওপর নয়. সিস্টেম আগে থেকেই যে ফল বেছে নিয়েছিল, মডেল তা ব্যাখ্যা করার সময় সবচেয়ে বেশি কাজে এসেছে.

• নিচে: কীভাবে বেছে নেবেন, তারপর কী কাজ করেছে আর কী করেনি.

বেশিরভাগ দল এখনও AI পাইলট চালায় বা কম ঝুঁকি-কম লাভের পার্শ্বিক ব্যবহারে AI মোতায়েন করে. খুব কম দলই এমন ব্যবসা-গুরুত্বপূর্ণ পণ্য শিপ করে যা ব্যবহারকারীরা প্রতি সপ্তাহে ব্যবহার করেন. লক্ষ্য যদি পুরো অ্যাসিস্ট্যান্ট নিজে বানানোর বদলে ChatGPT-এর ভেতরে পৌঁছানো হয়, সেই ফাঁক কমানোর একটি উপায় হলো ChatGPT Apps SDK.

আমাদের শেখাগুলো এসেছে এমন এক ক্লায়েন্ট কাজ থেকে, যেখানে প্রয়োজনীয়তা ChatGPT-কে প্রাথমিক ব্যবহারস্থল হিসেবে নির্দেশ করেছিল এবং এমন দ্রুত পথ চেয়েছিল যাতে পূর্ণাঙ্গ কাস্টম চ্যাট পণ্য বানাতে অর্থায়ন করতে না হয়.

সেই ব্রিফের বিপরীতে Apps SDK মানানসই ছিল, কারণ ক্লায়েন্টের দরকার ছিল:

• বানিয়ে হোস্ট করার মতো আলাদা চ্যাট পণ্য নয়—তারা ChatGPT-এর ভেতরে পৌঁছাতে চেয়েছিল, আরেকটি স্বতন্ত্র অ্যাসিস্ট্যান্ট শেল নয়.

• চ্যাটের সঙ্গে ছোট, কাজনির্দিষ্ট UI—কয়েকটি কেন্দ্রীভূত উইজেট ধাপ, ওয়ার্কফ্লোর ভেতরে দ্বিতীয় পূর্ণাঙ্গ পণ্য নয়.

• MCP টুলের মাধ্যমে উন্মুক্ত ব্যাকএন্ড আচরণ—স্ট্যান্ডার্ড টুল কলিং, শুরু থেকে শেষ পর্যন্ত নিজস্ব কাস্টম এজেন্ট রানটাইম নয়.

• ChatGPT-এর ভেতরে আবিষ্কারযোগ্যতা—ব্যবহারকারীরা যেখানে আগে থেকেই কাজ করেন, সেখানেই যেন ওয়ার্কফ্লোটির দেখা পান.

বানানোর সময়ই আমরা ক্লায়েন্টের সঙ্গে এই পছন্দগুলো যাচাই করেছি. সমঝোতাটি তবু থাকে: ChatGPT সেশন হোস্ট করলে বাইরের রানটাইম আপনার নিয়ন্ত্রণে থাকে না. আপনি দিকনির্দেশ দেন; পুরোপুরি নিয়ন্ত্রণ করেন না.

একটি Apps SDK অ্যাপ তিনটি জিনিসকে একসঙ্গে যুক্ত করে:

1. ChatGPT-এর এজেন্ট রানটাইম

2. আপনার MCP টুল

3. আপনার উইজেট UI

বাস্তবে ফ্লো:

1. ব্যবহারকারী ChatGPT-কে কিছু করতে বলেন.

2. ChatGPT আপনার MCP টুলগুলোর একটি কল করতে পারে.

3. আপনার সার্ভার একটি স্ট্রাকচার্ড টুল ফলাফল ফেরত দেয়.

4. ChatGPT সেই ফলাফল পড়ে পরবর্তী ধাপ ঠিক করে: আরও টুল কল, ব্যবহারকারীকে উত্তর, অথবা দুটোই. সে টুলে উইজেট যুক্ত থাকলে, এই টার্নেই সেটি দেখা যেতে পারে.

5. ব্যবহারকারী চ্যাটে বা উইজেটে এগিয়ে যান (ফলো-আপ টেক্সট, কোনো পছন্দ, বা উইজেট-ট্রিগার করা টুল কল). এতে থ্রেড আপডেট হয়; ChatGPT আরেকটি টার্ন চালায় এবং কাজ শেষ না হওয়া পর্যন্ত ধাপ দুই–চার পুনরাবৃত্তি হয়.

চ্যাট, ব্যাকএন্ড অ্যাকশন এবং ছোট UI ধাপের এই মিশ্রণটাই মূল বিষয়. এর মানে হলো ভঙ্গুর অংশগুলো থাকে চ্যাট, টুল এবং UI-এর মধ্যকার হ্যান্ডঅফে.

চ্যাট UI, টুল ওয়্যারিং, অথ প্যাটার্ন বা উইজেট শেল আপনাকে একেবারে শুরু থেকে বানাতে হয় না. অনেক পণ্যের ক্ষেত্রে এতে নির্মাণের সময় অনেক কমে, ফলে আপনি ডোমেইন লজিক ও গার্ডরেইলে মন দিতে পারেন.

ChatGPT-এর ভেতরে বানানো আর নিজের এজেন্ট চালানো এক বিষয় নয়. প্রকল্পের কঠিন অংশ প্রম্পটের কৌশল ছিল না. কঠিন ছিল টুল, উইজেট এবং পরবর্তী ধাপকে এত স্পষ্ট করা, যাতে মডেল ও UI একসঙ্গে তাল মিলিয়ে চলে.

Apps SDK আপনার সাধারণ ফ্রন্টএন্ডের তুলনায় ভিন্ন ধরনের পণ্য আকৃতি দেয়, তবে কোন পরিস্থিতিতে এটি আদর্শ তা জানা গুরুত্বপূর্ণ.

Apps SDK ব্যবহার করুন যখন আপনি চান

• দ্রুত একটি ChatGPT ওয়ার্কফ্লো শিপ করতে.

• কথোপকথনটি ChatGPT-কে হোস্ট করতে দিতে.

• স্বাভাবিক ভাষার সঙ্গে কয়েকটি কেন্দ্রীভূত UI ধাপ মিলিয়ে দিতে.

• নিজস্ব চ্যাট ইন্টারফেস, এজেন্ট কনটেইনার এবং আবিষ্কারযোগ্যতা বানানো এড়াতে.

আপনার ব্যবহারকারীরা যদি আগে থেকেই ChatGPT-তে থাকেন, শেষ পয়েন্টটি গুরুত্বপূর্ণ.

নিজের এজেন্ট বানান যখন আপনার দরকার

• কোডে বলবৎ করা যায় এমন নির্দিষ্ট ধাপে ধাপে ফ্লো.

• শুরু থেকে শেষ পর্যন্ত আপনার নিয়ন্ত্রণে থাকা কাস্টম UI এবং কনফার্মেশন পথ.

• নিজস্ব মেমোরি ও স্টেট মডেল.

• প্রতিবার চালানোর সময় পূর্বানুমেয় আচরণ.

• এজেন্টের জন্য ট্রেস, লগ এবং মেট্রিকস.

প্ল্যানার, সিস্টেম প্রম্পট এবং পুরো ওয়ার্কফ্লোই যদি আপনার পণ্য হয়, সাধারণত কাস্টম স্ট্যাকই বেশি মানানসই.

আমাদের কাজে বারবার যে শব্দটি ফিরে এসেছে তা হলো নিয়ন্ত্রণ: একদিকে গতি ও পরিচিত হোস্ট; অন্যদিকে রানটাইমের আংশিক মালিকানা. পুরো স্ট্যাকের মালিকানার চেয়ে ChatGPT-তে ব্যবহারকারীদের কাছে পৌঁছানোকে অগ্রাধিকার দিয়ে ক্লায়েন্ট এই সমঝোতাই মেনে নিয়েছিল.

সোজা পথটি সহজ শোনায়: ব্যবহারকারী জিজ্ঞেস করেন, টুল চলে, ডেটা ফিরে আসে, কোনো পছন্দ গুরুত্বপূর্ণ হলে উইজেট দেখা যায়.

বাস্তবে কষ্টের জায়গা ছিল হ্যান্ডঅফ. উইজেট কোনো সাজসজ্জা নয়. স্ক্রিনে আসার পর এটি মডেল কী দেখে এবং এরপর কী করে তা বদলে দেয়. উইজেট অ্যাকশনকে ঢিলেঢালা চ্যাট নয়, নাম দেওয়া ইভেন্ট হিসেবে ধরুন.

কাজটির স্ট্যাক ছিল সরল: FastMCP, Pydantic, React, TypeScript. এগুলো ইন্টিগ্রেট করা ঠিকই ছিল. আসল কাজ ছিল মডেল, টুল এবং UI-কে পরের ধাপে কী হবে সে বিষয়ে একমত করানো.

প্রতিটি হ্যান্ডঅফ স্পষ্ট করুন

আমরা টুল ফলাফলকে আর কাঁচা ব্যাকএন্ড পে-লোড হিসেবে দেখা বন্ধ করি. প্রতিটি রিটার্ন একটি হ্যান্ডঅফে পরিণত হয়.

একটি শক্তিশালী টুল ফলাফল:

• উইজেট রেন্ডার করতে যা দরকার তা দেয়.

• উত্তর তৈরির ভিত্তি হিসেবে ChatGPT-কে স্ট্রাকচার্ড তথ্য দেয়.

• ফ্লোতে দরকার হলে, পরের ধাপে কী হওয়া উচিত তা বলে দেয়, যাতে মডেলকে অনুমান করতে না হয়.

উইজেট অ্যাকশনের মাধ্যমে থ্রেডে অস্পষ্ট গদ্য পাঠানো উচিত নয়. ব্যবহারকারী কী করেছেন এবং এরপর কী হওয়া উচিত, সেটাই বলা উচিত.

হ্যান্ডঅফ স্পষ্ট হওয়ার পর নির্ভরযোগ্যতা বেড়েছে.

টুল আউটপুট ও উইজেট অ্যাকশনে থাকলে মডেল সংক্ষিপ্ত, স্পষ্ট নির্দেশনা অনুসরণ করে.

নিচে আমরা ব্যবহার করা একটি ছোট Pydantic শেপ আছে. output ফিল্ডে থাকে উইজেট দেখালে তার প্রয়োজনীয় স্ট্রাকচার্ড ডেটা, এবং সেশনে ChatGPT যে তথ্য ব্যবহার করবে তা. agent_directions ফিল্ডে থাকে একটি ছোট লাইন, যা বলে অ্যাসিস্ট্যান্টের পরের কাজ কী হওয়া উচিত. Reason ঐচ্ছিক.

1from typing import Generic, TypeVar2
3from pydantic import BaseModel4
5T = TypeVar("T")6
7class AgentDirections(BaseModel):8 assistant_instruction: str9 reason: str | None = None10
11class ToolResults(BaseModel, Generic[T]):12 agent_directions: AgentDirections13 output: T

উইজেট ছোট রাখুন

যে উইজেটগুলো কাজ করেছে, সেগুলো একটি সিদ্ধান্ত নিত এবং তারপর নিয়ন্ত্রণ ফিরিয়ে দিত. উইজেটকে মিনি অ্যাপে পরিণত করার চেয়ে ছোট তালিকা, কনফার্মেশন বা সংক্ষিপ্ত রিভিউ স্ক্রিন ভালো কাজ করেছে. ফ্লোকে আরও নির্ধারিত করতে চাইলে উইজেটের সামান্য লজিক, যেমন সহজ ভ্যালিডেশন বা নির্দিষ্ট পরবর্তী ধাপ, তবু সহায়ক ছিল.

উইজেট বার্তায় তৃতীয় পুরুষ

আমরা ব্যবহারকারীর চ্যাটের মতো উইজেট ফলো-আপ লেখা বন্ধ করেছি (“আমি নির্বাচন করেছি...,” “আমি নিশ্চিত করেছি...”). বরং ব্যবহারকারী কী করেছেন তার ছোট রিপোর্ট হিসেবে লিখেছি (“ব্যবহারকারী নির্বাচন করেছেন...,” “ব্যবহারকারী নিশ্চিত করেছেন...”). আমরা এই পদ্ধতি চেষ্টা করেছি, কারণ ChatGPT উইজেট বার্তাগুলোকে ব্যবহারকারী বার্তার বদলে টুল বার্তা হিসেবে যোগ করছিল.

পরবর্তী ধাপ স্পষ্ট হলে সরাসরি অ্যাকশন

কোনো বোতাম যদি পরবর্তী টুল কল স্পষ্টভাবে বোঝায়, উইজেটকে সরাসরি সেটি ট্রিগার করতে দেওয়া আরেকটি চ্যাট টার্ন বাধ্য করার চেয়ে ভালো কাজ করেছে. এটি শুধু তখনই, যখন পরবর্তী টুল কলে ChatGPT থেকে ইনপুট লাগে না.

এটি নির্ধারিত ফ্লো বলবৎ করতে সাহায্য করেছে এবং আরেকটি চ্যাট টার্ন এড়িয়ে লেটেন্সিও কমিয়েছে.

ত্রুটি সামলানো

টুল কল ব্যর্থ হলে আমরা টুল থেকে সঠিক MCP ত্রুটি কোড এবং সংক্ষিপ্ত, সরল বার্তা ফেরত দিয়েছি. তখন ব্যর্থ কলের ক্ষেত্রে ChatGPT-এর পড়ার মতো বাস্তব কিছু ছিল, যাতে এটি ব্যবহারকারীকে সমস্যা ব্যাখ্যা করতে এবং/অথবা যুক্তিসঙ্গত পরবর্তী ধাপ বেছে নিতে পারে.

টুল কনটেক্সট ব্যবস্থাপনা

আমরা সেশন স্টেট আমাদের সার্ভারে রেখেছি. ChatGPT টুল কলের সঙ্গে সেশন-স্কোপড কনটেক্সট পাঠায়; FastMCP-তে আমরা প্রতিটি টুলকে একটি Context প্যারামিটার দিয়েছি, যাতে হ্যান্ডলার সেই স্টেট পড়তে ও আপডেট করতে পারে.

• প্রতিটি কলে টুল আর্গুমেন্ট হিসেবে আবার পাস করতে ChatGPT-কে বলার বদলে স্থিতিশীল ID এবং আগের ফলাফল সেশনে রাখা হয়েছে.

• টুল-কল লুপ দেখা দিলে আমরা ডুপ্লিকেট কল ধরতে পারতাম এবং টুল ফলাফলের মাধ্যমে স্পষ্ট ত্রুটি ফেরত দিতে পারতাম.

• ডিবাগিং ও সাপোর্টের জন্য সেশন লগ আমাদের দিকেই থাকত.

শুরুর দিকে আমরা একটি উইজেট দেখিয়েছিলাম, ধরে নিয়েছিলাম মডেল “বুঝেছে,” এবং সঠিক ফলো-আপ টুল কলের অপেক্ষায় ছিলাম. কখনও তা ঘটেছে. প্রায়ই ঘটেনি.

স্পষ্ট হ্যান্ডঅফ না থাকলে, আমরা অ্যাকশন চাইলে ChatGPT সারাংশ দিতে পারে, ব্যবহারকারীকে পছন্দটি আবার বলতে বলতে পারে, অথবা থামা উচিত হলেও পরিকল্পনা চালিয়ে যেতে পারে.

সমাধান ছিল স্ট্রাকচার্ড আউটপুটস এবং উইজেট পে-লোডে পরের ধাপ স্পষ্ট করে বলা, মডেল নিজে বুঝে নেবে এই আশায় থাকা নয়.

Apps SDK ডকুমেন্টেশন অনুযায়ী টুল আউটপুট, লুকানো মেটাডেটা এবং চ্যাট টেক্সটজুড়ে রেসপন্স ভাগ করে আমরা যখন বেশি কৌশলী হতে চেয়েছিলাম. কিন্তু উইজেটে আমরা লুকানো মেটাডেটা পড়তে পারিনি. তাই আমরা এটি ব্যবহার করতে পারিনি.

Apps SDK ডকসে এমন টুলের কথা বলা আছে যা এজেন্টের টুল তালিকার বাইরে রাখা যায়, যাতে সেটি সেগুলো না বেছে নেয়, তবু উইজেট থেকে সেগুলো কল করা যায়. আমরা visibility app-only করলে, সেসব টুল শুধু এজেন্ট থেকে নয়, উইজেট থেকেও অপ্রাপ্য হয়ে যায়. এমন সেটআপ আমরা কখনও পাইনি যেখানে এজেন্ট কোনো টুল দেখতে পারে না, কিন্তু উইজেট তবু পারে.

কাজের কিছু না ঘটলেও নীরবতা বা সাধারণ “সফল” বার্তা সরাসরি ত্রুটির চেয়ে খারাপ ছিল, তাই আমরা টুল ও উইজেট ব্যর্থতাকে প্রথম-শ্রেণির আউটপুট হিসেবে ধরেছি: কোনো ধাপ এগোতে না পারলে আমরা সরল ভাষায় তা বলেছি এবং স্পষ্ট ত্রুটি ফেরত দিয়েছি, ব্যবহারকারীদের এমন উইজেটের দিকে তাকিয়ে থাকতে দিইনি যা রেন্ডার হয়েছে কিন্তু তাদের এগিয়ে নিচ্ছে না. এতে ব্যবহারযোগ্যতা উন্নত হয়েছে এবং মডেলের আচরণ আরও নির্ভরযোগ্য হয়েছে.

কম কাস্টম প্ল্যাটফর্ম কাজ নিয়ে ChatGPT-তে একটি ওয়ার্কফ্লো বানানো যদি আপনার লক্ষ্য হয়, Apps SDK সেখানে পৌঁছানোর বাস্তবসম্মত উপায়. গতি এবং ব্যবহারকারীরা যেখানে আগে থেকেই কাজ করেন সেখানে পৌঁছানোর বিনিময়ে আপনি কিছু নিয়ন্ত্রণ ছাড়েন.

ফ্লোর প্রতিটি শাখা, UI এবং প্রতিটি ধাপে সিদ্ধান্ত কে নেবে—এসব নিজের নিয়ন্ত্রণে রাখতে হলে শুরু থেকেই নিজের এজেন্ট স্ট্যাকের পরিকল্পনা করুন. শুধু ChatGPT-এর ভেতরে বানানোর সীমা আপনি সম্ভবত ছাড়িয়ে যাবেন.

চ্যাট, অথ এবং এজেন্ট প্লাম্বিং নিজে বানানোর আগে ChatGPT-এর ভেতরে আপনার MCP সার্ভার চালাতেও Apps SDK ব্যবহার করতে পারেন; পরে পণ্যের প্রয়োজনে নিজের স্ট্যাকে যেতে পারেন.

একই অবস্থায় থাকা দলগুলোর জন্য পরবর্তী ধাপ: স্পষ্ট ফলাফলসহ একটি ওয়ার্কফ্লো বেছে নিন, চ্যাট, টুল ও উইজেটের মধ্যকার হ্যান্ডঅফ লিখে ফেলুন, তারপর প্রম্পট টিউনিংয়ে বেশি সময় দেওয়ার আগে রিট্রাই ও ত্রুটির স্ট্রেস-টেস্ট করুন.