আমি কীভাবে OpenSecondBrain তৈরি করেছি
আমি বেশ কিছুদিন ধরে বিভিন্ন AI টুল ব্যবহার করছি, কিন্তু একপর্যায়ে বুঝতে পারলাম: আমি শুধু সেগুলো ব্যবহার করছি না, প্রায় পুরোপুরি এজেন্ট এবং AI-সম্পর্কিত সবকিছুতে “ঘেঁটে” গেছি।
বেশ কয়েক মাস ধরে এজেন্টরা আমার ওয়ার্কফ্লো অনুযায়ী কোড লিখছে: পরিকল্পনা, বাস্তবায়ন, রিভিউ, সংশোধন, পুনঃপরীক্ষা। এটি কাজ করে, কিন্তু প্রক্রিয়াটির একটি অদ্ভুত ম্যানুয়াল অংশ রয়ে গেছে। এজেন্ট কোড লিখলেও, আমাকেই কাজগুলো পর্যায়ের মধ্যে সরাতে হয়, কন্টেক্সট স্থানান্তর করতে হয়, নিয়ম মনে করিয়ে দিতে হয়, পরীক্ষা চালাতে হয় এবং নিশ্চিত করতে হয় যে পরবর্তী কর্মী বুঝতে পেরেছে ইতিমধ্যে কী হয়েছে।
পুনরাবৃত্তিমূলক কাজ অনেক বেড়ে গেছে। তাই পরবর্তী স্বাভাবিক পদক্ষেপ আরেকটি ফিচার নয়, বরং ওয়ার্কফ্লো নিজেকেই অটোমেট করা।
এভাবেই তৈরি হলো OpenSecondBrain প্রজেক্ট — এজেন্টদের স্বাভাবিক মেমোরি দেওয়ার একটি প্রচেষ্টা, যাতে তারা জানতে পারে আমরা কী করছি, কেন করছি এবং ইতিমধ্যে কী সিদ্ধান্ত নেওয়া হয়েছে।
ম্যানুয়াল ওয়ার্কফ্লো থেকে Dark Fabric পর্যন্ত
প্রথম পোস্টে আমি লিখেছিলাম কীভাবে কোডিং এজেন্টের সাহায্যে এই ব্লগ চালু করেছি। সেখানে ওয়ার্কফ্লো ইচ্ছাকৃতভাবে সহজ রাখা হয়েছিল: কন্টেক্সট দেওয়া, Astro প্রজেক্ট সেট আপ করা, ডিজাইন পাস করা, পোস্টার যোগ করা, ফলাফল পরীক্ষা করা।
কিন্তু আমার স্বাভাবিক প্রক্রিয়া আরও জটিল। এতে রয়েছে ভূমিকা, মধ্যবর্তী রিভিউ, বিভিন্ন ধরনের কাজের জন্য আলাদা এজেন্ট এবং প্রতিটি ধাপে মান নিয়ন্ত্রণ। যখন এই ধরনের কাজ বাড়তে থাকে, মানুষটি একজন ডিসপ্যাচারে পরিণত হয়: কন্টেক্সট এখানে সরাও, তাকে ওটা পরীক্ষা করতে বলো, পরবর্তী এজেন্টকে আগের এজেন্টের আউটপুট দাও, সিদ্ধান্ত লিখে রাখতে ভুলো না।
আমি একটি আরও কঠোর মডেলে পৌঁছাতে চেয়েছি, যা ক্রমশই Dark Fabric নামে পরিচিত হচ্ছে: ইনপুটে একটি ফিচারের ধারণা, আউটপুটে ফিচার বাস্তবায়িত, পরীক্ষিত এবং ডিপ্লয় করা। “এজেন্ট কোডের একটি অংশ লিখেছে” নয়, বরং একটি ফ্যাক্টরি যা নিজে কাজকে পর্যায়ে ভাগ করতে পারে এবং প্রক্রিয়ার মধ্য দিয়ে পরিচালনা করতে পারে।
সম্পূর্ণ Dark Fabric এখনও অনেক দূরে। কিন্তু প্রথম ব্যবহারিক পদক্ষেপ ইতিমধ্যে নেওয়া হয়েছে: VPS-এ চলমান Hermes, বিভিন্ন কাজের জন্য এজেন্ট, স্কিল, Telegram ইন্টারফেস এবং OmniRoute এর মাধ্যমে সস্তা মডেল রাউটিং সহ।
এবং প্রায় সাথে সাথেই এই ফ্যাক্টরির দ্বিতীয় অপরিহার্য অংশ আবিষ্কৃত হলো: এজেন্টদের মেমোরি প্রয়োজন।
এজেন্টের জন্য Second Brain কেন প্রয়োজন
যদি এজেন্ট একটি সেশনে কাজ করে, তাহলে সহজভাবে প্রম্পটে কন্টেক্সট দেওয়া যায়। যদি এজেন্ট সপ্তাহভর প্রজেক্টে কাজ করে, তা যথেষ্ট নয়।
তাকে জানতে হবে:
- প্রজেক্টে ইতিমধ্যে কী নিয়ম গৃহীত হয়েছে;
- কী সিদ্ধান্ত নিয়ে আলোচনা হয়েছে এবং কেন ঠিক সেগুলো বেছে নেওয়া হয়েছে;
- তদন্তের সময় কী তথ্য পাওয়া গেছে;
- ইতিমধ্যে কী কী আর্টিফ্যাক্ট তৈরি হয়েছে;
- কাজে কোন কোন এজেন্ট অংশ নিয়েছে;
- মানুষের নলেজ বেস কোথায়, আর এজেন্টের সার্ভিস এরিয়া কোথায়।
এবং সবচেয়ে গুরুত্বপূর্ণ — এটি শুধুমাত্র “মডেলের মেমোরির” উপর নির্ভর করা উচিত নয়। আমার একটি সহজ, যাচাইযোগ্য, ফাইল-ভিত্তিক নলেজ সিস্টেম দরকার যা হাতে খুলতে পারি, Obsidian-এ পড়তে পারি, সিঙ্ক করতে পারি, আংশিকভাবে কমিট করতে পারি বা আর কমিটই না করতে পারি।
তাই open-second-brain শুরু থেকেই “আরেকটি মেমোরিযুক্ত চ্যাটবট” হয়ে ওঠেনি, বরং Markdown vault কে কেন্দ্র করে একটি ছোট ইনফ্রাস্ট্রাকচার হয়ে উঠেছে।
Obsidian এবং Markdown কেন
Obsidian-সামঞ্জস্যপূর্ণ vault বেছে নেওয়া প্রায় স্পষ্ট ছিল।
প্রথমত, এগুলো সাধারণ Markdown ফাইল। কোনো জাদু নেই, কোনো ক্লোজড ডাটাবেস নেই, কোনো নির্দিষ্ট সার্ভিসের উপর নির্ভরতা নেই। এজেন্ট কিছু লিখলে, আমি ফাইল খুলে ফলাফল দেখতে পারি।
দ্বিতীয়ত, Obsidian ইতিমধ্যেই Second Brain-এর মানবিক অংশ ভালোভাবে সমাধান করে: নোট, উইকিলিঙ্ক, ডেইলি, ম্যানুয়াল নেভিগেশন, গ্রাফ, সার্চ। নিজের নলেজ ইন্টারফেস তৈরি করার কোনো মানে হয়নি যখন একটি পরিচিত টুল আছে।
তৃতীয়ত, এজেন্টদের সম্পূর্ণ Obsidian দরকার নেই। তাদের ডিটারমিনিস্টিক অপারেশন দরকার: সার্ভিস স্ট্রাকচার তৈরি করা, ডেইলি লগে ইভেন্ট যোগ করা, পেজ ইনডেক্স তৈরি করা, vault-এর স্বাস্থ্য পরীক্ষা করা, সিক্রেট ছাড়া কনফিগ এক্সপোর্ট করা। এসব CLI এবং MCP এর মাধ্যমে করা যায়, মডেলকে ফাইল অপারেশন নিয়ে “চিন্তা” করতে বাধ্য না করে যেখানে একটি সুনির্দিষ্ট কমান্ড চালানো ভালো।
এখন open-second-brain vault-এ AI Wiki/ এজেন্ট এরিয়া তৈরি করে, Daily/*.md-এ দৈনিক লগ রাখে, Markdown ইনডেক্স আপডেট করতে পারে, কনফিগারেশন পরীক্ষা করতে পারে এবং ## Raw events সার্ভিস বিভাগের উপরে মানুষের নোট স্পর্শ করে না।
আমি একটি খালি রিপোজিটরি দিলাম — এজেন্ট আর্কিটেকচার বেছে নিল
সবচেয়ে আকর্ষণীয় বিষয়: আমি সবকিছু ক্লাসিক লাইব্রেরি API হিসেবে ডিজাইন করতে বসিনি। আমি এজেন্টকে জনপ্রিয় বাস্তবায়নের লিঙ্ক, একটি খালি রিপোজিটরি এবং একটি কাজ দিয়েছি: একটি সার্বজনীন প্লাগইন তৈরি করো, প্রথমে Hermes-এর জন্য, কিন্তু এমনভাবে যে অন্য এজেন্টরাও এটি গ্রহণ করতে পারে।
প্রথম কমিট ছিল সম্পূর্ণ ডকুমেন্টেশন: README এবং প্রজেক্ট bootstrap ৬ মে। তারপর এজেন্ট দ্রুত CLI ফাউন্ডেশন, o2b কমান্ড, init/doctor, vault primitives এবং ইনডেক্স তৈরি করে। একই দিনে MCP সার্ভার তৈরি হলো — একটি গুরুত্বপূর্ণ স্তর, কারণ MCP এর মাধ্যমে বিভিন্ন রানটাইম একই টুল পেতে পারে ম্যানুয়াল কমান্ড লাইন পার্সিং ছাড়াই।
প্রথম ভার্সনগুলো খুবই প্রায়োগিক ছিল: নিশ্চিত করা যে Hermes প্লাগইন ইনস্টল করতে পারে, vault সেট আপ করতে পারে, অবস্থা পরীক্ষা করতে পারে এবং ইভেন্ট লিখতে পারে। কাগজে নিখুঁত আর্কিটেকচার নয়, বরং একটি কাজ করা ন্যূনতম মেমোরি একটি প্রকৃত এজেন্টের জন্য।
এরপর ইন্টিগ্রেশনের চাপে প্রজেক্ট পরিবর্তিত হতে শুরু করে।
Hermes থেকে সার্বজনীন প্লাগইন পর্যন্ত
Hermes প্রধান রানটাইম হিসেবে রয়ে গেছে। এটি তার জন্যই প্রজেক্টটি পরিকল্পনা করা হয়েছিল: প্লাগইন ইনস্টল করা, vault নির্দেশ করা, এজেন্টকে টুল দেওয়া এবং গুরুত্বপূর্ণ ইভেন্ট Second Brain-এ লেখানো।
কিন্তু বেশ দ্রুত বুঝতে পারা গেল শুধু Hermes-এর সাথে বাঁধা পড়া ঠিক নয়। আমার কাছে ইতিমধ্যে বিভিন্ন এজেন্ট এবং বিভিন্ন পরিবেশ আছে: Claude Code, Codex, OpenClaw। যদি Second Brain একটি সাধারণ মেমোরি হয়, তবে তা শুধু একটি ক্লায়েন্টে থাকতে পারে না।
এভাবে প্রজেক্টে বেশ কয়েকটি রানটাইমের জন্য অ্যাডাপ্টার এবং ম্যানিফেস্ট যুক্ত হলো:
- Hermes প্রধান ইনস্টলেশন পরিস্থিতি হিসেবে;
- Claude Code marketplace manifest এবং MCP এর মাধ্যমে;
- Codex তার নিজস্ব marketplace manifest এবং MCP এর মাধ্যমে;
- OpenClaw প্রথমে JS অ্যাডাপ্টারের মাধ্যমে, তারপর সম্পূর্ণ native plugin entry এর মাধ্যমে;
- generic MCP কন্ট্রাক্ট ভবিষ্যতে আসা রানটাইমের জন্য।
এটি একটি গুরুত্বপূর্ণ আর্কিটেকচারাল সিদ্ধান্ত: কোর একটিই হতে হবে, কিন্তু এন্ট্রি পয়েন্ট একাধিক হতে পারে। এজেন্টদের নিয়ে ঝগড়া করতে হবে না সত্য কোথায়। সত্য হলো vault-এ এবং অপারেশনের সাধারণ সেটে।
পথে কী ঠিক করতে হয়েছে
open-second-brain খুব দ্রুত বিকশিত হয়েছে: ৬ থেকে ৯ মে পর্যন্ত প্রজেক্ট README থেকে ভার্সন 0.7.0 পর্যন্ত পৌঁছেছে। এবং প্রায় প্রতিটি ভার্সন “কসমেটিক” ছিল না, বরং ইন্টিগ্রেশনের একটি প্রকৃত সমস্যার প্রতিক্রিয়া ছিল।
উদাহরণস্বরূপ, OpenClaw প্রথমে native plugin compatibility পেল, কিন্তু রানটাইম প্রত্যাশার চেয়ে কঠোর প্রমাণিত হলো। name কে tool objects এর ভেতরে যোগ করতে হলো, register() কে সিঙ্ক্রোনাস করতে হলো, এবং তারপর OpenClaw প্লাগইনকে child_process ছাড়া বিশুদ্ধ JavaScript-এ পুনরায় লিখতে হলো, কারণ security scanner subprocess ব্লক করছিল।
পরবর্তী বড় বিষয় হলো identity। যদি ডায়েরিতে শুধু @agent লেখা থাকে, তবে এমন লগ প্রায় অকেজো। তাই 0.6.0-এ এজেন্ট নামের সাথে একটি ওয়ার্কফ্লো এল: o2b init --agent-name, AI Wiki/identity/agents.md-এ নিবন্ধন এবং যাচাই করা যে Daily তে এন্ট্রিগুলো স্বাভাবিক @agent-name পায়, placeholder নয়।
তারপর যোগ হলো timezone, ভুল vault-এ লেখা রোধ, Claude এবং Codex-এর জন্য marketplace ম্যানিফেস্ট, MCP-এর জন্য অটো-ইনস্ট্রাকশন, ফাঁকা আর্গুমেন্ট নরমালাইজেশন, install flow পরীক্ষা, multi-agent registry। এটি বীরত্বপূর্ণ প্রোডাক্ট ফিচারের মতো শোনায় না, কিন্তু ঠিক এই ধরনের বিস্তারিত বিষয়গুলোই একটি খেলনাকে এমন টুল থেকে আলাদা করে যা সার্ভারে কাজ করতে রেখে যাওয়া যায়।
ভার্সন 0.7.0: TypeScript এবং Bun-এ একটি একক কোর
সবচেয়ে বড় পরিবর্তন 0.7.0-এ এল: প্রজেক্ট Bun-এ একক TypeScript core-এ চলে গেল।
এর আগে রিপোজিটরিতে সমান্তরাল লজিক ছিল: CLI/MCP-এর জন্য Python বাস্তবায়ন, OpenClaw-এর জন্য JavaScript অংশ, Hermes shim। এই স্কিম দ্রুত বিচ্যুত হতে শুরু করে। এক জায়গায় বাগ ঠিক করলাম — অন্য জায়গায় ঠিক হয়েছে কিনা নিশ্চিত নই। Python-এ timezone যোগ করলাম — JS-এ পুনরায় করতে ভুলে গেলাম।
0.7.0-এ এজেন্ট ডুপ্লিকেশন সরিয়ে দিল: Hermes, Claude Code, Codex এবং OpenClaw এখন src/core/ থেকে সাধারণ মডিউল ব্যবহার করে। CLI src/cli/-তে, MCP src/mcp/-তে, OpenClaw entry TypeScript থেকে bun build এর মাধ্যমে JS bundle-এ কম্পাইল হয়।
সাথে সাথে একটি স্বাভাবিক টেস্ট বেস তৈরি হলো: ১৭৬টি কেসে bun:test, Python shim টেস্ট, ১২টি প্রসেসে কনকারেন্ট append-event টেস্ট, বান্ডেল ফ্রেশনেস এবং ম্যানিফেস্টে ভার্সন সিঙ্ক পরীক্ষা।
এটি ঠিক সেই মুহূর্ত যেখানে এজেন্ট ওয়ার্কফ্লো-এর সুবিধা দেখা যায়। একজন মানুষের জন্য একই কোড রানটাইমের মধ্যে সরানো এবং টেস্ট পুনরায় লেখা বিরক্তিকর। এজেন্টের জন্য — স্বাভাবিক, যদি স্পষ্ট লক্ষ্য, সীমাবদ্ধতা এবং ফলাফল যাচাই দেওয়া হয়।
এটি VPS-এ কীভাবে চলে
এই পুরো গল্পটি মাসে প্রায় ৮ ডলারের একটি সাধারণ VPS-এ চলে। সেখানেই Hermes আছে, সেখানেই ডেভেলপমেন্ট করা যায়, সেখানেই AI সাবস্ক্রিপশন এবং OmniRoute এর মাধ্যমে রাউটিং পরিচালনা হয়।
আমার জন্য এটি পরীক্ষার একটি গুরুত্বপূর্ণ অংশ। আমি চাই না AI-সহায়ক ওয়ার্কফ্লো-এর জন্য আলাদা দামি ইনফ্রাস্ট্রাকচার প্রয়োজন হয়। একটি সার্ভার, একটি ব্রাউজার, এজেন্টের ইন্টারফেস হিসেবে Telegram, কাছে git রিপোজিটরি এবং মডেলে সস্তা অ্যাক্সেস দরকার।
বেশ অদ্ভুত, কিন্তু কাজ করে এমন একটি চিত্র তৈরি হচ্ছে: আমি ফোন থেকে Telegram-এ এজেন্টকে লিখতে পারি, সে VPS-এ কাজটি বুঝে নেবে, রিপোজিটরিতে যাবে, প্রয়োজনীয় স্কিল ব্যবহার করবে, আর্টিফ্যাক্ট তৈরি করবে, পরীক্ষা চালাবে এবং গুরুত্বপূর্ণ ইভেন্ট Second Brain-এ লিখবে।
এটি এখনও Dark Fabric নয়। কিন্তু এটি আর শুধু “মডেলের সাথে চ্যাট”ও নয়।
কী পাওয়া গেল
এই ড্রাফট লেখার সময় open-second-brain হলো এজেন্ট ডেভেলপমেন্টের জন্য একটি ছোট, কিন্তু ইতিমধ্যে কার্যকর মেমোরি স্তর।
এটি পারে:
- এজেন্ট কাজের জন্য Obsidian-সামঞ্জস্যপূর্ণ vault ইনিশিয়ালাইজ করতে;
AI Wiki/এবং সার্ভিস পেজ তৈরি করতে;- Markdown-এ দৈনিক ইভেন্ট লিখতে;
- এজেন্টদের identity সংরক্ষণ করতে;
- সার্ভারের সময়ের পাশাপাশি ব্যবহারকারীর timezone বিবেচনা করতে;
- vault, কনফিগ এবং রানটাইম ম্যানিফেস্টের স্বাস্থ্য পরীক্ষা করতে;
- সিক্রেট-সদৃশ মান সম্পাদনা সহ কনফিগারেশন এক্সপোর্ট করতে;
- CLI, MCP এবং রানটাইম অ্যাডাপ্টারের মাধ্যমে কাজ করতে;
- একটি রিপোজিটরি থেকে Hermes, Claude Code, Codex এবং OpenClaw সমর্থন করতে।
সবচেয়ে মূল্যবান বিষয় কমান্ডের তালিকা নয়। মূল্যবান হলো যে এজেন্টদের একটি সাধারণ মেমোরি প্রোটোকল হয়েছে: যখন কিছু দীর্ঘস্থায়ী ঘটে — কোড, ফিক্স, কনফিগ, কন্টেন্ট, গবেষণার ফলাফল, ডিজাইন সিদ্ধান্ত — তা এমনভাবে লিখতে হবে যাতে future-me এবং future-agent পরে তা খুঁজে পেতে পারে।
এরপর কী
নিকটতম লক্ষ্য হলো Hermes + open-second-brain কে এমন অবস্থায় নিয়ে যাওয়া যেখানে এজেন্ট শুধু ইভেন্ট লেখে না, বরং পরিকল্পনা এবং রিভিউয়ের সময় সঞ্চিত মেমোরি সত্যিই ব্যবহার করে।
এরপর চাই:
- Daily লগকে wiki পেজের সাথে আরও ভালোভাবে যুক্ত করতে;
- প্রজেক্টের ইতিহাসে আরও কার্যকর সার্চ এবং summaries যোগ করতে;
- একটি আলাদা পোস্টে বর্ণনা করতে কীভাবে Hermes VPS-এ কাজ করে এবং Telegram-এর মাধ্যমে যোগাযোগ কীভাবে সাজানো;
- বর্তমান ওয়ার্কফ্লোকে আরও স্বায়ত্তশাসিত Dark Fabric-এ রূপান্তর করতে;
- পরীক্ষা করতে যে বিভিন্ন এজেন্ট একটি vault বিনা কষ্টে শেয়ার করতে পারে কিনা এবং একে অপরের কন্টেক্সট নষ্ট করে না।
প্রধান উপসংহার আপাতত সহজ: এজেন্টদের শুধু মডেল এবং রিপোজিটরি অ্যাক্সেস দরকার নয়। তাদের এমন একটি পরিবেশ দরকার যেখানে সিদ্ধান্ত, তথ্য এবং ইভেন্ট প্রক্রিয়ার দীর্ঘস্থায়ী অংশে পরিণত হয়।
open-second-brain — এই দিকে আমার প্রথম কার্যকর পদক্ষেপ।
এই পোস্টটি কীভাবে লেখা হয়েছে
দুঃখিত, কিন্তু এই পোস্টটিও একই এজেন্ট Hermes দ্বারা লেখা হয়েছে। হাতে লেখা হয়েছে শুধু এই অনুচ্ছেদটি এবং আমার Facebook পোস্ট। আমি শুধু এজেন্টকে বলেছি আমার ব্লগ একটি সাধারণ প্রজেক্ট হিসেবে ক্লোন করতে, কমিট হিস্টরি দেখতে এবং Facebook পোস্টকে ভিত্তি হিসেবে নিতে। এবং অবশ্যই আমি প্রকাশের আগে পুনরায় পড়েছি এবং সংশোধন করেছি। এবং বলবেন না যে এতে আত্মা নেই, আমি এজেন্টে আত্মা ঢালছি।