"Prompt engineer" কখনোই কোনো সুনির্দিষ্ট পদবি ছিল না, কিন্তু কিছুকাল ধরে সেটার দরকারও ছিল না। যদি আপনার পুরো কাজ হতো একটিমাত্র inference call থেকে একটি ভালো উত্তর বের করা, তাহলে একটিমাত্র দক্ষতাই যথেষ্ট ছিল: নির্দেশনাটি ভালোভাবে লেখা, কয়েকটি উদাহরণ দেওয়া, হয়তো কিছু retrieved text যোগ করা—ব্যস, হয়ে গেল। সেই দক্ষতা এখনও গুরুত্বপূর্ণ। কিন্তু ২০২৬ সালের মাঝামাঝিতে "agent তৈরি করা" বলতে যা বোঝায়, তা এখন আর সেটুকুতেই সীমাবদ্ধ নেই, আর এই ফাঁকটা একটি নির্দিষ্ট, চেনা ব্যর্থতার ধরন হিসেবে সামনে আসছে: এমন agent যা ডেমোতে দারুণ কাজ করে, কিন্তু তারপর নীরবে ক্ষয়প্রাপ্ত হয়, নিজের সাথেই বিরোধিতা করে, অথবা ব্যবহারকারী দুই সেশন আগে কী বলেছিলেন তা ভুলে যায়।
Machine Learning Mastery-র একটি সাম্প্রতিক লেখা এই ফাঁকটিকে সরাসরি চিহ্নিত করে, এবং এটা নিয়ে ভাবার মতো, কারণ এটা এমন দুটি ভিন্ন কাজের সাথে স্পষ্টভাবে মিলে যায় যা করার জন্য আপনাকে প্রকৃতপক্ষে নিয়োগ দেওয়া হতে পারে। Context engineering হলো একটিমাত্র inference call-এর ভেতরে যা ঘটে: context window-এ কী কী থাকবে, সেগুলো কাঠামোগতভাবে কোথায় বসবে, আর কী compress বা বাদ দেওয়া হবে যাতে মডেলটি অপ্রাসঙ্গিক token-এর ভারে ডুবে না যায়—এসব ঠিক করা। Memory engineering একেবারে ভিন্ন একটি সমস্যা, যা কেবল একাধিক call জুড়েই থাকে: একটি সেশন শেষ হওয়ার পর কী লিখে রাখা হবে, সেটা কোথায় সংরক্ষিত হবে, পরের বার সেটা কীভাবে retrieve করা হবে, আর কীভাবে সেটা রক্ষণাবেক্ষণ করা হবে (আপডেট, ডুপ্লিকেট বাদ দেওয়া, মেয়াদ শেষ করা) যাতে সেটা নষ্ট না হয়ে যায়। ওই লেখা অনুযায়ী, দীর্ঘ, একাধিক-সেশনের agent workflow-এ যে ব্যর্থতাগুলো দেখা যায়, সেগুলোর উৎস প্রায়ই এই দুটি কাজকে গুলিয়ে ফেলা, অথবা এর একটিকে বাদ দেওয়া—বিশেষ করে তারা যাকে বলছে "retrieval boundary," অর্থাৎ সেই মুহূর্ত যখন একটি agent-কে ঠিক করতে হয় যে তার প্রয়োজনীয় কোনো কিছু তার সামনেই আছে, নাকি সেটা storage থেকে আনতে হবে।
এগুলোকে গুলিয়ে ফেলাই আসল বাগ, শুধু একটা খুঁটিনাটি বিষয় নয়
প্রতিটি শাখা আসলে কী optimize করার চেষ্টা করছে, সেটা একবার ভাবুন। Context engineering একটি একক, সীমাবদ্ধ, এককালীন ব্যবহারের window optimize করে—এই মুহূর্তে, এই একটি মাত্র বিনিময়ের জন্য, মডেলের সামনে তথ্যের সঠিক অংশটুকু হাজির করা, তারপর বাকিটা ফেলে দেওয়া। Memory engineering optimize করে একটি টেকসই ভাণ্ডার, যাকে একাধিক সেশন জুড়ে টিকে থাকতে হয়, নতুন তথ্য এলে সামঞ্জস্যপূর্ণ থাকতে হয়, আর অনেক কঠিন একটা প্রশ্নের উত্তর দিতে হয়—"এই প্রম্পটের সাথে কী প্রাসঙ্গিক" নয়, বরং "আদৌ কী রাখার মতো, আর কতদিনের জন্য।"
এগুলো ভিন্ন ভিন্ন design সমস্যা, আর তাদের ব্যর্থতার ধরনও ভিন্ন। একটি context-engineering ভুল একটিমাত্র উত্তরকে খারাপ করে দেয়। একটি memory-engineering ভুল জমতে থাকে—খারাপ লেখাগুলো জমা হতে থাকে, পুরনো তথ্যকে হালনাগাদ মনে করে retrieve করা হয়, আর কেউ খেয়ালই করে না যতক্ষণ না agent-টি আত্মবিশ্বাসের সাথে এমন কিছু আবার বলে যা তিন সেশন আগেই সংশোধন করা হয়েছিল। যদি একজন মানুষ (বা একটি prompt template) নীরবে এই দুটো কাজই করে যায় সেগুলোকে আলাদা না করে, তাহলে memory layer প্রায়ই context-engineering-এর এমন অভ্যাস উত্তরাধিকারসূত্রে পায় যা তার পাওয়া উচিত নয়: একটি window-কে যেভাবে বেশি ঠাসা হয়, সেভাবে storage-কেও বেশি ঠাসা করা, অথবা retrieval-কে একটি relevance-ranking সমস্যা হিসেবে দেখা, যখন আসলে সেটা একটি curation-and-maintenance সমস্যা। এটাই সেই গুলিয়ে ফেলাটা, যেদিকে research digest-টি ইঙ্গিত করছে, আর এটা এমন কিছুর সাথে মিলে যায় যা practitioner-রা ইতিমধ্যেই কিসসা আকারে বলে থাকেন: এমন agent যারা একটি সেশনে চমৎকার, আর পঞ্চম সেশনে অনির্ভরযোগ্য।
প্রতিদিনের কাজে প্রতিটি ভূমিকা আসলে কেমন দেখায়
আপনি যদি বোঝার চেষ্টা করেন যে আপনি ইতিমধ্যে এর মধ্যে কোনটা করছেন, বা কোনটার দিকে এগোতে চান, তাহলে দৈনন্দিন কাজটা যথেষ্ট আলাদা দেখতে, যাতে আলাদা করে চেনা যায়:
Context engineering, বাস্তবে যা করা হয়: উপলব্ধ তথ্যের (নথি, tool output, আগের turn) কোন অংশটুকু আসলে এই call-এ থাকা উচিত তা ঠিক করা; prompt-এর কোথায় সেটা বসবে তা বেছে নেওয়া, যেহেতু অবস্থান মডেল সেটাকে কতটা গুরুত্ব দেবে তা প্রভাবিত করে; compression বা summarization ধাপ লেখা যাতে একটি লম্বা tool trace পুরো budget খেয়ে না ফেলে; আর একই মডেলের ওপর ভিত্তি করেও একটি debugging agent আর একটি লেখালেখির agent ভিন্ন ভিন্ন context আকার চায় বলে, প্রতিটি কাজ অনুযায়ী এটা সূক্ষ্মভাবে সামঞ্জস্য করা।
Memory engineering, বাস্তবে যা করা হয়: একটি write policy ঠিক করা (একটি সেশনের পর কী কী সংরক্ষণ করার মতো—সবকিছু নয়); একটি storage layer বেছে নেওয়া (vector store, structured database, সাধারণ file, বা কোনো hybrid) এবং প্রতিটির trade-off সম্পর্কে সৎ থাকা; এমন একটি retrieval strategy তৈরি করা যা ঠিক করে কী কখন ফিরে আসবে; আর চলমান রক্ষণাবেক্ষণ করা—ছাঁটাই করা, ডুপ্লিকেট তথ্য একত্র করা, ব্যবহারকারী মত বদলালে বিরোধপূর্ণ তথ্য সামলানো। শেষের অংশটা, অর্থাৎ রক্ষণাবেক্ষণ, সেটাই মানুষ সবচেয়ে বেশি এড়িয়ে যায়, কারণ একটি agent সপ্তাহের পর সপ্তাহ চলার আগ পর্যন্ত সেটা চোখেই পড়ে না।
শিল্পক্ষেত্রে এই বিষয়গুলোকে কাঠামোগতভাবে আলাদা করার প্রবণতা দেখা যাচ্ছে, শুধু ধারণাগতভাবে নয়। Claude Agent SDK-এর ওপর একটি debugging harness তৈরির বিষয়ে Lenny's Newsletter-এর walkthrough permission, tool adapter, এবং চারপাশের "harness"-কে তার ভেতরের prompting থেকে আলাদা একটি নিজস্ব engineering ক্ষেত্র হিসেবে দেখে—একই সহজাত বোধ, কিন্তু ভিন্ন একটি সংযোগস্থলে প্রয়োগ করা হয়েছে। আর Google-এর নতুন Gemini API "Managed Agents" বৈশিষ্ট্যগুলো—background execution, interaction জুড়ে credential refresh—কার্যত platform vendor-এর নিজেই স্বীকার করা যে session-persistent state এখন এমন একটি infrastructure যা design করতে হয়, শুধু যথেষ্ট লম্বা একটি context window-এর পার্শ্বপ্রতিক্রিয়া নয়। কাউকে না কাউকে এই design-এর দায়িত্ব নিতে হবে। অনেক দলেই, এখন পর্যন্ত, স্পষ্টভাবে কেউই সেটা নেয় না।
এটা কেন আপনার job title-এর জন্য গুরুত্বপূর্ণ, শুধু আপনার কোডের জন্য নয়
আপনি যদি early বা mid-career-এ থাকেন এবং আপনার resume-এ "prompt engineer" বা "AI engineer" লেখা থাকে, তাহলে জিজ্ঞেস করার মতো বিষয় হলো—এই দুটো কাজের মধ্যে কোনটা আপনি সত্যিই করেছেন তার প্রমাণ দেখাতে পারেন—কারণ সাধারণ AI-agent ভূমিকাগুলো আরও নির্দিষ্ট ভূমিকায় ভেঙে যেতে শুরু করেছে, ঠিক যেভাবে একদিন "webmaster" শেষ পর্যন্ত frontend, backend, আর DevOps-এ ভাগ হয়ে গিয়েছিল। এটা একটা headline নয়, বরং একটা সতর্কতা: "memory engineer"-কে একটি স্বতন্ত্র পদবি হিসেবে নিশ্চিত করার মতো কোনো কঠিন নিয়োগ-তথ্য আমি এখনও দেখিনি, তাই এটাকে কাজের গতিপথের একটি পাঠ হিসেবে দেখুন, এমন দাবি হিসেবে নয় যে job board-গুলো ইতিমধ্যে এভাবে সাজানো হয়ে গেছে। কিন্তু এর পেছনের চাপটা বাস্তব, আর উপরের digest-এর সাথে সরাসরি সংযুক্ত: agent দলগুলো একটি নির্দিষ্ট, নামযুক্ত ব্যর্থতার (multi-session degradation) মুখোমুখি হচ্ছে, যার একটি নির্দিষ্ট, নামযুক্ত কারণ আছে (দুটো শাখাকে গুলিয়ে ফেলা), আর এই সমন্বয়টাই সাধারণত একটা ঝাপসা ভূমিকাকে দুটো স্পষ্ট ভূমিকায় রূপান্তরিত করে।
বাস্তবসম্মত পদক্ষেপ হলো নিজের জন্য একটা পদবি বানিয়ে ফেলা নয়। বরং সুনির্দিষ্টভাবে উত্তর দিতে পারা যে আপনি আসলে কোন সমস্যাটা সমাধান করেছেন। আপনি কি এমন কিছু তৈরি করে সরবরাহ করেছেন যেখানে আপনি একটি write policy design করেছেন—একটি নিয়ম যা ঠিক করে একটি agent memory-তে কী জমা রাখবে আর কী বাদ দেবে? আপনি কি কোনো retrieval-boundary ব্যর্থতা debug করেছেন, যেখানে একটি agent-এর storage থেকে কিছু দরকার ছিল আর হয় সেটা আনেইনি, নয়তো ভুল সংস্করণ এনেছে? এগুলো এমন দাবি যা interview-তে যাচাই করা যায়, কোনো repo বা postmortem দিয়ে সমর্থিত, আর এগুলো এমন কিছু বলে যা সাধারণ "আমি ভালো prompt লিখি" বলে না: যে আপনি বোঝেন একটিমাত্র উত্তরকে ভালো করার আর সময়ের সাথে একটি agent-কে নির্ভরযোগ্য করে তোলার মধ্যে পার্থক্যটা কী।
একটা সতর্কবার্তা
একবার কোনো প্রজেক্টে vector database যোগ করেছেন বলেই নিজেকে "memory engineer" নাম দিয়ে ফেলবেন না। যে শাখার দিকে এই গবেষণা ইঙ্গিত করছে, তার মধ্যে সেই কম চাকচিক্যময় অর্ধেকটাও আছে—রক্ষণাবেক্ষণ, মেয়াদ শেষ করা, বিরোধ সামলানো—আর সেই অর্ধেকটাই আসলে ওপরে বর্ণিত ব্যর্থতার ধরনটাকে ঠেকায়। যদি আপনার portfolio-র কাজটা এমন একটি সিস্টেম হয় যা memory-তে লেখে কিন্তু কখনো কিছু ছাঁটাই বা সংশোধন হয় না, তাহলে আপনি একজন memory engineer-এর কাজের অর্ধেকটাই তৈরি করেছেন, আর তৃতীয় সেশনের পর ব্যর্থ হওয়ার সমস্যাটা তখনও বাকি অর্ধেকে আপনার জন্য অপেক্ষা করছে।