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

n8n AI agent কী এবং এটি chain থেকে কোথায় ভিন্ন

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

Chain-এর পদ্ধতি বিপরীত। একটি Basic LLM Chain-এ আপনি ধাপগুলো নির্ধারণ করেন, আর model শুধু text তৈরি করে। Agent-এ model ধাপগুলো নির্ধারণ করে। তাই একই প্রশ্নে আজ একটি model call লাগতে পারে, আবার আগামীকাল নয়টি। এই একটি পার্থক্যই এই guide-এর প্রতিটি setting নির্ধারণ করে। n8n feature হিসেবে নয়, ধারণা হিসেবে এই loop আপনার কাছে নতুন হলে node দিয়ে এটি তৈরি করার আগে একবার হাতে লিখে তৈরি করে দেখুন। কারণ node সেই নির্দিষ্ট অংশটি আড়াল করে, যেটি নিয়ে এই guide-এর বাকি অংশে আপনাকে যুক্তি দিয়ে সিদ্ধান্ত নিতে হবে।

এখানে ধরে নেওয়া হয়েছে, আপনার নিয়ন্ত্রণাধীন একটি 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

Version 1.82.0 agent-type setting-টি বাদ দিয়ে Tools Agent ব্যবহার করা শুরু করেছে। Legacy v1 node-গুলোতে এখনও এই setting আছে। n8n-এর documentation অনুযায়ী, এই node version অপসারণের জন্য n8n 3.0 নির্ধারিত হয়েছে।

ধাপ 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-এর Claude Console থেকে credential তৈরি করুন। এজন্য Settings, তারপর API keys-এ যান। Key-টি একবারই দেখানো হয়। Key তৈরি করার সময় Console আপনাকে একটি expiration বেছে নিতে বলে। Unattended agent তার key-এর মেয়াদ শেষ হওয়ার দিন কাজ বন্ধ করে দেয়। তাই তারিখটি এমন কোথাও লিখে রাখুন, যেখানে আপনি তা দেখতে পাবেন। Unattended agent-এর জন্য workspace-এ scoped একটি service account key ব্যবহার করুন। এতে request-এর সঙ্গে আলাদা workspace header পাঠাতে হয় না।

31 October 2026 অনুযায়ী API usage প্রতি token হিসেবে বিল করা হয়। এর মূল্য পরিশোধের পদ্ধতি আপনার Claude plan-এর ওপর নির্ভর করে। Max, Ultra এবং Team plan-এ মাসিক API credit অন্তর্ভুক্ত থাকে: Max-এ $100, Ultra-তে $200 এবং Team-এ pooled হিসেবে সর্বোচ্চ $500। Max বা Ultra-তে Settings > Billing থেকে, অথবা Team-এ Organization settings > Billing থেকে একটি Console organization-কে plan-এর সঙ্গে link করে credit claim করতে হয়। Console-এ payment method যোগ করার প্রয়োজন নেই। নতুন subscriber-রা plan-এ 7 দিন থাকার পর credit claim করতে পারেন। অব্যবহৃত credit প্রতিটি billing cycle-এর শেষে মেয়াদোত্তীর্ণ হয়। Annual plan-এ এটি প্রতি মাসে মেয়াদোত্তীর্ণ হয়। অন্তর্ভুক্ত credit শেষ হয়ে গেলে request purchased credit-এর বিপরীতে চলতে থাকে। Auto-reload আরও credit কিনতে পারে। Invoiced organization-কে অতিরিক্ত usage-এর জন্য bill করা হয়। Prepaid organization-এ কোনো credit অবশিষ্ট না থাকলে request বন্ধ হয়ে যায়। API usage কখনো আপনার Claude plan-এ charge করা হয় না। Free, Pro এবং Enterprise plan-এ কোনো মাসিক API credit নেই। তাই এসব plan-এ API usage subscription থেকে আলাদাভাবে billed হয়।

প্রতিটি agent-এর জন্য model বেছে নিন, company-র জন্য নয়। কোনো একটি জিনিস খুঁজে তা report করে এমন one-tool agent Haiku-তেই ভালোভাবে চলে। 12 October 2026 অনুযায়ী বর্তমান version Haiku 5.5-এর মূল্য প্রতি million input token-এ $0.10 এবং প্রতি million output token-এ $0.50। কোনো request-এর prompt 100,000 token অতিক্রম করলে এই মূল্য যথাক্রমে $0.50 এবং $2.50 হয়। দীর্ঘ memory window এবং বড় tool result-এর কারণে prompt এই সীমা অতিক্রম করতে পারে। Agent-এর একাধিক tool থাকলে এবং সেগুলোর মধ্যে পরিকল্পনা করতে হলে Sonnet ব্যবহার করুন। আপনি যে সমস্যা এড়াতে চাইছেন তা হলো, সস্তা model ভুল tool চারবার call করে। এতে সঠিক tool একবার call করা ব্যয়বহুল model ব্যবহারের চেয়েও বেশি খরচ হতে পারে।

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

n8n docs-এর একটি গুরুত্বপূর্ণ সতর্কতা আছে, যা অনেকের সমস্যা তৈরি করে: sub-node-এর expression সবসময় প্রথম input item-এর বিরুদ্ধে resolve হয়, প্রতিটি item-এর জন্য আলাদাভাবে নয়। Per-item expression root node-এর prompt field-এ রাখুন।

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

AI Agent node খুলুন। Source for Prompt (User Message) parameter-এ দুটি setting আছে।

• Connected Chat Trigger Node incoming field হিসেবে 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: এজেন্টকে একটি tool দিন

n8n-এর documentation অনুযায়ী, একটি AI Agent node-এর সঙ্গে অন্তত একটি tool sub-node সংযুক্ত করতে হবে। তবে বর্তমান node code (version 3.1) chat model ছাড়া চলতে অস্বীকার করে। যেভাবেই হোক, শুরুতে একটি tool ব্যবহার করুন। চারটি tool অর্ধেক configure করার চেয়ে একটি কার্যকর tool আপনাকে বেশি তথ্য দেবে। কোনো tool ছাড়া agent মূলত এমন একটি chain, যার খরচ বেশি।

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

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

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

tool-এর Description field আপনার সহকর্মীদের জন্য documentation নয়। tool-টি প্রাসঙ্গিক কি না নির্ধারণ করার সময় model tool-এর নাম ও parameter schema-এর পাশাপাশি এই description পড়ে। কী ফলাফল ফেরত আসে, তা সরাসরি লিখুন: "একটি 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') }}

arguments হলো 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-এর দিকে নির্দেশ করতে পারেন। তবে এটি যে প্রতিটি page ফেরত আনে, সেটিকে untrusted text হিসেবে বিবেচনা করুন, কারণ এখন সেটি আপনার prompt-এর অংশ।

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

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

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

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

n8n queue mode-এ চললে active production workflow-এ Simple Memory কাজ করে না। কারণ এটি workflow এবং session ID দিয়ে চিহ্নিত একটি process-local singleton Map-এ history সংরক্ষণ করে, আর worker-গুলো সেই memory ভাগ করে না। queue-mode instance-এ এর বদলে Postgres Chat Memory sub-node ব্যবহার করুন এবং এমন একটি database নির্ধারণ করুন, যেটিতে main process ও worker—উভয়ই পৌঁছাতে পারে।

ধাপ 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। এই call হয় tools-এর জন্য অনুরোধ করে, নয়তো final answer ফেরত দেয়; tool-এর ফলাফল পরবর্তী call-এ পাঠানো হয়। তাই একটি agent run শুধু একটি API call নয়। এটি সর্বোচ্চ 10টি call নিয়ে গঠিত, এবং প্রতিটি call-এর input হিসেবে ক্রমশ বড় হওয়া সম্পূর্ণ conversation পাঠানো হয়।

এর মান কমান। বেশিরভাগ single-tool agent দুইটি iteration-এর মধ্যে কাজ শেষ করে। 3 বা 4 turn-এর সীমা runaway loop-কে execution list-এ দৃশ্যমান একটি পরিষ্কার failure-এ পরিণত করে।

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

Shell থেকে একটি run চলার সময় তা পর্যবেক্ষণ করুন।

docker compose logs -f n8n

স্বয়ংক্রিয় agent-কে নীরবে অতিরিক্ত খরচ করা থেকে আটকানো

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

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

আপনি কাজ করার সময় workflow unpublish করে রাখুন, অথবা অন্তত কোন version live আছে তা মনে রাখুন। Schedule Trigger-সহ একটি published workflow আপনি screen-এ যে draft দেখছেন সেটি নয়, সর্বশেষ publish করা version চালাতে থাকে। কারণ আপনি আবার publish না করা পর্যন্ত n8n আপনার পরিবর্তনগুলো draft হিসেবে সংরক্ষণ করে।

FAQ

আমার AI Agent node কেন execute হচ্ছে না?

প্রথমে connector-গুলো পরীক্ষা করুন। AI Agent node-এর একটি chat model sub-node প্রয়োজন। এটি না থাকলে কোনো API call করার আগেই node-টি "Please connect a model to the Chat Model input" বার্তা দিয়ে থেমে যায়। n8n-এর documentation-এ অন্তত একটি tool sub-node-ও প্রয়োজনীয় হিসেবে উল্লেখ আছে। তাই model সংযুক্ত থাকার পরও node কাজ না করলে একটি tool সংযুক্ত করুন, সেটি খুব সাধারণ tool হলেও চলবে, এবং আবার চালান।

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

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

একই প্রশ্নে প্রতিবার খরচের পরিমাণ আলাদা হয় কেন?

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

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

Instance-টি queue mode-এ চলছে কি না পরীক্ষা করুন। Simple Memory workflow ও session ID অনুযায়ী process-local singleton Map-এ history সংরক্ষণ করে। আলাদা worker process এই history share করে না। এর পরিবর্তে Postgres Chat Memory sub-node ব্যবহার করুন। এটি এমন database-এ history সংরক্ষণ করে, যা প্রতিটি worker share করে।