Claude এখন lab equipment চালাবে: MHS integration নামাবে মিনিটে

Anthropic ২৭ আগস্ট ২০২৬ Model Hardware Standard বা MHS-এর সীমিত research preview চালু করেছে। Anthropic-এর ঘোষণায় microscope, liquid handler ও robotic arm-এর মতো যন্ত্রকে shared interface দিয়ে Claude-সহ AI agent-এর নিয়ন্ত্রণে আনা এবং আগে থেকে উপযুক্ত setup-এ integration-এর কাজ সপ্তাহ বা মাস থেকে ঘণ্টা বা মিনিটে নামানোর কথা বলা হয়েছে।

এটি এখনো সাধারণভাবে উন্মুক্ত standard বা প্রস্তুত commercial product নয়; প্রথম পর্যায়ে নির্বাচিত গবেষণাগার ও advanced manufacturer-দের নিয়ে পরীক্ষা চলছে। ২৭ আগস্টের Reuters-এর প্রতিবেদন research preview-এর এই সীমিত অবস্থান এবং open-source করার আগে অংশীদারদের সঙ্গে safety evaluation তৈরির পরিকল্পনা নিশ্চিত করেছে।

Common driver কোথায় integration কমায়

Laboratory ও factory equipment সাধারণত নিজস্ব command format, software এবং programming interface ব্যবহার করে। একই workflow-তে microscope, plate reader ও robotic arm বসাতে হলে প্রতিটি যন্ত্রের জন্য আলাদা সংযোগ লিখতে হয়; কোনো component বদলালে সেই সংযোগ আবার পরীক্ষা করাও প্রয়োজন হতে পারে।

MHS এই বিচ্ছিন্নতার ওপর একটি standard driver contract বসায়। এর অর্থ সব যন্ত্রে একই binary driver নয়; বরং প্রতিটি device-এর MHS driver একই ধরনের primitive operation—যেমন কোনো মান পেতে read এবং parameter বদলাতে write—প্রকাশ করে। নিচের স্তরে সংশ্লিষ্ট driver সাধারণ command-কে vendor API, SDK, scripting interface, job file বা প্রয়োজন হলে GUI control-এ অনুবাদ করে।

তাই শিরোনামের “মিনিটে integration” যন্ত্র বসানো, calibration বা পুরো experiment শেষ হওয়ার সময় নয়। এটি মূলত MHS-এ onboard করা পরিবেশে নতুন component-কে shared workflow-তে যুক্ত করার software effort: HHMI Janelia-র একটি microscopy rig-এ আগে multi-day কাজ লাগলেও নতুন camera যোগ করা কয়েক মিনিটে নেমেছিল। নতুন driver তৈরি, hardware validation এবং protocol পরীক্ষা করতে যন্ত্রভেদে আরও সময় লাগবে।

Discovery metadata থেকে command যাওয়ার flow

MHS-এর সেতুটি command translation-এ শেষ হয় না। Driver যন্ত্রকে standard format-এ discoverable করে এবং তার state, sensor value, adjustable parameter ও available procedure একটি অভিন্ন description-এ প্রকাশ করে। ফলে agent জানতে পারে কোন যন্ত্র network-এ আছে, সেটি এখন কোন অবস্থায় এবং কী কাজ করতে পারে।

Driver tag-এ এমন physical তথ্যও যোগ করা যায়, যা শুধু source code দেখে বোঝা যায় না—যেমন robot arm-এর ওজন বা কোনো parameter-এর কার্যকর safety limit। Natural language-এ দেওয়া এই তথ্য থেকে reference file তৈরি হয়, যেখানে যন্ত্র কী মাপে, কোন মান বদলানো যায় এবং কোন সীমা কার্যকর হবে তা লেখা থাকে। Flow-টি তাই: device-specific driver → discovery ও physical metadata → agent-readable capability → অনুমোদিত command।

Hardware control-এর তিনটি পথ রাখা হয়েছে: Model Context Protocol বা MCP, command-line interface এবং code file বা API। Agent উচ্চস্তরে ধাপ সাজাতে, ফল পর্যবেক্ষণ করতে ও parameter বদলাতে পারে; দীর্ঘ বা দ্রুত কাজের জন্য একাধিক driver command deterministic code file-এ গাঁথা যায়। এতে প্রতিটি motor movement বা measurement-এর মাঝখানে model-এর নতুন করে reasoning করার প্রয়োজন থাকে না।

কোন যন্ত্রে Claude কাজ করেছে

প্রাথমিক project-গুলো universal compatibility test নয়, তবে বিভিন্ন control system-এ MHS-এর ব্যবহার দেখিয়েছে। Genentech-এর proof of concept-এ Claude liquid handler, robotic arm ও plate reader সমন্বয় করে protein concentration মাপার BCA assay চালিয়েছে। আর Janelia-র microscopy rig-এ সাতটি vendor program-এর variable, control ও sensor value একটি shared interface-এ আনা হয়েছে।

আরেকটি laboratory setup-এ robotic arm job-file watcher দিয়ে, liquid handler পুরোনো Windows COM scripting দিয়ে এবং API-বিহীন plate reader তার GUI দিয়ে নিয়ন্ত্রিত হয়েছে। MHS সেখানে তিন যন্ত্রের state ও procedure একটি manifest-এ এনেছে; camera plate-এর উপস্থিতি ও orientation যাচাই করার পরই robotic transfer অনুমোদিত হয়েছে। এটি দেখায় যে পুরোনো interface-ও driver-এর আড়ালে আনা সম্ভব, কিন্তু প্রতিটির জন্য কার্যকর adapter ও স্থানীয় validation লাগবে।

Programmable interface নেই—এমন hardware এখনো MHS-এর ঘোষিত সীমার বাইরে। GUI automation-নির্ভর উদাহরণটিও এই সীমা দূর করে না: software-এ নিয়ন্ত্রণযোগ্য surface থাকতে হয় এবং screen-এ যা দেখা যায়, তার বাইরে কাজ সঠিক হয়েছে কি না যাচাই করার জন্য sensor বা অন্য safeguard দরকার।

Physical safety শুধু tag-এর দায়িত্ব নয়

MHS driver-এ device-level restriction ও safety limit লেখা এবং প্রয়োগ করা যায়। কিন্তু tag নিজে যন্ত্রকে নিরাপদ করে না: সীমাটি সঠিক হতে হবে, driver-কে সেটি enforce করতে হবে এবং reported state-এর সঙ্গে যন্ত্রের বাস্তব অবস্থা মিলতে হবে। ভুল sensor reading, অসম্পূর্ণ metadata বা ত্রুটিপূর্ণ adapter থাকলে অনুমোদিত command থেকেও ক্ষতিকর physical ফল হতে পারে।

WIRED-এর বিশ্লেষণে physical system ক্ষতিগ্রস্ত হওয়া, মানুষ আহত হওয়া এবং model-কে বিভ্রান্ত করে robot-এর ভুল আচরণ ঘটানোর ঝুঁকি তুলে ধরা হয়েছে। বর্তমান প্রতিরক্ষা তাই কয়েক স্তরের: driver-এ device-specific limit, model-level guardrail, স্থানীয় sensor ও hardware interlock, ঝুঁকিপূর্ণ সিদ্ধান্তে মানুষের অনুমোদন এবং প্রতিষ্ঠানের নিজস্ব laboratory বা factory safety procedure।

প্রাথমিক পরীক্ষাও expert oversight-এর প্রয়োজন দেখিয়েছে। Protein sample-এ foam তৈরি হলে Claude প্রথমে সেটিকে physical failure হিসেবে বুঝতে পারেনি; গবেষকদের নির্দেশনা প্রয়োজন হয়েছিল। Text ও image থেকে শেখা model-এর spatial ও physical reasoning সীমিত হওয়ায় MHS safety certification, emergency stop বা laboratory protocol-এর বিকল্প নয়—এটি ওই সীমা ও যন্ত্রের অবস্থা agent-এর control path-এ প্রকাশ করার specification।

Preview শেষে কোন প্রমাণ দরকার

বর্তমান access আবেদনভিত্তিক research preview-তে সীমাবদ্ধ এবং open-source release-এর নির্দিষ্ট তারিখ প্রকাশিত হয়নি। Preview চলাকালে অংশীদারদের সঙ্গে অতিরিক্ত safety evaluation, deployment practice ও misuse protection তৈরির পরিকল্পনা আছে; standard open-source হলে পরীক্ষার findings-সহ নিরাপদ deployment guidance প্রকাশ করার কথা।

এখন বড় প্রশ্ন হলো, বিভিন্ন vendor-এর driver একইভাবে safety tag enforce করে কি না এবং agent ভুল সিদ্ধান্ত নিলে hardware-level protection কত দ্রুত হস্তক্ষেপ করে। “মিনিটে integration” একটি বাস্তব partner example দিয়ে সমর্থিত হলেও সব laboratory বা factory setup-এর সাধারণ ফল নয়; বিস্তৃত independent test, driver conformance ব্যবস্থা এবং বাস্তব incident data ছাড়া সেই দাবি সর্বজনীন ধরে নেওয়া যাবে না।