কাজের ভবিষ্যৎ

UST Codon পাঁচ enterprise platform-এ লিখবে—অজানা action নিজেই থামবে

|লেখক: QUASA সম্পাদকীয় দল|5 মিনিটের পাঠ| 1
UST Codon পাঁচ enterprise platform-এ লিখবে—অজানা action নিজেই থামবে

UST ১ সেপ্টেম্বর ২০২৬ UST Codon চালুর ঘোষণা দিয়েছে—একটি AI-সহায়িত workspace, যা plain-English requirement থেকে ServiceNow, SAP, Salesforce, Oracle Fusion ও Workday-এ application ও workflow তৈরি বা বদলাতে পারে। Business+IT-এর প্রতিবেদন ঘোষণার তারিখ, পাঁচটি target platform এবং প্রতিটি output-এ UST expert review থাকার বিষয়টি নিশ্চিত করেছে।

Codon-এর ঘোষিত নিয়ন্ত্রণ অনুযায়ী AI-এর তৈরি change সরাসরি production-এ যাওয়ার কথা নয়: UST expert validation-এর পর সেটি গ্রাহকের প্রচলিত development ও approval path অনুসরণ করবে। প্রতিটি operation read না write তা চিহ্নিত করা না গেলে execution থামবে—শিরোনামের “নিজেই থামবে” বলতে এই fail-closed আচরণই বোঝানো হয়েছে, স্বয়ংক্রিয়ভাবে সব ধরনের ভুল শনাক্ত করার নিশ্চয়তা নয়।

এক workspace থেকে পাঁচটি আলাদা platform

Codon একই governed surface থেকে পাঁচটি enterprise platform-কে target করে, কিন্তু সেগুলোকে একটি অভিন্ন runtime বা data model-এ পরিণত করে না। সমর্থিত platform হলো ServiceNow, SAP, Salesforce, Oracle Fusion ও Workday; developer-কে requirement-এর সঙ্গে নির্দিষ্ট target-টিও জানাতে হয়।

প্রতিটি target-এর জন্য নিজস্ব governed MCP server ও সংশ্লিষ্ট platform SDK ব্যবহারের কথা বলা হয়েছে। Codon requirement বুঝে উপযুক্ত সংযোগ নির্বাচন করে এবং গ্রাহকের configuration অনুযায়ী build-এর খসড়া প্রস্তুত করে। ফলে “পাঁচ platform-এ লিখবে” মানে একই request একযোগে পাঁচ system-এ নির্বিচারে পরিবর্তন করবে না; নির্ধারিত platform-এর জন্য change তৈরি করবে।

কাজের জন্য দুটি interface বর্ণিত হয়েছে। Chat channel catalog, workflow, configuration ও documentation-এর মতো natural-language কাজের জন্য; terminal channel platform CLI ও SDK-নির্ভর জটিল বা দীর্ঘ build, verification এবং iteration-এর জন্য। Interface আলাদা হলেও governance engine একই থাকার কথা।

Requirement থেকে live change: পাঁচ ধাপ

ঘোষিত workflow-এ plain-language request ও production change-এর মাঝে planning, attribution, expert validation এবং গ্রাহকের approval path রাখা হয়েছে। ধাপগুলো হলো:

  1. Describe: developer সাধারণ ইংরেজিতে requirement লেখেন এবং target platform নির্দিষ্ট করেন। Business intent, scope ও expected result পরিষ্কার করার দায়িত্ব এখানেই শুরু হয়।
  2. Design: Codon কাজের পরিকল্পনা করে, উপযুক্ত governed MCP server বেছে নেয় এবং গ্রাহকের configuration-এর বিপরীতে draft তৈরি করে। এটি তখনো অনুমোদিত production change নয়।
  3. Build: নির্দিষ্ট platform-এ change তৈরি ও assemble হয়। ঘোষিত নকশায় build এই পর্যায়ে read-by-default থাকে এবং action-এর attribution সংরক্ষিত হয়।
  4. Validate: একজন senior UST practitioner প্রতিটি output review ও validate করেন। এই review না পেরিয়ে change live business system-এ পৌঁছানোর কথা নয়।
  5. Go live: validated build গ্রাহকের নিজস্ব governance ও promotion path পেরিয়ে system of record-এ কার্যকর change হয়।

এই বিন্যাসে Codon implementation-এর বড় অংশ তৈরি করতে পারে, কিন্তু requirement-এর যথার্থতা, access scope, business rule, test evidence এবং production promotion-এর সিদ্ধান্ত মানুষের কাছেই থাকে। UST reviewer output যাচাই করলেও customer-side developer, platform owner বা administrator-এর change-management দায়িত্ব শেষ হয় না।

অজানা write কোথায় থামবে

UST Codon-এর product page live system of record-এ write-এর জন্য classification, attribution, policy gate, reversibility ও audit এবং আগাম cost visibility—এই পাঁচ ধরনের control বর্ণনা করেছে। প্রতিটি tool call read বা write হিসেবে classified হবে; unknown বা ambiguous operation fail closed করবে, অর্থাৎ শ্রেণি নির্ধারিত না হলে সেটি চলবে না।

Attribution-এর একটি স্পষ্ট সীমা রয়েছে। Target platform সমর্থন করলে write ব্যক্তিগত developer identity দিয়ে সম্পন্ন হবে এবং acting principal রেকর্ড হবে। যেখানে individual attribution সমর্থিত নয়, সেখানে কোন service identity ব্যবহৃত হবে এবং তার কাজের জবাবদিহি কার—প্রকাশিত বর্ণনা সেই platform-specific ব্যবস্থা নির্ধারণ করে দেয় না।

Approved-build phase ও production rail live promotion নিয়ন্ত্রণ করে। Destructive action-এর জন্য explicit intent দরকার এবং activity tamper-evident, hash-chained audit trail-এ রেকর্ড হওয়ার কথা। তবে “reversible” মানেই সব platform-এ এক-click rollback বা একই recovery guarantee নয়; কোন artifact ফিরিয়ে নেওয়া যাবে এবং partial failure কীভাবে সামলানো হবে, তা deployment-এর আগে target platform অনুযায়ী স্থির করতে হবে।

Promotion-এর আগে কোন evidence মিলতে হবে

ঘোষিত control-গুলো সত্যিই একটি নির্দিষ্ট change-এ কাজ করেছে কি না, তা promotion record-এ দেখা দরকার। পাঁচ ধাপের workflow-এর সঙ্গে মিলিয়ে ন্যূনতম evidence হতে পারে:

  • Classification: প্রতিটি tool call-এর read/write শ্রেণি log-এ আছে কি এবং unknown বা ambiguous action block হওয়ার record রাখা হয়েছে কি না।
  • Attribution: requester, execution principal, UST reviewer ও final approver-কে আলাদাভাবে শনাক্ত করা যায় কি না।
  • Approval: validated build-এর সঙ্গে customer change ticket, test result, অনুমোদিত scope ও production window যুক্ত আছে কি না।
  • Rollback: destructive change-এর explicit intent, আগের configuration, dependency এবং recovery procedure সংরক্ষিত আছে কি না।
  • Cost preview: agentic run শুরুর আগে token charge ও UST expert input মিলিয়ে অনুমান দেখানো এবং গ্রহণ করা হয়েছে কি না।

এটি Codon-এর বাইরে নতুন governance framework নয়; product page-এ বর্ণিত control-গুলোকে যাচাইযোগ্য deployment evidence-এ রূপ দেওয়া। Developer-এর দায়িত্ব তাই request লেখায় শেষ হয় না: generated change, permission scope, test result ও rollback প্রস্তুতি যাচাই করে approval চাওয়াও কাজের অংশ।

গতির দাবি vendor-এর, স্বাধীন benchmark নয়

UST internal deployment-এ platform development প্রায় ৫০ শতাংশ দ্রুত হওয়া এবং আগে কয়েক মাস লাগা কিছু application এক সপ্তাহের মতো সময়ে সরবরাহ করার দাবি করেছে। VocMedia-এর মূল্যায়ন স্পষ্ট করেছে যে এই সংখ্যাগুলো UST-এর দেওয়া দাবি, সব application-এর সাধারণ delivery time বা স্বাধীন performance benchmark নয়।

প্রকাশিত পাতাগুলোতে customer-by-customer baseline, error rate, blocked operation-এর হার কিংবা rollback success rate দেওয়া হয়নি। Availability, platformভিত্তিক permission mapping, data-residency ব্যবস্থা ও commercial pricing-এর পূর্ণ শর্তও প্রকাশ্য বিবরণে স্পষ্ট নয়। ফলে এখন নিশ্চিত তথ্য হলো—Codon পাঁচটি নির্দিষ্ট platform-এ build তৈরি করে, expert review ও customer approval path বজায় রাখে এবং অশ্রেণিবদ্ধ operation থামানোর control দাবি করে; বাস্তব customer deployment-এর performance ও recovery evidence এখনো দেখার বাকি।

আরও পড়ুন:

শেয়ার করুন:

আমাদের নিউজলেটার নিন

সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।

0