লুপ ইঞ্জিনিয়ারিং কী? সহজ সংজ্ঞা

লুপ ইঞ্জিনিয়ারিং বলতে কী বোঝায়

লুপ ইঞ্জিনিয়ারিং হলো AI agent যে পুনরাবৃত্ত চক্রে চলে, সেটি নকশা করার পদ্ধতি। এতে নির্ধারণ করা হয় কী কারণে agent সক্রিয় হবে, এটি কোন সংস্থান ব্যবহার করতে পারবে, এর আউটপুট কীভাবে যাচাই করা হবে এবং কোন পরিস্থিতিতে এটি থামবে। Prompt engineering একটি model-এর জন্য একটি বার্তা তৈরি করে। Loop engineering এমন একটি প্রক্রিয়া তৈরি করে, যা আপনি ঘুমিয়ে থাকলেও হাজার হাজার বার্তা পাঠায়। কাজের একক prompt থেকে loop-এ স্থানান্তরিত হয়।

সংক্ষেপে: আপনি আর শুধু নির্দেশনা লিখবেন না; আপনি একটি control system লিখবেন। Agent-এর এখনও ভালো নির্দেশনা দরকার। তবে নির্দেশনা এখন এমন একটি চক্রের একটি উপাদান, যা নির্দিষ্ট সময়সূচিতে চলে, আপনার code-এর একটি বিচ্ছিন্ন কপিতে কাজ করে, test-এর মাধ্যমে নিজের ফলাফল প্রমাণ করে এবং budget শেষ হলে কাজ ছেড়ে দেয়।

2026-এ শব্দটির প্রচলন কেন হলো

নামটি এখন প্রকাশ্য ব্যবহারে স্থির হচ্ছে। প্রথম প্রকাশের দুই মাসের মধ্যে GitHub repository cobusgreyling/loop-engineering 9,600-এর বেশি star পেয়েছে (July 2026 অনুযায়ী)। এর মূলবাক্য হলো "Stop prompting. Design the loop. Get a score." এটি এই পরিবর্তনকে ছয়টি building block-এ সংক্ষেপ করে: scheduling, worktrees, skills, plugins and connectors, sub-agents এবং conversation-এর বাইরে সংরক্ষিত durable memory।

এতে Anthropic-এ Claude Code-এর নেতৃত্বদানকারী Boris Cherny-এর বক্তব্য উদ্ধৃত করা হয়েছে:

I don't prompt Claude anymore. I have loops running that prompt Claude.

আরেকটি repository, AI-Builder-Club/skills, প্রায় 1,100 star পেয়েছে (July 2026 অনুযায়ী)। এতে দুটি ভূমিকার নাম সরাসরি দেওয়া হয়েছে: একটি "codebase harness", যা কোনো repository-কে agent-এর জন্য নিরাপদ করে যাতে সেটি tests চালাতে এবং deploy করতে পারে; এবং একজন "loop engineer", যিনি এমন workflow তৈরি করেন যা কোনো trigger-এ সক্রিয় হয়, কাজ সম্পন্ন করে এবং শেখা বিষয়গুলো একটি shared file-এ লেখে, যাতে পরের loop সেগুলো পড়তে পারে।

কোনো repository-ই এই পদ্ধতি উদ্ভাবন করেনি। যারা nightly build, continuous integration-এ linter, অথবা ticket খোলে এমন cron job চালিয়েছেন, তারা ইতিমধ্যেই এর কাঠামো জানেন। নতুন বিষয় হলো, loop-এর ভেতরের worker এখন non-deterministic। ফলে চারপাশের machinery-কে কী করতে হবে, তা বদলে গেছে।

একটি loop-এর চারটি অংশ

প্রতিটি কার্যকর loop-এ এই চারটি অংশ থাকে। কোনো loop একটি অংশ বাদ দিলে সেটিই এমন loop হয়, যা আপনাকে ভোর 3টায় জাগিয়ে দেয়।

• Trigger। যে event একটি run শুরু করে: timer, webhook, নতুন pull request অথবা alert।
• Boundary। সেই run চলাকালে agent যে files, credentials এবং network-এ পৌঁছাতে পারবে।
• Verification। exit code-সহ একটি check, যা নির্ধারণ করে run-এর output রাখা হবে, নাকি বাতিল করা হবে।
• Budget। token, time এবং money-এর সীমা, যা run সফল হোক বা না হোক, সেটি শেষ করে।

এই চারটি বিষয়কে প্রশ্ন হিসেবে আবার পড়ুন। আপনি যে কোনো agent চালু রেখে যাওয়ার আগে এটিই তার design review হিসেবে কাজ করবে।

ট্রিগার: এজেন্টকে কী জাগায়

টাইমার হলো সবচেয়ে সরল ট্রিগার। Linux server-এ এ কাজের জন্য cron-এর চেয়ে systemd timer ভালো, কারণ এটি লগ রাখে, আপনার নির্ধারিত নিয়মে পুনরায় চেষ্টা করে এবং এখনো চলমান কোনো unit-এর দ্বিতীয় কপি চালু করে না। শেষের বৈশিষ্ট্যটি agent loop-এ সবচেয়ে সাধারণ overlap bug দূর করে: একই branch সম্পাদনা করা দুটি run।

unit-টি /etc/systemd/system/agent-loop.service-এ লিখুন:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

এবং timer-টি /etc/systemd/system/agent-loop.timer-এ লিখুন:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers-এ ভবিষ্যতের একটি সময়সহ NEXT column এবং countdown দেখানো LEFT column থাকা উচিত। ফলাফল খালি হলে timer enabled নয়। কারণ enable, --now ছাড়া, এটিকে শুধু পরবর্তী boot-এর জন্য schedule করে। TimeoutStartSec=1800-এর গুরুত্ব প্রত্যাশার চেয়ে বেশি: input-এর অপেক্ষায় আটকে থাকা কোনো agent অন্যথায় unit-টিকে অনির্দিষ্টকাল active রাখবে এবং timer আর কখনো fire করবে না। journalctl -u agent-loop.service -n 50 দিয়ে একটি run-এর বিবরণ দেখুন।

পরিবর্তে cron দিয়ে loop চালালে নিজস্ব overlap guard যোগ করুন, কারণ cron সহজেই দ্বিতীয় কপি চালু করবে:

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

lock দখলে থাকলে flock -n সঙ্গে সঙ্গে status 1 দিয়ে exit করে। ফলে দ্বিতীয় run প্রথমটির সঙ্গে race না করে নীরবে বন্ধ হয়ে যায়। একই systemd service ও timer সেটআপ box-এ চলমান যেকোনো দীর্ঘস্থায়ী job-এর ক্ষেত্রেও প্রযোজ্য, agent হোক বা না হোক।

সীমা: প্রতিটি রানকে নিজস্ব কপি দিন

আপনার working tree সম্পাদনা করা agent আপনার commit না-করা কাজ হারিয়ে ফেলতে পারে। Git worktree কম খরচে এই সমস্যা সমাধান করে: প্রতিটি রান নিজস্ব directory এবং নিজস্ব branch পায়, আর একটি object store শেয়ার করে।

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list প্রতিটি tree-এর path, commit এবং branch দেখিয়ে একটি করে লাইন প্রিন্ট করে। রান শেষ হলে git worktree remove /srv/agent/work/triage-01 directory মুছে দেয়, আর git worktree prune যেসব entry-এর directory আর নেই, সেগুলো পরিষ্কার করে। এই পর্যায়ে parallel loop নিরাপদ হয়, কারণ ভিন্ন directory-তে থাকা ভিন্ন branch-এর দুই agent একে অপরের কাজ overwrite করতে পারে না।

সীমাটি credentials-এর ক্ষেত্রেও প্রযোজ্য। unattended অবস্থায় চলা একটি loop দীর্ঘস্থায়ী token ধরে রাখে, এবং প্রতিটি রানেই সেটি log, commit অথবা model context-এ ফাঁস হওয়ার সম্ভাবনা থাকে। token-টির scope কেবল loop যে repository-তে কাজ করে, সেই repository-তে সীমাবদ্ধ রাখুন। যেখানে সম্ভব, agent-এর নিজস্ব shell যে environment দেখতে পায়, সেখান থেকে token দূরে রাখুন। loop-কে production access দেওয়ার আগে AI agent থেকে secret দূরে রাখার পদ্ধতি পড়ুন। আরও শক্তিশালী বিচ্ছিন্নতার জন্য পুরো loop-টি প্রতিটি রান শেষে ধ্বংস করা যায় এমন disposable VM-এ চালান।

যাচাই: লুপকে নিরাপদ রাখার গেট

এটাই লুপ এবং শুধু কমান্ড টাইপ করে এমন একটি cron job-এর মধ্যে পার্থক্য তৈরি করে। এজেন্টের আউটপুট হলো একটি প্রস্তাব। গেট সিদ্ধান্ত নেয়।

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

এই স্ক্রিপ্টে set -euo pipefail বাস্তব কাজ করছে। -e না থাকলে, ব্যর্থ git fetch উপেক্ষিত হয় এবং রানটি পুরোনো origin/main-এর ওপর চলতে থাকে। -u না থাকলে, ভেরিয়েবলের নামে টাইপো হলে সেটি একটি খালি স্ট্রিংয়ে প্রসারিত হয়। এরপর cleanup ভুল path-এর ওপর চলে, স্পষ্টভাবে ব্যর্থ হওয়ার পরিবর্তে।

if ! npm test ব্লকটিই মূল ধারণা। আপনি ইতিমধ্যে যে check-কে বিশ্বাস করেন, যেমন আপনার test suite বা type checker, তার exit code নির্ধারণ করে branch-টি push করা হবে নাকি ধ্বংস করা হবে। গেটবিহীন লুপ এমন কাজ তৈরি করে যা পর্যালোচনা করার সময় কারও নেই। এটি কোনো কাজ না থাকার চেয়েও খারাপ। গেটসহ লুপ এমন একটি branch তৈরি করে, যা মানব contributor-এর branch-কে যে একই মানদণ্ড পূরণ করতে হয়, সেটি ইতিমধ্যে পূরণ করেছে।

এমন একটি গেট বেছে নিন যা সঠিকভাবে ব্যর্থ হয়। খালি diff-এ পাস করা test suite লুপকে শেখায় যে কিছু না করাই সফলতা। দুর্বল test-যুক্ত repository দুর্বল লুপ তৈরি করে। তাই জনপ্রিয় repository-গুলোতে "codebase-কে agent-ready করা"-কে "লুপ লেখা"-র আগে রাখা হয়।

বাজেট: কী একটি রান থামায়

যে agent অনন্তকাল retry করে, তার bill-এর কোনো সীমা থাকে না। TimeoutStartSec-এর মাধ্যমে প্রতিটি loop-এর জন্য wall-clock সীমা নির্ধারণ করুন এবং তা কার্যকর করুন; আপনার script-এর ভিতরে retry count নির্ধারণ করুন; আর provider account-এর মাধ্যমে spend cap কার্যকর করুন। এরপর প্রতিটি run-এর খরচ log করুন, যাতে invoice আসার আগেই loop-এর খরচ বেড়ে যাওয়া শনাক্ত করতে পারেন। সবসময় চালু থাকা agent VPS-এর খরচ নিয়ন্ত্রণ-এ accounting-এর দিকটি ব্যাখ্যা করা হয়েছে। turn-এর মধ্যে agent যে context বহন করে তা পরিচালনা করা-এ প্রতি-run খরচের সবচেয়ে বড় একক নিয়ামকটি ব্যাখ্যা করা হয়েছে। কারণ কোনো loop প্রতি 30 মিনিটে একই repository আবার পড়লে, প্রতি 30 মিনিটেই তার জন্য খরচ হয়।

খরচের কারণেই loop সাধারণত একটি দীর্ঘ session-এর চেয়ে ভালো। নতুন করে শুরু হওয়া একটি run একটি নির্দিষ্ট ছোট কাজ সম্পন্ন করে এবং বন্ধ হয়ে গেলে তার context ছোট থাকে। 8 ঘণ্টা খোলা থাকা একটি session তার history-তে আগের সব ভুল বহন করে এবং প্রতিটি turn-এ পুরো transcript-এর জন্য খরচ করে।

ট্রেন্ডিং repository-গুলো যে pattern-গুলোকে সংহত করেছে

loop-engineering repository-তে production-এর জন্য সাতটি pattern তালিকাভুক্ত আছে। এগুলোকে ঘোষণাপত্রের বদলে একটি মেনু হিসেবে পড়া বেশি উপযোগী। দৈনিক triage। এমন একটি pull-request babysitter, যা review comment-এর জন্য monitor করে এবং সেগুলোর উত্তর দেয়। এমন একটি continuous-integration sweeper, যা ব্যর্থ build শনাক্ত করে। dependency sweeper। changelog-এর খসড়া প্রস্তুতকারী। merge-এর পরের cleanup। issue triage।

এগুলোর মিল হলো, প্রতিটির কাজ সীমিত এবং gate স্পষ্ট। "ব্যর্থ build ঠিক করুন"-এর pass condition machine পড়তে পারে। "codebase উন্নত করুন"-এর মতো কাজের pass condition নেই। তাই এটি কখনো loop হয় না। এটি schedule-সহ একটি বিশৃঙ্খলায় পরিণত হয়।

এগুলোর আরেকটি মিল হলো লিখিত record। উভয় repository conversation-এর বাইরে state নিয়ে repository-র file-এ সংরক্ষণ করে: কী চলেছে, কী পাওয়া গেছে এবং কী সিদ্ধান্ত নেওয়া হয়েছে। ওই file-ই loop-এর memory। এর ফলে দ্বিতীয় loop প্রথমটির কাজের ওপর ভিত্তি করে এগোতে পারে, আবার একই তথ্য খুঁজে বের করতে হয় না। পরে agent audit করার এটিই পদ্ধতি, কারণ run শেষ হওয়ার সঙ্গে সঙ্গে model-এর context আর থাকে না।

লুপ যেখানে ব্যর্থ হয়

ব্যর্থতাগুলো একঘেয়ে এবং বিভিন্ন team-এ বারবার ঘটে।

• কোনো gate নেই। Output জমতে থাকে, কেউ তা review করে না, আস্থা নষ্ট হয় এবং লুপ বন্ধ করে দেওয়া হয়।
• Overlap। একই branch-এ দুটি run চলে, অথবা একই working tree-তে দুটি agent কাজ করে। এতে conflict তৈরি হয়, যা পরে agent সমাধান করার চেষ্টা করে।
• নীরব drift। Check ব্যর্থ হওয়ার মতো যথেষ্ট কঠোর না হওয়ায় লুপটি সফল হতে থাকে।
• সীমাহীন scope। ব্যস্ত repository-তে প্রতিটি commit-এ চালু হওয়া trigger এক দিনের মধ্যেই ব্যয়ের সমস্যায় পরিণত হয়।

প্রতিটির একই সমাধান: কাজের পরিধি কমান, check আরও নির্দিষ্ট করুন এবং run log করুন। Pass condition এক বাক্যে বর্ণনা করতে না পারলে job-টি automation-এর জন্য প্রস্তুত নয়।

শব্দভান্ডার ছাড়াই শুরু করা

আপনার কোনো framework দরকার নেই। একটি ছোট, সব সময় চালু থাকা Linux server, এমন একটি git repository যার test suite ব্যর্থ হওয়ার কথা হলে ব্যর্থ হয়, একটি systemd timer এবং তার মধ্যে if থাকা একটি shell script—এই উপাদানগুলোই একটি সম্পূর্ণ loop তৈরি করে। অধিকাংশ মানুষের এখান থেকেই শুরু করা উচিত। কারণ নকশা-সংক্রান্ত প্রশ্নের উত্তর কোনো tool বেছে নেওয়ার মাধ্যমে নয়, সেটি চালিয়ে পাওয়া যায়। একটি loop স্থিতিশীল হলে দ্বিতীয়টি চালানো মূলত আরেকটি timer এবং আরেকটি worktree যোগ করার বিষয়। প্রাথমিক সেটআপের জন্য VPS-এ coding AI agent কীভাবে চালাবেন দেখুন। আর agent-টি আপনার নিয়ন্ত্রণাধীন hardware-এ চালাতে চাইলে বর্তমান self-hosted AI agent-এর বিকল্পগুলো দেখুন।

FAQ

লুপ ইঞ্জিনিয়ারিং কি প্রম্পট ইঞ্জিনিয়ারিং থেকে আলাদা?

প্রম্পট ইঞ্জিনিয়ারিং একটি বার্তা অপ্টিমাইজ করে: শব্দচয়ন, উদাহরণ এবং আউটপুটের ফরম্যাট। লুপ ইঞ্জিনিয়ারিং বার্তাকে ঘিরে থাকা চক্রটি অপ্টিমাইজ করে: যে ট্রিগার একটি রান শুরু করে, যে sandbox-এ এটি চলে, যে পরীক্ষা এর আউটপুট গ্রহণ বা প্রত্যাখ্যান করে, এবং যে বাজেট এটি শেষ করে। লুপের ভেতরে এখনও একটি ভালো প্রম্পট প্রয়োজন। তবে প্রতিদিনের টিউনিংয়ে প্রম্পটই আর প্রধান বিষয় থাকে না, কারণ gate এবং trigger ফলাফলে বেশি প্রভাব ফেলে।

একটি agent loop তৈরি করতে কি আমার framework প্রয়োজন?

না। একটি systemd timer, প্রতি রান-এর জন্য একটি git worktree, একটি shell script যার শেষে একটি test command থাকে, এবং provider account-এ একটি ব্যয়ের সীমা—সংজ্ঞার প্রতিটি অংশের জন্য যথেষ্ট। একাধিক লুপ চালানোর সময় framework-গুলো scheduling interface, shared memory format এবং multi-agent routing যোগ করে, যা কাজে লাগে। তবে প্রথম লুপ তৈরির জন্য এগুলো বাধ্যতামূলক নয়।

codebase harness কী?

এটি এমন উপাদানগুলোর সমষ্টি, যা কোনো মানুষ উপস্থিত না থাকলেও একটি agent-কে repository-তে কাজ করতে দেয়: একটি এক-কমান্ডের setup, non-interactive ভাবে চলে এবং স্পষ্টভাবে ব্যর্থ হয় এমন test, একটি linter, এবং কোনো পরিবর্তন deploy বা preview করার পদ্ধতি। loop engineering-এর মতো একই 2026 সালের repository-ভিত্তিক ধারার সঙ্গে এই শব্দটির উদ্ভব। ব্যবহারিক পরীক্ষা সহজ: কোনো নতুন human contributor যদি একটি command দিয়ে clone থেকে green test পর্যন্ত যেতে না পারে, agent-ও পারবে না।

একটি agent loop-কে বড় বিল তৈরি করা থেকে কীভাবে থামাব?

তিনটি জায়গায় সীমা নির্ধারণ করুন। systemd unit-এ TimeoutStartSec সেট করুন, যাতে আটকে থাকা রান বন্ধ হয়ে যায়। সাফল্য না আসা পর্যন্ত loop না চালিয়ে script-এর ভেতরে retry-এর সংখ্যা সীমিত করুন। API account-এ একটি কঠোর ব্যয়ের সীমা নির্ধারণ করুন, কারণ এটিই একমাত্র সীমা যাকে agent যুক্তি দেখিয়ে অতিক্রম করতে পারে না। এরপর প্রতি রান-এর খরচ log করুন, কারণ যে লুপের খরচ দ্বিগুণ হয়, তার scope সাধারণত অজ্ঞাতসারে বেড়ে যায়।

কোন কাজগুলোকে প্রথমে লুপে রূপান্তর করা উপযুক্ত?

এমন একটি কাজ বেছে নিন যার machine-readable pass condition এবং ছোট blast radius আছে। ব্যর্থ build ঠিক করা, dependency আপডেট করা এবং changelog পুনরায় তৈরি করা—সবই উপযুক্ত, কারণ test suite বা diff ফলাফল প্রমাণ করতে পারে। refactoring বা design-এর মতো open-ended কাজ এখনও উপযুক্ত নয়, কারণ gate পরীক্ষা করার মতো কোনো নির্দিষ্ট ফল নেই। gate ছাড়া লুপ review debt তৈরি করার একটি ব্যয়বহুল পদ্ধতি।