নিজের VPS-এ n8n AI agent তৈরি করুন

n8n AI agent কী এবং এটি chain থেকে কীভাবে আলাদা

একটি n8n AI agent হলো একটি একক AI Agent node, যার সঙ্গে sub-node যুক্ত থাকে: একটি chat model, এক বা একাধিক tool এবং ঐচ্ছিক memory। আপনি সাধারণ ভাষায় একটি লক্ষ্য নির্ধারণ করেন। এরপর উত্তর দিতে পারা পর্যন্ত model কোন tool কখন এবং কোন ক্রমে call করবে তা নিজেই নির্ধারণ করে। নিচের সবকিছু এই একটি ধারণাকে ঘিরে configuration।

Chain-এর কাজ এর বিপরীত। একটি Basic LLM Chain-এ আপনি ধাপগুলো নির্ধারণ করেন এবং model শুধু text তৈরি করে। Agent-এ model ধাপগুলো নির্ধারণ করে। তাই একই প্রশ্নে আজ একটি model call লাগতে পারে, আবার আগামীকাল নয়টি call-ও লাগতে পারে। এই একটিমাত্র পার্থক্যই এই guide-এর প্রতিটি setting-এর ভিত্তি।

এখানে ধরে নেওয়া হয়েছে যে আপনার নিয়ন্ত্রণাধীন একটি machine-এ n8n ইতিমধ্যে HTTPS-এর পেছনে চলছে। তা না হলে বাস্তব certificate ব্যবহার করে Docker-এ n8n self-hosting দিয়ে শুরু করুন, কারণ আপনি যে API key সংরক্ষণ করতে যাচ্ছেন তার জন্য ওই guide-এ জোর দেওয়া encryption-key backup প্রয়োজন। Agent নয় এমন pattern, webhook summarizer এবং scheduled classifier-এর জন্য দেখুন Claude এবং n8n workflow pattern।

এখানে দেওয়া যেকোনো field name ব্যবহারের আগে আপনার version পরীক্ষা করুন, কারণ n8n প্রায়ই AI node পরিবর্তন করে।

docker compose exec n8n n8n --version

এই guide-এর নামগুলো July 2026 অনুযায়ী n8n-এর বর্তমান stable version-এর সঙ্গে মেলে। version 1.82.0 থেকে প্রতিটি AI Agent node Tools Agent হিসেবে চলে। তাই পুরোনো agent-type dropdown আর নেই।

ধাপ 1: trigger নির্বাচন করুন

Conversational agent-এর জন্য একটি Chat Trigger node যোগ করুন। তৈরি করার সময় Make Chat Publicly Available বন্ধ রাখুন, যাতে শুধু editor-এর chat panel এটি ব্যবহার করতে পারে। Agent সম্পূর্ণ হলে এবং authentication পদ্ধতি নির্ধারণ করলে এটি চালু করুন।

Chat Trigger agent-কে chatInput নামের একটি field দেয়। ধাপ 3-এ এই নামটি গুরুত্বপূর্ণ। প্রথমবার ব্যর্থ হওয়ার সবচেয়ে সাধারণ কারণ হলো নামটি ভুল লেখা।

Unattended agent-এর জন্য এর পরিবর্তে Schedule Trigger অথবা Webhook node ব্যবহার করুন। এগুলোর কোনোটিই chatInput তৈরি করে না। তাই prompt নিজেকেই লিখতে হবে।

ধাপ 2: মডেলের credential

Canvas-এ একটি AI Agent node রাখুন। n8n সঙ্গে সঙ্গে এর নিচে একটি খালি Chat Model connector দেখাবে। সেখানে একটি Anthropic Chat Model sub-node সংযুক্ত করুন।

platform.claude.com-এর Anthropic Console-এ Settings এবং এরপর API Keys-এ গিয়ে credential তৈরি করুন। key একবারই দেখানো হয়। API usage প্রতি token অনুযায়ী বিল করা হয় এবং এটি যেকোনো Claude.ai subscription থেকে আলাদা। তাই প্রথমবার run করার আগে account-এ billing সেট আপ করতে হবে।

মডেল নির্বাচন করুন agent অনুযায়ী, company অনুযায়ী নয়। একটি tool ব্যবহার করে কোনো তথ্য খুঁজে report করা one-tool agent Haiku-তে ভালোভাবে চলে। July 2026 অনুযায়ী Haiku-এর মূল্য প্রতি million input token-এ $1 এবং প্রতি million output token-এ $5। Agent-এর একাধিক tool থাকলে এবং সেগুলোর মধ্যে পরিকল্পনা করে কাজ করতে হলে Sonnet ব্যবহার করুন। আপনি যে সমস্যা এড়াতে চান তা হলো এমন একটি সস্তা model, যা চারবার ভুল tool call করে। এতে একবার সঠিক tool call করা ব্যয়বহুল model-এর চেয়েও বেশি খরচ হতে পারে।

Sub-node-এর options-এ Maximum Number of Tokens নির্ধারণ করুন। এটি model-এর প্রতিটি response-এর সর্বোচ্চ দৈর্ঘ্য নির্ধারণ করে। বড় default মান রেখে দিলে একটি বিভ্রান্ত run অত্যন্ত দীর্ঘ answer তৈরি করতে পারে এবং এর জন্য আপনাকে billing করা হবে।

n8n docs-এ উল্লেখিত একটি গুরুত্বপূর্ণ বিষয় সবাইকে সমস্যায় ফেলে: sub-node-এর expression সবসময় প্রথম input item-এর ভিত্তিতে resolve হয়, প্রতিটি item-এর ভিত্তিতে নয়। Per-item expression root node-এর prompt field-এ রাখুন।

ধাপ 3: agent যে prompt পায়

AI Agent node খুলুন। Prompt parameter-এর 2টি setting আছে।

• Take from previous node automatically incoming chatInput নামের field প্রত্যাশা করে। Chat Trigger-এর পরে এটি সঠিক পছন্দ।
• Define below একটি Prompt (User Message) field দেখায়, যেখানে static text বা expression লিখতে পারেন। Schedule Trigger বা Webhook node-এর পরে এটি সঠিক পছন্দ।

সামনে Webhook node থাকলে POST body $json.body-এর অধীনে আসে। তাই prompt field দেখতে এমন হয়।

Check the current status of {{ $json.body.service }} and tell me
whether it is up. If it is down, say for how long. No preamble.

ধাপ 4: agent-কে একটি tool দিন

কোনো tool sub-node ছাড়া AI Agent node চলতে অস্বীকার করে। প্রথমে একটি tool দিয়ে শুরু করুন, কারণ অর্ধেক কনফিগার করা চারটির চেয়ে কাজ করা একটি tool আপনাকে বেশি তথ্য দেয়।

agent-এর Tool connector-এর সঙ্গে একটি HTTP Request node সংযুক্ত করুন। সাধারণ HTTP Request node-এর মতোই এটি কনফিগার করুন, তারপর আগে shell থেকে ওই endpoint পরীক্ষা করুন।

curl -s -H 'Accept: application/json' \
  https://status.example.com/api/status/database | head -c 400

যদি ওই curl error বা HTML login page ফেরত দেয়, agent-ও ব্যর্থ হবে। তখন সমস্যাটি আসলে URL বা authentication-সংক্রান্ত হলেও failure-টি model-এর সমস্যা বলে মনে হতে পারে। node-এ নয়, shell-এ সমস্যাটি ঠিক করুন।

tool-এর Description field আপনার সহকর্মীদের জন্য documentation নয়। এই tool প্রাসঙ্গিক কি না নির্ধারণ করার সময় model শুধু এটিই পড়ে। কী ফেরত আসে, তা সরাসরি লিখুন: "একটি monitored service-এর বর্তমান up বা down অবস্থা এবং downtime-এর সময়কাল JSON হিসেবে ফেরত দেয়।"

অনুরোধের একটি অংশ model-কে পূরণ করতে দিতে $fromAI() expression ব্যবহার করুন। এটি শুধু AI Agent node-এর সঙ্গে সংযুক্ত tool-এ কাজ করে। Code tool-এ এটি কাজ করে না।

{{ $fromAI('service', 'The name of the service to look up', 'string') }}

argument-গুলো হলো key, এরপর ঐচ্ছিক description, type এবং defaultValue। key-এর দৈর্ঘ্য 1 থেকে 64 characters হতে হবে। এতে letters, digits, underscores এবং hyphens ব্যবহার করা যাবে। type হবে string, number, boolean অথবা json-এর একটি। এর default মান string। আরও পূর্ণ একটি call এভাবে দেখায়।

{{ $fromAI('limit', 'How many records to return', 'number', 20) }}

key হলো একটি hint, existing data-এর reference নয়। $fromAI('service') কোথাও থেকে service নামে কোনো field পড়ে না। এটি model-কে বলে, "একটি value তৈরি করে সেটির নাম service দিন"। এরপর model conversation, input data এবং অন্য tool-এর result দেখে value খুঁজে নেয়। chat workflow-এ এটি সরাসরি user-কে জিজ্ঞাসা করতে পারে।

Web search সাধারণত দ্বিতীয় tool হিসেবে ব্যবহার করা হয়। এটি আরেকটি HTTP endpoint হওয়ায়, paid search API-এর বদলে একই node-কে আপনার নিজস্ব SearXNG instance-এ নির্দেশ করতে পারেন। তবে node-টি যে প্রতিটি page ফেরত আনে, তা untrusted text হিসেবে বিবেচনা করুন, কারণ সেটি তখন আপনার prompt-এর অংশ হয়ে যায়।

ধাপ 5: memory এবং agent কেন ভুলে যায়

একটি memory sub-node না থাকলে প্রতিটি message শূন্য থেকে শুরু হয়। সাম্প্রতিক conversation ধরে রাখতে একটি Simple Memory sub-node সংযুক্ত করুন।

এতে 2টি parameter থাকে। Session Key নির্ধারণ করে এটি কোন conversation, তাই ভিন্ন key ব্যবহারকারী 2 জনের history আলাদা থাকে। Context Window Length নির্ধারণ করে prompt-এ আগের কতগুলো interaction আবার যুক্ত করা হবে।

Context Window Length শুধু quality নয়, cost-ও নিয়ন্ত্রণ করে। কারণ পরবর্তী প্রতিটি call-এ মনে রাখা প্রতিটি turn input token হিসেবে আবার পাঠানো হয়। chatty agent-এর ক্ষেত্রে window 20 হলে একই শুরুর message-এর জন্য আপনি 20 বার অর্থ প্রদান করেন।

n8n queue mode-এ চললে active production workflow-এ Simple Memory কাজ করে না। কারণ history shared store-এ নয়, workflow-এর নিজস্ব data-তে থাকে। queue-mode instance-এ এর পরিবর্তে Postgres Chat Memory sub-node ব্যবহার করুন এবং এমন একটি database নির্ধারণ করুন, যেটিতে main process ও workers উভয়ই পৌঁছাতে পারে।

ধাপ 6: System Message

agent-এর Options খুলে একটি System Message যোগ করুন। এখানে কাজের বিবরণ লিখতে হবে। Workflow-এ প্রভাবের দিক থেকে এটি সবচেয়ে গুরুত্বপূর্ণ text।

You are an infrastructure status assistant. Always call the status
tool before answering a question about whether something is running.
Never guess. If the tool returns an error, say so and stop.

“উত্তর দেওয়ার আগে সবসময় status tool call করুন”—এই নির্দেশটি বাস্তবে গুরুত্বপূর্ণ কাজ করে। এটি না থাকলে, model যদি মনে করে যে উত্তরটি তার আগে থেকেই জানা, তাহলে tool ব্যবহার না করে memory থেকে উত্তর দেবে। Infrastructure পরিবর্তিত হলেই এই উত্তর আত্মবিশ্বাসের সঙ্গে ভুল হয়ে যাবে।

এজেন্ট কেন লুপ করে এবং কীভাবে এটি থামানো যায়

Options-এর মধ্যে Max Iterations-ও আছে, যার ডিফল্ট মান 10। একটি iteration বলতে একটি model call এবং context-এ ফেরত পাঠানো একটি tool result বোঝায়। তাই একটি agent run কেবল একটি API call নয়; এটি সর্বোচ্চ 10টি API call পর্যন্ত হতে পারে, এবং প্রতিটি call-এর input হিসেবে ক্রমশ বড় হওয়া পুরো conversation পাঠানো হয়।

এই মান কমিয়ে দিন। বেশিরভাগ single-tool agent দুইটি iteration-এর মধ্যেই শেষ হয়। 3 বা 4 turns-এর limit নিয়ন্ত্রণহীন loop-কে execution list-এ দৃশ্যমান একটি পরিষ্কার ব্যর্থতায় পরিণত করে।

Debugging-এর সময় Return Intermediate Steps চালু করুন। তখন final output-এ agent পথে যে tool call-গুলো করেছে, সেগুলিও অন্তর্ভুক্ত থাকে। এর মাধ্যমে বোঝা যায়, "model কখনো tool call করেনি" নাকি "tool কোনো কার্যকর ফল ফেরত দেয়নি"। Live ব্যবহারের আগে এটি আবার বন্ধ করুন, কারণ end user-এর জন্য এই ধাপগুলো অপ্রয়োজনীয় তথ্য।

Shell থেকে একটি run চলতে দেখুন।

docker compose logs -f n8n

একটি unattended agent-কে নীরবে অতিরিক্ত খরচ করা থেকে আটকানো

Chat Trigger-এর পেছনে থাকা agent-এর সঙ্গে একজন মানুষ যুক্ত থাকে, এবং উত্তরটি ভুল মনে হলে সেই মানুষ agent-টিকে থামিয়ে দেন। Schedule Trigger-এর পেছনে থাকা agent-কে কেউ পর্যবেক্ষণ করে না। এখানে আপনি licence খরচের বদলে model ব্যবহারের খরচ পর্যবেক্ষণ করছেন, কারণ agent, tool এবং memory node—সবই বিনামূল্যের self-hosted edition-এ কাজ করে, এবং যে বৈশিষ্ট্যগুলোর জন্য paid key প্রয়োজন হয়, সেগুলো মূলত team ও governance-সংক্রান্ত। এর বিস্তারিত আলোচনা আছে always-on VPS-এ AI agent-এর খরচ নিয়ন্ত্রণ-এ। এখানে চারটি setting-ই বেশিরভাগ কাজ করে।

• model sub-node-এ Maximum Number of Tokens-এর সীমা নির্ধারণ করুন, যাতে কোনো একক response দীর্ঘ সময় চলতে না পারে।
• কাজটি সম্পন্ন করার জন্য যথেষ্ট সর্বনিম্ন সংখ্যায় Max Iterations সেট করুন।
• tool response ছোট রাখুন। কোনো tool 4,000 লাইনের JSON blob ফেরত দিলে একই run-এর পরবর্তী model call-এ তার সম্পূর্ণ অংশ যুক্ত হয়, এবং এরপরের প্রতিটি call-এও তা থাকে।
• agent-এর আদৌ schedule প্রয়োজন কি না, তা বিবেচনা করুন। প্রতি পাঁচ মিনিটে চলা একটি job দিনে 288 বার চালু হয়। একটি run-এর খরচ যত, সেই সংখ্যাকে 288 দিয়ে গুণ করতে হবে।

পরিবর্তন পরীক্ষা করার সময় workflow deactivate রাখুন। সক্রিয় workflow Schedule Trigger-সহ n8n-এ সংরক্ষিত version-এর ওপর চলতে থাকে। সেটি আপনার screen-এ থাকা version-এর সঙ্গে সবসময় এক নয়।

FAQ

আমার AI Agent node কেন execute করতে অস্বীকার করে?

AI Agent node-এর জন্য একটি chat model sub-node এবং অন্তত একটি tool sub-node প্রয়োজন। model আছে কিন্তু tool নেই—এমন node কোনো API call করার আগেই ব্যর্থ হয়। একটি tool সংযুক্ত করুন, সেটি খুব সাধারণ হলেও চলবে, এবং আবার চালান।

agent উত্তর দেয়, কিন্তু আমার tool কখনো call করে না। সমস্যা কী?

প্রায় সব ক্ষেত্রেই সমস্যা tool-এর Description field-এ থাকে। model এই description পড়ে tool নির্বাচন করে। তাই "HTTP Request"-এর মতো description toolটি কখন প্রযোজ্য, সে সম্পর্কে কিছু জানায় না। কোন data ফেরত আসে এবং কোন পরিস্থিতিতে toolটি কার্যকর, তা স্পষ্ট করে descriptionটি লিখুন। এরপর System Message-এ agent-কে উত্তর দেওয়ার আগে ওই tool call করতে নির্দেশ দিয়ে একটি line যোগ করুন।

একই প্রশ্নে প্রতিবার ভিন্ন খরচ কেন হয়?

কারণ model কতগুলি step নেবে, তা নিজেই নির্বাচন করে। প্রতিটি iteration-এ তখন পর্যন্ত সম্পূর্ণ conversation আবার পাঠানো হয়, যার মধ্যে আগের tool output-ও থাকে। তাই চারটি iteration লাগা একটি run-এর খরচ single call-এর চার গুণের চেয়ে অনেক বেশি হতে পারে। Max Iterations এই সংখ্যার সর্বোচ্চ সীমা নির্ধারণ করে। Return Intermediate Steps দেখায়, কোনো নির্দিষ্ট run বাস্তবে কতগুলি step ব্যবহার করেছে।

editor-এ আমার memory কাজ করে, কিন্তু production-এ কাজ করে না। কী পরিবর্তন হয়েছে?

instance queue mode-এ চলছে কি না পরীক্ষা করুন। Simple Memory workflow-এর নিজস্ব execution data-তে history সংরক্ষণ করে। আলাদা worker process-এ workflow হস্তান্তর করা হলে এই data টিকে থাকে না। ফলে active production workflow তার history হারায়। এর পরিবর্তে Postgres Chat Memory sub-node ব্যবহার করুন। এটি এমন database-এ history সংরক্ষণ করে, যা প্রতিটি worker শেয়ার করে।