Codex দিয়ে স্ব-উন্নয়নশীল ট্যাক্স এজেন্ট তৈরি

প্র্যাকটিশনারের দক্ষতাকে Codex-চালিত লুপের সঙ্গে একীভূত করে কীভাবে Thrive Holdings এবং OpenAI, Crete হিসাবরক্ষকদের জন্য Tax AI যৌথভাবে তৈরি করেছে

বাস্তব জগতের সিস্টেমগুলো ল্যাবের তুলনায় প্রোডাকশনে ভিন্নভাবে আচরণ করে, এবং ডিপ্লয়মেন্টের আগে অনুমান করা কঠিন এমন উপায়ে ভেঙে পড়ে. দলগুলো প্রায়ই লঞ্চের পর এসব ব্যর্থতা আবিষ্কার করে, তারপর edge case পরীক্ষা, প্রম্পট সমন্বয়, এবং প্রোডাকশন প্রতিক্রিয়াকে টেকসই পণ্য উন্নতিতে রূপান্তর করতে সপ্তাহ ব্যয় করে. প্রতিক্রিয়া লুপটি ম্যানুয়াল ও ধীর, এবং কেবল তখনই উন্নত হয় যখন কোনো ইঞ্জিনিয়ার এটিকে এগিয়ে নেন. কিন্তু আজ, সুচিন্তিতভাবে নকশা করা eval অবকাঠামো, প্র্যাকটিশনার ও বাস্তব পরিবেশে সরাসরি প্রবেশাধিকার, এবং Codex-এর অগ্রবর্তী এজেন্টিক সক্ষমতা দিয়ে আপনি এমন এজেন্ট তৈরি করতে পারেন যা নিজে নিজে উন্নত হয়.

এই পোস্টে, আমরা ব্যাখ্যা করব কীভাবে আমরা Codex ব্যবহার করে এই ধরনের এজেন্ট তৈরি করেছি. গত ছয় মাসে, OpenAI-এর forward deployed engineers ও researchers, এবং Thrive Holdings-এর engineers একসঙ্গে কাজ করে Crete⁠(একটি নতুন উইন্ডোতে খোলে)-এর 30+ হিসাবরক্ষণ প্রতিষ্ঠানের নেটওয়ার্কের পাশে ও তাদের জন্য Tax AI তৈরি করেছেন, যাতে ক্রমশ জটিল ট্যাক্স রিটার্ন প্রস্তুত করতে সহায়তা করা যায়. প্রতিটি ব্যর্থতা খুঁজে বের করে ঠিক করার জন্য ইঞ্জিনিয়ারদের ওপর নির্ভর না করে, Tax AI প্রোডাকশন ব্যবহাকে structured signal-এ পরিণত করতে Codex ব্যবহার করে, যা স্বয়ংক্রিয় উন্নতিকে জ্বালানি দেয়.

Crete-এর প্র্যাকটিশনাররা প্রতি মৌসুমে কয়েক হাজার ট্যাক্স রিটার্ন প্রস্তুত করেন, যার জন্য লক্ষ লক্ষ অন্তর্নিহিত নথি নিয়ে কাজ করতে হয়. মাঝারি থেকে বড় জটিলতার ফাইলিংয়ের ক্ষেত্রে, শুধু data entry-তেই প্রতি রিটার্নে আট ঘণ্টা লাগতে পারে, যেখানে অগোছালো ডেটা সোর্স, আগের বছরের নথি, এবং ম্যানুয়াল extraction ও calculation জড়িত থাকে. তারা আমাদের দেখিয়েছেন যে ট্যাক্স মৌসুমের সবচেয়ে ব্যস্ত সময়ে ট্যাক্স প্রস্তুতি একটি বড় bottleneck.

এই সমস্যা সমাধানে, Tax AI এই ট্যাক্স মৌসুমে পাইলটে অংশ নেওয়া Crete প্রতিষ্ঠানের 7,000টি ট্যাক্স রিটার্ন প্রক্রিয়া করেছে. সিস্টেমটি 1040 ও 1041 ট্যাক্স রিটার্ন প্রস্তুতির সময়সাপেক্ষ প্রক্রিয়ার বড় অংশ স্বয়ংক্রিয় করে, তবে দক্ষতা বৃদ্ধির চেয়েও বেশি আকর্ষণীয় হলো, সিস্টেমটি নিজেই তিন মাস আগে প্রথম ডিপ্লয় করা সংস্করণের তুলনায় পরিমাপযোগ্যভাবে ভালো.

Tax AI-এ, প্র্যাকটিশনাররা যেকোনো client-specific note-সহ সোর্স ফাইল আপলোড করেন. এরপর Tax AI একটি tax engine submission তৈরি করে, যা পর্যালোচনার জন্য প্রস্তুত. এটি প্র্যাকটিশনারদের ট্যাক্স প্রস্তুতির সময়ের প্রায় এক-তৃতীয়াংশ বাঁচায়, 97% পর্যন্ত নির্ভুলতায় রিটার্নের খসড়া তৈরি করে, এবং থ্রুপুট প্রায় 50% বাড়ায়, ফলে তারা ক্লায়েন্টদের সঙ্গে সময় কাটানোর আরও সুযোগ পান. 

পরে সংশোধনের প্রয়োজন ছাড়াই Tax AI কতটা নির্ভুলভাবে একটি রিটার্ন সম্পূর্ণ করতে পারে তা বুঝে আমরা এই উন্নতি পরিমাপ করতে পারি. আমরা নির্ভুলতা মাপি এই দেখে যে কত অংশ রিটার্ন 75%, 90%, বা 100% সঠিক ফিল্ড সম্পূর্ণতায় পৌঁছায়. লঞ্চের সময়, মাত্র এক-চতুর্থাংশ রিটার্ন 75% সঠিক ফিল্ড সম্পূর্ণতায় ছিল, কিন্তু ছয় সপ্তাহের মধ্যে 86% সেই মানে পৌঁছে যায়. 90% এবং 100% সঠিক ফিল্ড সম্পূর্ণতার স্তরেও সিস্টেমটি আরও দ্রুত বৃদ্ধি দেখিয়েছে. এই সীমাগুলো আমাদের ব্যবহারিকভাবে বুঝতে সাহায্য করে যে ভিন্ন ভিন্ন রিটার্নে এখনও কতটা প্র্যাকটিশনার follow-up দরকার. 

শুরুর দিকে, Tax AI W-2s এবং 1099s-এর মতো সহজ কাজ সামলাত. মৌসুম এগোতে থাকলে, এটি K-1s, schedules, এবং আরও কঠিন edge case-সহ বেশি জটিল রিটার্নে যায়. প্রতিটি নতুন সক্ষমতা আগেরটির চেয়ে প্রতি রিটার্নে বেশি সময় বাঁচিয়েছে, কারণ এটি যে কাজগুলো নিয়েছে সেগুলো ম্যানুয়ালি করা আরও কঠিন ও সময়সাপেক্ষ ছিল. আমরা আজও ধারাবাহিক অগ্রগতি দেখতে পাচ্ছি.

এরপর, আমরা দেখাব কীভাবে আমাদের দলগুলো তিনটি গুরুত্বপূর্ণ স্তম্ভের ওপর ভর করে Tax AI-কে স্ব-উন্নয়নশীল হিসেবে যৌথভাবে ইঞ্জিনিয়ার করেছে: 1) বিশেষজ্ঞ প্র্যাকটিশনার প্রতিক্রিয়া, 2) প্রোডাকশন ট্রেস (ইনপুট থেকে চূড়ান্ত আউটপুট পর্যন্ত একটি structured history), এবং 3) ধারাবাহিক ও দ্রুততর পণ্য উন্নয়ন সক্ষম করতে tailored evals-ভিত্তিক Codex-চালিত iteration loop. আমরা আশা করি, যেসব ডোমেইনে প্র্যাকটিশনারের দক্ষতা সামগ্রিক সিস্টেমের গুণমান ও এর মধ্য দিয়ে চলা ডেটাকে গড়ে তুলতে গুরুত্বপূর্ণ, সেখানে অন্য নির্মাতাদের জন্য আমাদের অভিজ্ঞতা উপকারী হবে.

আমরা যখন ট্যাক্স প্রস্তুতির আরও কঠিন অংশে এগোতে থাকলাম (K-1s, ভাড়ার রিয়েল এস্টেট schedule, এবং এমন tax form যেখানে একাধিক সোর্স ফাইল জুড়ে মান মিলিয়ে নিতে হতো), তখন স্পষ্ট হয়ে গেল যে আসল চ্যালেঞ্জ ছিল পণ্যটি জটিল প্রোডাকশন ব্যর্থতাকে দৃশ্যমান, বোধগম্য এবং কার্যকর করতে পারে কি না.

পণ্যের শুরুর দিনে, বেশিরভাগ সংশোধনই ছিল ম্যানুয়াল. প্র্যাকটিশনাররা সিস্টেমের ভুল সংশোধন করতে পারতেন, কিন্তু পণ্যটি পূর্ণ প্রেক্ষাপট ধরত না: ফাইলিংয়ের আগে পরিবর্তিত একটি মান সত্যিকারের extraction miss, mapping problem, অনুপস্থিত product support, বা প্রত্যাশিত workflow noise প্রতিফলিত করতে পারে. এসব কেস আলাদা করতে এখনও ইঞ্জিনিয়ারিং দলের follow-up দরকার হতো. ইঞ্জিনিয়াররা coding agent ব্যবহার করতে পারতেন, কিন্তু সিস্টেমটি তখনও এমনভাবে নকশা করা ছিল না যাতে উন্নয়ন লুপের ভেতরে AI-কে অর্থবহভাবে ব্যবহার করা যায়. সঠিক আরোহনের লক্ষ্য শনাক্ত করার মতো সংকেত আমাদের ছিল না.

এতে আমরা সিস্টেমটিকে তিনটি স্তম্ভ ঘিরে নকশা করেছি:

1. প্র্যাকটিশনারদের কাছাকাছি থাকুন: যারা কাজটি করছেন, পণ্যটি কী শিখবে তা তাদেরই পরিচালনা করতে হবে. তাদের অন্তর্দৃষ্টি ও বোঝাপড়া কোন ভুলগুলো গুরুত্বপূর্ণ তা প্রকাশ করে এবং workflow-এর কোন অংশে পরেরবার মনোযোগ দেওয়া উচিত তা নির্ধারণে সাহায্য করে.
2. পণ্যটি এমনভাবে তৈরি করুন যাতে প্রোডাকশন প্রমাণ তৈরি করে: পণ্যটিকে শুধু ইনপুট ও আউটপুট নয়, বরং সোর্স উপাদান থেকে extraction করা ফিল্ড ও provenance, তারপর downstream submission ও বিশেষজ্ঞ সংশোধন পর্যন্ত পুরো পথটি ধরতে হবে.
3. Codex-চালিত উন্নয়ন লুপ তৈরি করুন: একবার প্রোডাকশন সমস্যা দৃশ্যমান ও structured হয়ে গেলে, সেগুলো finding, tailored evals, এবং scoped engineering task-এ পরিণত হতে পারে. এরপর Codex অনুসন্ধান, পরিবর্তনের প্রস্তাব, targeted ও regression evals-এর বিপরীতে সেগুলোর validation, এবং সম্পূর্ণ ম্যানুয়াল iteration cycle-এর তুলনায় দ্রুত পণ্যকে এগিয়ে নিতে সাহায্য করতে পারে. 

নিচের ভাড়ার সম্পত্তির উদাহরণটি দেখায় কীভাবে এই লুপ বাস্তবে কাজ করে, যেখানে একটি প্র্যাকটিশনার সংশোধন কীভাবে structured finding, তারপর eval target, এবং শেষ পর্যন্ত Codex-scoped engineering task-এ পরিণত হয় তা ধাপে ধাপে দেখানো হয়েছে.

ভাড়ার সম্পত্তির আয় ব্যক্তিগত ট্যাক্স রিটার্নের Schedule E-তে রিপোর্ট করা হয়. ইঞ্জিনিয়ারিং দৃষ্টিকোণ থেকে, এটি extraction করার কাজটি বর্ণনা করা সহজ, কিন্তু ভালোভাবে করা কঠিন. সিস্টেমটিকে অগোছালো সোর্স উপাদান (হাতে লেখা নোট, ইমেইল, স্প্রেডশিট এবং অন্যান্য ক্লায়েন্ট ফাইল) পড়তে হবে, সিস্টেম যে ভাড়ার-সম্পত্তি ফিল্ডগুলোকে আত্মবিশ্বাসের সঙ্গে tax engine-এ ম্যাপ করতে পারে সেগুলো extraction করতে হবে, এবং যথেষ্ট প্রমাণ সংরক্ষণ করতে হবে যাতে একজন প্র্যাকটিশনার ফলাফল অনুমোদন বা সংশোধন করতে পারেন. নিচের সরলীকৃত উদাহরণটি দেখায়, সেই সোর্স ফাইল ও extraction করা আউটপুটগুলো কেমন হতে পারে.

এজেন্ট-অনুমানকৃত মান এবং দাখিল করা ট্যাক্স রিটার্নের প্রকৃত মানের মধ্যে পার্থক্য সত্যিকারের extraction miss নির্দেশ করতে পারে, তবে এটি প্র্যাকটিশনারের পছন্দ, ট্যাক্স ইঞ্জিনে আগের বছরের রিটার্ন থেকে বহন করা মান, বা ফাইলিং workflow-এর অন্য কোথাও যোগ বা পরিবর্তিত হওয়া মানও হতে পারে. প্র্যাকটিশনাররা আমাদের এসব কেস আলাদা করে বুঝতে সাহায্য করেছেন, যাতে আমরা শনাক্ত করতে পারি কোন কাজগুলোতে প্র্যাকটিশনারের সংশোধন দরকার ছিল বা কোনগুলো জমা দেওয়া আটকে দিয়েছিল.

কারণ আমরা এসব সংশোধন বিস্তারিতভাবে দেখতে পেরেছি, আমরা পর্যালোচনা প্রক্রিয়াটিকে ব্যর্থতার পরের চূড়ান্ত ধাপ থেকে একটি ধারাবাহিক শেখার চক্রে রূপান্তর করেছি. আমরা workflow-টি এমনভাবে নকশা করেছি যাতে বিশেষজ্ঞদের কাজগুলো structured data হিসেবে ধরা যায়. এখন, প্রতিটি intervention পণ্যের উন্নয়ন লুপকে খাওয়ায়, কারণ এতে ঠিক কী Tax AI প্রস্তাব করেছিল, প্র্যাকটিশনার কী পরিবর্তন করেছিলেন, এবং শেষ পর্যন্ত দাখিল করা রিটার্নে কী গেছে তা নথিভুক্ত হয়.

ভাড়ার সম্পত্তির মতো জটিল workflow-এর ক্ষেত্রে, সোর্স ফাইল এবং দাখিল করা রিটার্নের মাঝখানে কী ঘটে তা সিস্টেমকে সংরক্ষণ করতে হয়. এই পথে নথিগুলো সংগঠিত, বিভক্ত এবং শ্রেণিবদ্ধ করা হয়; ভাড়ার-সম্পত্তি ফিল্ডগুলো সোর্স উপাদানে উদ্ধৃতিসহ extraction করা হয়; সেই মানগুলো ট্যাক্স ইঞ্জিনে ম্যাপ করা হয়; এবং ফাইলিংয়ের আগে প্র্যাকটিশনাররা সেগুলো এখনও সংশোধন করতে পারেন. এই পণ্য-স্তরের ট্রেসগুলো ব্যর্থতা কোথায় ঘটেছে তা অনুসন্ধান করা সম্ভব করে. প্র্যাকটিশনারের সংশোধনকে কার্যকর মূল্যায়ন লক্ষ্যে পরিণত করতে, সিস্টেম সেগুলোকে তিন ধাপে প্রক্রিয়া করে:

• পার্থক্য ধরুন: Tax AI-এর আউটপুট দাখিল করা রিটার্নের সঙ্গে তুলনা করা হয়, যাতে ফিল্ড-স্তরের review row তৈরি হয় যা প্রত্যাশিত মান, অনুমানকৃত মান, এবং পার্থক্যটি কার্যকর বলে মনে হয় কি না তা ধরে.
• সম্পর্কিত ব্যর্থতাগুলোকে গ্রুপ করুন: একই ধরনের review row-গুলোকে একত্র করা হয়, যাতে পুনরাবৃত্ত পণ্য ব্যর্থতাকে প্রত্যাশিত workflow noise থেকে আলাদা করা যায়. উদাহরণস্বরূপ, বারবার প্র্যাকটিশনার সংশোধন দেখাতে পারে যে Tax AI প্রায়ই “fair rental days” ফিল্ড মিস করে, “other expenses” ভুলভাবে সামলায়, বা একই সোর্স প্যাকেজে একাধিক ভাড়ার সম্পত্তি গুলিয়ে ফেলে.
• পুনরাবৃত্ত প্যাটার্নকে eval লক্ষ্যে পরিণত করুন: একবার পর্যালোচনা ও পরিমাপ করা হলে, পুনরাবৃত্ত ফলাফল Codex-এর উন্নতির জন্য স্পষ্ট eval লক্ষ্যে পরিণত হয়.

তৃতীয় স্তম্ভ হলো এমন একটি ইঞ্জিনিয়ারিং লুপ তৈরি করা, যা এই নতুন evals-এর ওপর কাজ করতে সক্ষম. এখানেই Codex কেন্দ্রীয় হয়ে ওঠে.

ধরা যাক, আমাদের eval pipeline চিহ্নিত করল যে Tax AI ধারাবাহিকভাবে "fair rental days" ফিল্ডটি মিস করছে, অথচ প্র্যাকটিশনাররা নির্ভরযোগ্যভাবে এটি পূরণ করছেন. কারণ এই ফলাফল ইতিমধ্যেই প্রতিনিধিত্বমূলক সোর্স প্যাকেজ ও প্রত্যাশিত আউটপুটসহ একটি লক্ষ্যভিত্তিক eval set-এ প্যাকেজ করা হয়েছে, Codex পণ্যের scaffold-এর ভেতরেই সরাসরি মূল কারণ অনুসন্ধান করতে পারে.

Codex শুধু নিম্নমানের চূড়ান্ত আউটপুট নিয়ে কাজ করছে না. এটি trace, eval, repo এবং skills একসঙ্গে পরীক্ষা করে:

• pipeline অনুসন্ধান করুন: সোর্স প্যাকেজ, extraction schema, mapper-এর আচরণ এবং code path পরীক্ষা করে নির্ধারণ করুন সমস্যাটি unsupported field, মিস হওয়া extraction pattern, source-selection সমস্যা, mapper gap, নাকি grader issue.
• লক্ষ্যভিত্তিক সংশোধন বাস্তবায়ন করুন: extraction schema সম্প্রসারণ করুন, ভাড়ার-সম্পত্তি নথির জন্য source selection উন্নত করুন, tax-engine mapper আপডেট করুন, অথবা প্রত্যাশিত workflow noise-কে ব্যর্থতা হিসেবে গণনা করা হলে grader পরিমার্জন করুন.
• যাচাই ও প্রস্তাব দিন: লক্ষ্যভিত্তিক eval আবার চালান, আরও বিস্তৃত regression suite চালান, এবং ইঞ্জিনিয়ারিং পর্যালোচনার জন্য একটি সম্ভাব্য pull request উপস্থাপন করুন.
• লুপ সম্পূর্ণ করুন: পুনরাবৃত্ত প্র্যাকটিশনার সংশোধনকে পরিমাপযোগ্য ইঞ্জিনিয়ারিং কাজে পরিণত করুন. যদি প্রমাণ অস্পষ্ট হয় বা নিরাপদভাবে স্বয়ংক্রিয় করা না যায়, তবে কেসটিকে জোর করে লুপে না ঢুকিয়ে আবার পণ্য দলের কাছে পাঠানো হয়.

ভাড়ার সম্পত্তির উদাহরণটি আরও বিস্তৃত পুনর্ব্যবহারযোগ্য একটি প্যাটার্নের প্রতীক: প্রোডাকশন আর্টিফ্যাক্ট ও ট্রেস ব্যবহার করে একটি এজেন্টের সক্ষমতা উন্নত করা. প্রোডাকশন ডেটা থেকে পর্যালোচিত ফলাফল, সোর্স ট্রেস, প্রত্যাশিত tax-engine output, প্রাসঙ্গিক code example এবং eval command-কে ইনপুটের একটি সেট হিসেবে দিলে, Codex সপ্তাহ ও মাসজুড়ে কর্মক্ষমতা ও নির্ভুলতায় বাস্তব উন্নতি আনতে পারে. এটি harness engineering এবং Symphony নিয়ে আমাদের কাজের বর্ণিত নীতির ওপর ভিত্তি করে তৈরি, যেখানে দেখানো হয়েছে কীভাবে কাজগুলোকে Codex-এর কাছে বোধগম্য করা যায়, সীমিত প্রাসঙ্গিকতা ও টুল দেওয়া যায়, এবং validation ও মানব পর্যালোচনাকে পরিবেশের অংশ রাখা যায়. 

এই প্রমাণ স্বয়ংক্রিয়ভাবে Codex-এর কাজ হয়ে যায় না. একটি প্র্যাকটিশনার সংশোধন extraction miss, mapping issue, unsupported product behavior, tax judgment, অথবা প্রত্যাশিত workflow noise প্রতিফলিত করতে পারে. শুধু তখনই, যখন পুনরাবৃত্ত পার্থক্যগুলো পর্যালোচনা করে কার্যকর ফলাফলে গ্রুপ করা হয়, সিস্টেম সেগুলোকে স্পষ্ট সাফল্য-শর্তসহ একটি সীমাবদ্ধ কাজে পরিণত করে.

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

Codex-এর জন্য ফলাফলটি অস্পষ্ট সতর্কতা নয়, বরং প্রমাণ, সম্পাদনাযোগ্য পণ্য-পৃষ্ঠ এবং স্পষ্ট validation gate-সহ একটি সীমিত ইঞ্জিনিয়ারিং কাজ. একটি প্রতিনিধিত্বমূলক ভাড়ার সম্পত্তি কাজের প্রেক্ষাপট সংক্ষেপে এভাবে বলা যায়:

একই লুপ ভাড়ার সম্পত্তির বাইরেও প্রযোজ্য. ভাড়ার সম্পত্তির ক্ষেত্রে 90% precision এবং recall-এ পৌঁছাতে প্রায় ছয় সপ্তাহ ও উল্লেখযোগ্য ইঞ্জিনিয়ারিং তদারকি লেগেছিল, কিন্তু সেই কাজ পুনর্ব্যবহারযোগ্য abstraction, review artifact, eval convention এবং implementation pattern তৈরি করেছে, যা Schedule C এবং Schedule A-এর মতো একইভাবে জটিল schedule সমর্থন করা সহজ করেছে.

Tax AI স্ব-উন্নয়নশীল এজেন্ট তৈরির একটি পথ প্রমাণ করে. প্র্যাকটিশনাররা সেবা প্রদান করতে গিয়ে উচ্চ-মূল্যের প্রতিক্রিয়া সংকেত তৈরি করেন. পণ্যের workflow-গুলো সেই সংকেতগুলোকে structured evidence হিসেবে সংরক্ষণ করে. Eval-সমর্থিত ইঞ্জিনিয়ারিং সিস্টেম উন্নতিগুলো প্রোডাকশনে পৌঁছানোর আগে যাচাই করে, এবং এজেন্ট-চালিত একটি লুপ সিস্টেমটিকে ধারাবাহিক স্ব-উন্নয়নের প্রবাহে রাখে. 

Thrive Holdings-এর কাঠামো আমাদের নির্দিষ্ট শিল্পে এই পরিবেশ পুনরায় তৈরি করতে দেয়. Holdings একই সঙ্গে owner এবং Operator, তাই আমাদের যৌথ ইঞ্জিনিয়ারিং দলগুলো Crete-এর মতো ব্যবসার ভেতর থেকেই প্র্যাকটিশনার ও প্রোডাকশন ডেটার সঙ্গে সরাসরি কাজ করতে পারে, vendor হিসেবে নয়, অংশীদার হিসেবে. এর মানে প্রযুক্তি, পণ্য এবং সেবা—সবই একই ছাদের নিচে থাকে, যাতে আমরা দ্রুত এগোতে এবং অসাধারণ পণ্য তৈরি করতে পারি.

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

একসঙ্গে, আমাদের দলগুলো এখন Tax AI-এর একই তিন-অংশের নকশাকে Thrive Holdings⁠(একটি নতুন উইন্ডোতে খোলে) জুড়ে অন্যান্য ডোমেইনে workflow তৈরির নকশা হিসেবে ব্যবহার করছে; যেমন হিসাবরক্ষণ workflow—bookkeeping ও audit, এবং অপারেশনাল workflow—যেমন IT help desk automation. ডোমেইন ও শিল্পজুড়ে, স্ব-উন্নয়নশীল এজেন্টের বৃহত্তর প্রতিশ্রুতি অটুট. সেরা এজেন্টগুলো মানুষ দ্বারা পরিচালিত হয়, যাতে তারা সময়ের সঙ্গে আরও সক্ষম, আরও বিশ্বস্ত এবং আরও মূল্যবান হয়ে উঠতে শেখে.

এই প্রকল্পে কাজ করা OpenAI দলের সম্পর্কে আরও জানতে, যোগাযোগ করুন.