স্থায়ী AI এজেন্টের জন্য ওয়ার্কফ্লো সেমান্টিকস প্রয়োজন, চ্যাট লুপ নয়

একটি এজেন্ট ডেমো হলো একটি লুপ:

text1 line

prompt -> model -> tool -> model -> answer

একটি প্রডাকশন এজেন্ট হলো দীর্ঘসময় ধরে চলা একটি ডিস্ট্রিবিউটেড ওয়ার্কফ্লো, যেখানে মডেল কলগুলো নন-ডিটারমিনিস্টিক, টুলগুলোর সাইড এফেক্ট রয়েছে, মানুষ কয়েক ঘণ্টা পর কাজ অনুমোদন করতে পারে, ক্রেডেনশিয়াল এক্সপায়ার করে, ডেপ্লয়মেন্ট কোড পরিবর্তন করে, এবং “প্রভাব ঘটেছে” ও “স্টেট রেকর্ড করা হয়েছে”-র মধ্যবর্তী যেকোনো সময় যেকোনো প্রসেস ক্র্যাশ করতে পারে।

মূল আর্কিটেকচারের প্রশ্নটি এটি নয় যে কোন ফ্রেমওয়ার্ক টুল কল করতে পারে। প্রশ্নটি হলো: কোন স্থায়ী স্টেট সিস্টেমটিকে প্রতিটি পদক্ষেপ ব্যাখ্যা করতে, পুনরায় শুরু করতে এবং নিরাপদে compensation চালাতে সাহায্য করে?

এক্সিকিউশন থেকে রিজনিং আলাদা করুন

মডেলকে এমন একটি প্ল্যানার হিসেবে বিবেচনা করুন যা পরবর্তী অ্যাকশনের প্রস্তাব দেয়, সম্পন্ন হওয়া অ্যাকশনের সোর্স অব ট্রুথ হিসেবে নয়।

Architecture / inspect the boundariesReasoning proposes. Durable execution decides.

Read left to right on the top row, then right to left below. Persist intent before the external effect; record its evidence afterward. Retrying the effect still requires a stable idempotency key.

Pan, zoom, and select a node. Layout changes stay in your browser.

Read the components and connections

Goal: A durable run ID ties the request, budget, and evidence together.
Model planner: Record model output. Do not repeat model calls inside deterministic replay.
Policy gate: Check permission, remaining budget, and any required human approval before execution.
Durable intent: Persist the proposed operation and stable operation ID before invoking the tool.
Tool effect: A timeout is ambiguous. Retry under the same identity; do not assume the first attempt failed.
Recorded outcome: Persist the outcome before planning again. The target system must enforce effect deduplication.

Goal → Model planner: propose
Model planner → Policy gate: authorize
Policy gate → Durable intent: persist
Durable intent → Tool effect: execute
Tool effect → Recorded outcome: record

text7 lines

goal
  -> planner proposes action
  -> policy checks authority and budget
  -> workflow records intent
  -> tool executor performs effect
  -> workflow records evidence
  -> planner receives normalized result

ওয়ার্কফ্লো লাইফসাইকেল স্টেটের মালিকানা ধরে রাখে। কোনো একটি টুলকে ইমেইল পাঠাতে বলা মাত্রই মডেল এটি সিদ্ধান্ত নিতে পারে না যে ইমেইলটি পাঠানো হয়ে গেছে।

একটি ন্যূনতম স্টেট মডেল হতে পারে:

ts9 lines

type RunState = {
  runId: string
  goal: string
  status: 'running' | 'waiting_approval' | 'completed' | 'failed'
  policyVersion: number
  modelPolicy: { provider: string; model: string; maxTokens: number }
  budget: { tokens: number; toolCalls: number; moneyCents: number }
  steps: StepEvidence[]
}

একটি সুস্পষ্ট প্রাইভেসি পলিসি অনুযায়ী প্রম্পট এবং মডেল আউটপুট সংরক্ষণ করুন। অনেক সিস্টেমের জন্য, অনির্দিষ্টকালের জন্য প্রতিটি র কনভারসেশন সংরক্ষণ করার চেয়ে স্ট্রাকচার্ড সিদ্ধান্ত, হ্যাশ, রিড্যাক্ট করা আর্গুমেন্ট এবং টুল এভিডেন্স সংরক্ষণ করা নিরাপদ।

ডিউরেবল এক্সিকিউশন ব্যর্থতার মডেলকে বদলে দেয়

Temporal-এর মতো ওয়ার্কফ্লো সিস্টেমগুলো একটি ইভেন্ট হিস্ট্রি পারসিস্ট করে এবং ওয়ার্কার ব্যর্থ হওয়ার পর ওয়ার্কফ্লো স্টেট পুনরায় তৈরি করে। প্রধান বৈশিষ্ট্যটি এটি নয় যে “প্রসেসটি চিরকাল চলবে।” মূল বিষয়টি হলো অর্কেস্ট্রেশনটি কোনো আংশিক আপডেট হওয়া রো থেকে আন্দাজে কাজ না করে রেকর্ড করা হিস্ট্রি থেকে পুনরায় শুরু করতে পারে।

ওয়ার্কফ্লো লজিককে ডিটারমিনিস্টিক রাখুন। নেটওয়ার্ক কল, মডেল ইনভোকেশন, ক্লক, র্যান্ডমনেস এবং সাইড এফেক্টগুলোকে অ্যাক্টিভিটির মধ্যে রাখুন:

text6 lines

workflow (replayable decisions)
  activity: call model
  activity: fetch account
  wait: human approval signal
  activity: update CRM
  activity: send notification

একটি অ্যাক্টিভিটি একাধিকবার এক্সিকিউট হতে পারে যদি কোনো ওয়ার্কার এক্সটার্নাল এফেক্ট সম্পন্ন করার পর কিন্তু সমাপ্তি রেকর্ড করার আগে ক্র্যাশ করে। অতএব ডিউরেবল অর্কেস্ট্রেশন আইডেমপোটেন্সি দূর করে না; এটি আপনাকে সঠিকভাবে নির্দেশ করে ঠিক কোথায় আইডেমপোটেন্সি প্রয়োজন।

প্রতিটি এফেক্টকে একটি স্থিতিশীল আইডেন্টিটি দিন

টুল কলের জন্য ডিউরেবল ওয়ার্কফ্লো স্টেট থেকে প্রাপ্ত একটি অপারেশন আইডি প্রয়োজন, যা প্রতি চেষ্টায় নতুন করে তৈরি হয় না:

text1 line

operation_id = run_id + step_number + tool_contract_version

এটি ডাউনস্ট্রিম সিস্টেমে আইডেমপোটেন্সি কি হিসেবে পাস করুন। রিকোয়েস্ট ফিঙ্গারপ্রিন্ট এবং ফলাফল পারসিস্ট করুন:

sql3 lines

INSERT INTO tool_effects(operation_id, tool, request_hash, status)
VALUES ($1, $2, $3, 'started')
ON CONFLICT (operation_id) DO NOTHING;

যদি কোনো এক্সটার্নাল টুল আইডেমপোটেন্সি সাপোর্ট না করে, তবে একটি অস্পষ্টতা কৌশল নির্ধারণ করুন:

প্রমাণ বা এভিডেন্সের জন্য রিমোট সিস্টেমে কুয়েরি করুন;
মানুষের দ্বারা রিকনসিলিয়েশন বাধ্যতামূলক করুন;
এফেক্টটিকে অ্যাপেন্ড-অনলি এবং ক্ষতিপূরণযোগ্য করুন;
অথবা স্বয়ংক্রিয় রিট্রাই নিষিদ্ধ করুন।

“টুলটি আবার রিট্রাই করুন” কোনো সর্বজনীন রিকভারি পলিসি নয়।

অথরাইজেশন এক্সিকিউশনের সময় ঘটা উচিত

মডেলের প্রস্তাবিত আর্গুমেন্টগুলো অবিশ্বস্ত ইনপুট। টুলের বিবরণ এবং সংগৃহীত নথিগুলোও অবিশ্বস্ত, কারণ সেগুলোতে প্রম্পট ইনজেকশন থাকতে পারে।

এক্সিকিউশনের ঠিক আগে সুনির্দিষ্ট অ্যাকশনটি অথরাইজ করুন:

text7 lines

principal: sales_rep_17
tenant: acme
tool: crm.update_contact
resource: contact/882
fields: [next_follow_up]
reason: approved campaign workflow
policy_version: 42

Model Context Protocol-এর অথরাইজেশন স্পেসিফিকেশন সুরক্ষিত সার্ভারগুলোর জন্য OAuth-ভিত্তিক প্যাটার্ন ব্যবহার করে এবং স্পষ্টভাবেই রিসোর্স-সার্ভারের আচরণ নির্ধারণ করে। প্রোটোকল যাই হোক না কেন, মডেলের হাতে কোনো সর্বসাধারণের ব্যবহারের উপযোগী বেয়ারার টোকেন তুলে দেবেন না। এক্সিকিউটরের উচিত ক্রেডেনশিয়াল ধরে রাখা, সেগুলোকে একটি বিশ্বস্ত সার্ভিস আইডেন্টিটির সাথে যুক্ত করা এবং কেবল পলিসি-ফিল্টার করা সক্ষমতাগুলো উন্মুক্ত করা।

দীর্ঘ সময় অপেক্ষার পর পুনরায় অথরাইজেশন যাচাই করুন। যে ব্যবহারকারী গতকাল কোনো অ্যাকশন অনুমোদন করেছিলেন, আজ তার অ্যাক্সেস চলে যেতে পারে; কোনো গ্রাহক ইন্টিগ্রেশন বাতিল করতে পারেন; অথবা কোনো পলিসি পরিবর্তিত হতে পারে।

মানুষের অনুমোদন একটি স্থায়ী স্টেট

একটি বাটন ক্লিকের অপেক্ষায় থাকা HTTP রিকোয়েস্ট হিসেবে অনুমোদন বাস্তবায়ন করবেন না। একটি ট্রানজিশন রেকর্ড করুন:

text3 lines

proposed -> awaiting_approval -> approved -> executing -> evidenced
                        \-> rejected
                        \-> expired

অনুমোদন রিকোয়েস্টে প্রকৃত এফেক্ট প্রদর্শন করা উচিত: প্রাপক, পরিমাণ, পরিবর্তিত ফিল্ড, সিস্টেম ত্যাগকারী ডেটা এবং খরচ। “চালিয়ে যান”-র জন্য একটি অনুমোদন কোনো সচেতন সম্মতি নয়।

অনুমোদনকে প্রস্তাবিত অ্যাকশনের একটি হ্যাশের সাথে বাইন্ড করুন। অনুমোদনের পর যদি প্ল্যানার আর্গুমেন্ট পরিবর্তন করে, তবে নতুন সিদ্ধান্তের প্রয়োজন সৃষ্টি করুন। একটি এক্সপায়ারি নির্দিষ্ট করুন এবং কে অনুমোদন করেছে, কোন রোল ও পলিসি ভার্সনের অধীনে করেছে তা রেকর্ড করুন।

উন্মুক্ত রানগুলো ক্ষতিগ্রস্ত না করে ওয়ার্কফ্লো ভার্সনিং করুন

এজেন্ট রানগুলো ডেপ্লয়মেন্টের চেয়ে বেশি সময় ধরে টিকে থাকতে পারে। একটি নতুন প্রম্পট, টুল স্কিমা, বা ব্রাঞ্চিং রুল রিপ্লে-কে ভিন্নমুখী করতে পারে বা পুরনো স্টেটকে নতুন করে ব্যাখ্যা করতে পারে।

অন্তত নিম্নলিখিত বিষয়গুলোর ভার্সনিং করুন:

ওয়ার্কফ্লো কোড পাথ;
সিস্টেম প্রম্পট এবং মডেল পলিসি;
টুল কন্ট্রাক্ট;
অথরাইজেশন পলিসি;
স্ট্রাকচার্ড আউটপুট স্কিমা;
ইভালুয়েশন রুব্রিক।

বিদ্যমান রানগুলোর উপযুক্ত আচরণের সাথে অব্যাহত থাকা উচিত অথবা একটি সুস্পষ্ট মাইগ্রেশনের মধ্য দিয়ে যাওয়া উচিত। “ডেপ্লয় করুন এবং আশা করুন যে পদক্ষেপগুলোর মাঝে কোনো রান নেই” কোনো রিলিজ কৌশল হতে পারে না।

Temporal ওয়ার্কফ্লো রিপ্লে এবং ভার্সনিং সীমাবদ্ধতাগুলো ডক্যুমেন্ট করে, কারণ নন-ডিটারমিনিস্টিক কোড পরিবর্তন পুনর্গঠনকে ভেঙে দিতে পারে। নিজস্ব তৈরি অর্কেস্ট্রেটরগুলোতেও একই সমস্যা বিদ্যমান; রিকভারি ব্যর্থ না হওয়া পর্যন্ত এটি কম দৃশ্যমান থাকে।

লুপগুলো ইনসিডেন্টে পরিণত হওয়ার আগেই সেগুলোর বাজেট নির্ধারণ করুন

বৃদ্ধি পেতে পারে এমন প্রতিটি মাত্রা সীমিত করুন:

মডেল টোকেন এবং কল;
ওয়াল-ক্লক ডিউরেশন;
শ্রেণী অনুযায়ী টুল কল;
বাহ্যিক খরচ;
রিট্রিভ করা বাইট;
স্টেটের পরিবর্তন ছাড়া বারবার প্ল্যানিং;
ডেলিগেট করা চাইল্ড এজেন্ট;
অনুমোদনের অপেক্ষার সময়।

সেমান্টিকালি সাইকেল শনাক্ত করুন। একই আর্গুমেন্ট সহ একই টুলকে কল করা ভিন্নভাবে লেখা তিনটি প্ল্যান আসলে একটি আটকে থাকা লুপ।

text2 lines

if same_effect_fingerprint >= 2 and no_new_evidence:
    stop(reason="non-progressing loop")

বাজেট প্ল্যানারের কাছে দৃশ্যমান হওয়া উচিত কিন্তু এটি প্ল্যানারের বাইরে কার্যকর করা উচিত।

এভিডেন্স পর্যবেক্ষণ করুন, চেইন-অফ-থট নয়

একটি এজেন্ট পরিচালনা করার জন্য আপনার প্রাইভেট রিজনিং ট্রেসের প্রয়োজন নেই। আপনার স্ট্রাকচার্ড এভিডেন্সের প্রয়োজন:

রান এবং স্টেপ আইডি;
মডেল এবং প্রম্পট পলিসি ভার্সন;
ইনপুট/আউটপুট টোকেন কাউন্ট;
প্রস্তাবিত টুল এবং নরমালাইজড আর্গুমেন্ট;
পলিসি সিদ্ধান্ত এবং রিজন কোড;
অনুমোদন স্টেট;
টুল ল্যাটেন্সি, রিট্রাই এবং ফলাফল;
এক্সটার্নাল এফেক্ট আইডেন্টিফায়ার;
চূড়ান্ত ফলাফল এবং ইভালুয়েশন রেজাল্ট।

OpenTelemetry-এর জেনারেটিভ-AI সেমান্টিক কনভেনশনগুলো মডেল এবং এজেন্ট টেলিমেট্রির জন্য একটি বিকাশমান ভক্যাবিুলারি প্রদান করে। এই কনভেনশনগুলোকে পরিবর্তনশীল হিসেবে বিবেচনা করুন এবং সংবেদনশীল কন্টেন্ট ক্যাপচার অপ্ট-ইন রাখুন।

CTO রিভিউয়ের জন্য প্রশ্নাবলী

প্রতিটি সাইড এফেক্ট ঘটেছে তা প্রমাণ করার মতো কোন স্থায়ী রেকর্ড রয়েছে?
কোন অপারেশনগুলো একাধিকবার এক্সিকিউট হতে পারে এবং সেগুলোকে কীভাবে ডিডুপ্লিকেট করা হয়?
এক্সিকিউশনের সময় সুনির্দিষ্ট অ্যাকশনের বিরুদ্ধে কি অথরাইজেশন মূল্যায়ন করা হয়?
মানুষ কি সঠিক এফেক্ট দেখতে এবং অনুমোদন করতে পারে?
উন্মুক্ত রানগুলো কি ডেপ্লয়মেন্ট এবং পলিসি পরিবর্তন সত্ত্বেও টিকে থাকতে পারে?
অগ্রগতিহীন লুপকে কী থামায়?
অনাবশ্যক প্রাইভেট রিজনিং সংরক্ষণ না করে কি আমরা কোনো ইনসিডেন্ট পুনর্গঠন করতে পারি?

নির্ভরযোগ্য এজেন্ট সেটি নয় যার লুপ সবচেয়ে বুদ্ধিমান। এটি হলো সেটি যার অগ্রগতি স্থায়ী, যার ক্ষমতা সীমাবদ্ধ, যার এফেক্টগুলো প্রমাণিত এবং যার ব্যর্থতা কোনো রহস্যের বদলে একটি রিকভারযোগ্য স্টেট তৈরি করে।

স্থায়ী AI এজেন্টের জন্য ওয়ার্কফ্লো সেমান্টিকস প্রয়োজন, চ্যাট লুপ নয়

এক্সিকিউশন থেকে রিজনিং আলাদা করুন #

ডিউরেবল এক্সিকিউশন ব্যর্থতার মডেলকে বদলে দেয় #

প্রতিটি এফেক্টকে একটি স্থিতিশীল আইডেন্টিটি দিন #

অথরাইজেশন এক্সিকিউশনের সময় ঘটা উচিত #

মানুষের অনুমোদন একটি স্থায়ী স্টেট #

উন্মুক্ত রানগুলো ক্ষতিগ্রস্ত না করে ওয়ার্কফ্লো ভার্সনিং করুন #

লুপগুলো ইনসিডেন্টে পরিণত হওয়ার আগেই সেগুলোর বাজেট নির্ধারণ করুন #

এভিডেন্স পর্যবেক্ষণ করুন, চেইন-অফ-থট নয় #

CTO রিভিউয়ের জন্য প্রশ্নাবলী #

রেফারেন্সসমূহ #

লেখাটি শেয়ার করুন