আপনার অ্যাপের ভেতর দিয়ে AI এজেন্টদের জন্য একটি কাঠামোবদ্ধ পথ কীভাবে দেবেন

আপনার অ্যাপের ভেতর দিয়ে AI এজেন্টদের জন্য আলাদা পথ কেন দরকার?

আপনার application-এর অনুরোধের একটি বাড়তে থাকা অংশ AI এজেন্টদের কাছ থেকে আসে: কোনো user-এর জন্য documentation এনে দেওয়া assistant, product page পড়া research tool, আপনার API কল করা autonomous workflow। এদের অধিকাংশই মানুষের জন্য নকশা করা interface-এর মধ্য দিয়ে কাজ করছে। তারা পুরো HTML page ডাউনলোড করে, layout parse করে, mouse-এর জন্য তৈরি navigation অনুসরণ করে, এবং script-heavy page তাদের প্রত্যাশামতো render না হলে আবার চেষ্টা করে।

এটা সবার জন্যই অকার্যকর। এজেন্টরা বিশৃঙ্খল content পায় এবং ভুল করে। আপনার server এমন page render করতে resource খরচ করে যা কেউ দেখে না। আর এই traffic বোঝা কঠিন, কারণ দেখতে এটা এমন একটি browser-এর মতো যা অস্বাভাবিক আচরণ করছে। যদি এখনও নিশ্চিত না হন যে আপনার traffic-এর কতটা এই ধরনের, তাহলে website traffic কি AI agent থেকে আসছে তা কীভাবে বুঝবেন দিয়ে শুরু করুন।

একটি ভালো পদ্ধতি হলো এজেন্টদের জন্য একটি structured path দেওয়া: program-এর জন্য তৈরি format-এ content এবং action, standard জায়গায় discoverable, এবং নিজেকে সঠিকভাবে identify করা client-দের পুরস্কৃত করে এমন limit। এই guide দেখায় কীভাবে second application না বানিয়েই তা করা যায়।

ধাপ ১: এজেন্টরা কী করতে পারবে তা ঠিক করুন

প্রযুক্তি দিয়ে নয়, উদ্দেশ্য দিয়ে শুরু করুন। যেখানে আপনি ইতিমধ্যে এজেন্ট ট্রাফিক দেখছেন সেই route-গুলো দেখুন এবং সেগুলোকে ভাগ করুন:

• Content পড়া: documentation, product information, pricing page, help article, public profile।
• Data query করা: search, catalog lookup, availability, status।
• Action নেওয়া: কোনো user-এর পক্ষে কিছু create, update বা delete করা।

Reading এবং querying এমন structured path-এর জন্য ভালো candidate যা যেকোনো ভালো আচরণকারী client-এর জন্য উন্মুক্ত। Action-এর জন্য client নিজেকে কীভাবে identify করে তা নির্বিশেষে authentication এবং authorization দরকার, এবং এগুলো sensitive action protect করার guide-এ অন্তর্ভুক্ত।

ধাপ ২: machine-friendly format অফার করুন

Content route-এর জন্য page chrome ছাড়াই একই তথ্য দিন। বেশিরভাগ চাহিদা পূরণ করতে দুইটি format যথেষ্ট:

• Markdown prose content-এর জন্য, যেমন documentation এবং article, যা text/markdown media type দিয়ে পরিবেশন করা হয় এবং RFC 7763-এ নিবন্ধিত। এতে heading, list, link এবং code block থাকে, এবং এটি compact।
• JSON structured record-এর জন্য, যেমন product, plan বা status।

content negotiation ব্যবহার করুন যাতে URL একই থাকে এবং client তার চাওয়া format request করতে পারে:

import express from "express";

const app = express();

app.get("/docs/:slug", async (req, res) => {
  const doc = await loadDoc(req.params.slug);
  if (!doc) return res.status(404).end();

  res.vary("Accept");
  const preferred = req.accepts(["text/html", "text/markdown", "application/json"]);

  if (preferred === "text/markdown") {
    return res.type("text/markdown; charset=utf-8").send(doc.markdown);
  }
  if (preferred === "application/json") {
    return res.json({ title: doc.title, updatedAt: doc.updatedAt, body: doc.markdown });
  }
  return res.render("doc", { doc });
});

একটি Vary: Accept header পাঠান (RFC 9110 on Vary) যাতে cache প্রতিটি representation আলাদা করে সংরক্ষণ করে। অনেক team স্পষ্ট alternate URL-ও প্রকাশ করে, যেমন documentation path-এর শেষে .md যোগ করা, কারণ কিছু client-এর কাছে negotiation-এর চেয়ে এটা সহজ। HTML page থেকে <link rel="alternate" type="text/markdown" href="..."> দিয়ে এটি link করুন, যাতে এটি discover করা যায়। এ ধরনের typed link Web Linking model অনুসরণ করে।

ধাপ ৩: এজেন্টরা আপনার structured path কীভাবে discover করবে?

যা খুঁজে পায় না, তা ব্যবহারও করতে পারে না। এমন জায়গায় entry point প্রকাশ করুন যেখানে automated client ইতিমধ্যে খোঁজে:

1. সাইট root-এ /llms.txt: আপনার site কী অফার করে তার একটি সংক্ষিপ্ত Markdown summary, সবচেয়ে দরকারি page এবং তাদের structured version-এর link সহ, llms.txt proposal অনুসরণ করে।
2. একটি API description, যেমন OpenAPI document, যা আপনার developer documentation এবং /llms.txt থেকে link করা।
3. HTML page-এর মধ্যে alternate link যা Markdown বা JSON version-এ নির্দেশ করে।
4. একটি sitemap যা আপনার canonical content URL তালিকাভুক্ত করে, Sitemaps protocol-এ সংজ্ঞায়িত format-এ।

একটি minimal llms.txt:

# Example App

> Example App helps teams plan projects. This file lists the best entry points for automated clients.

## Docs
- [Getting started](https://example.com/docs/getting-started.md): setup in five steps
- [API reference](https://example.com/openapi.json): OpenAPI description of the public API

## Policies
- [Automated access](https://example.com/docs/automated-access.md): limits and how to sign requests

একটি page রাখুন যা automated client-এর জন্য আপনার নিয়ম ব্যাখ্যা করে: কোন route খোলা, কী limit প্রযোজ্য, এবং signed request দিয়ে client কীভাবে নিজেকে identify করলে better treatment পেতে পারে। স্পষ্ট নিয়ম অনুমানকে cooperation-এ রূপান্তর করে।

ধাপ ৪: user agent string দিয়ে নয়, actor class দিয়ে route করুন

একবার structured response পেয়ে গেলে, কারা তা পাবে তা default হিসেবে ঠিক করুন। ad hoc উপায়ে user agent string parse করার বদলে actor class এবং তার basis ব্যবহার করুন। AI operator-রা তাদের user agent publish করে, যেমন OpenAI এবং Anthropic তাদের crawler এবং fetcher-এর জন্য করে, কিন্তু string match এখনো কেবল একটি declaration।

type ActorClass = "human" | "human_ai" | "agent" | "unknown";
type Basis = "verified" | "declared" | "inferred" | "unknown";

function preferStructured(actor: ActorClass, basis: Basis, accept: string): boolean {
  if (accept.includes("text/markdown") || accept.includes("application/json")) return true;
  return actor === "agent" && (basis === "verified" || basis === "declared");
}

দুইটি নীতি এটি নিরাপদ রাখে:

• Explicit request সবসময় জিতে যায়। কোনো client যদি Markdown বা JSON চায়, তাকে তা দিন, class যাই হোক না কেন।
• Default কখনো কিছু কেড়ে নেয় না। Human বা Unknown visitor সবসময় পূর্ণ page পায়। এজেন্টদের জন্য structured default বেছে নেওয়া শুধু format বদলায়, তারা কী দেখতে পারে তা নয়।

ধাপ ৫: AI এজেন্টদের জন্য কী rate limit থাকা উচিত?

Rate limit-এ actor context সবচেয়ে দৃশ্যমানভাবে উপকার দেয়। সবার জন্য এক limit-এর বদলে, class এবং basis-এর প্রতিটি combination-এর জন্য একটি যুক্তিসঙ্গত budget দিন:

সবচেয়ে স্থিতিশীল identifier ব্যবহার করে limit নির্ধারণ করুন। verified agent-এর জন্য, তা হলো operator origin এবং key identifier। অন্যদের জন্য credential বা network-level key ব্যবহার করুন।

function limitKey(actor: { actor: ActorClass; basis: Basis; operator?: string }, ip: string, apiKey?: string) {
  if (actor.actor === "agent" && actor.basis === "verified" && actor.operator) return `op:${actor.operator}`;
  if (apiKey) return `key:${apiKey}`;
  return `ip:${ip}`;
}

function limitFor(actor: { actor: ActorClass; basis: Basis }): number {
  if (actor.actor === "agent" && actor.basis === "verified") return 600;
  return 120;
}

সংখ্যাগুলো placeholder। আপনি যে baseline পর্যবেক্ষণ করেছেন তা থেকে নিজের limit নির্ধারণ করুন। কোনো client limit ছাড়ালে 429 Too Many Requests ফেরত দিন, সঙ্গে একটি Retry-After header এবং আপনার automated access page-এর link দিন। ভালোভাবে তৈরি agent back off করে এটি পড়ে।

ধাপ ৬: action-কে authorization-এর আড়ালে রাখুন

পড়ার জন্য structured path আপনার security model-এর বিকল্প নয়। data বদলায় এমন যেকোনো action-এর জন্য এখনও প্রয়োজন:

1. আপনার application যে credential ইস্যু করেছে তা দিয়ে authentication,
2. সেই নির্দিষ্ট action-এর জন্য authorization, এবং
3. route-এর risk tier অনুযায়ী প্রয়োজনীয় অতিরিক্ত check।

একটি verified signature আপনাকে বলে কোন client কল করছে। কিন্তু সেটি বলে না যে client কোনো নির্দিষ্ট user-এর পক্ষে কাজ করতে পারে কি না। এই প্রশ্নগুলো আলাদা রাখুন। আমাদের signed AI agent request কী প্রমাণ করে পোস্টে পার্থক্যটি ব্যাখ্যা করা হয়েছে।

ধাপ ৭: প্রভাব পরিমাপ করুন

প্রথমে observation mode-এ structured path চালান, তারপর তুলনা করুন:

• structured format ব্যবহার করা agent request-এর share,
• আগে এবং পরে agent traffic-এর server cost এবং latency,
• agent client-এর error এবং retry rate,
• আপনি signing guidance প্রকাশ করার পর declared থেকে verified-এ যাওয়া automated client-এর সংখ্যা।

এই সংখ্যা দেখায় structured path তার কাজ করছে কি না এবং কোথায় এটিকে পরবর্তী ধাপে বাড়ানো উচিত।

ধাপ ৮: structured path-এর version তৈরি করুন এবং document করুন

structured path-কে public interface হিসেবে ধরুন, কারণ agent এটির ওপর ভিত্তি করে তৈরি করবে। কয়েকটি অভ্যাস এটিকে নির্ভরযোগ্য রাখে:

1. URL স্থির রাখুন। যদি কোনো agent শিখে থাকে যে /docs/getting-started.md আছে, তাহলে সেটি কাজ করে যেতে হবে। content সরলে, 404-এর বদলে নতুন location-এ একটি 301 ফেরত দিন।
2. Update time অন্তর্ভুক্ত করুন। JSON response-এ একটি updatedAt field এবং Markdown-এ একটি Last-Modified header দিন, যাতে agent যুক্তিসঙ্গতভাবে cache করতে এবং শুধু কিছু বদলালে refresh করতে পারে।
3. conditional requests সমর্থন করুন। If-None-Match এবং If-Modified-Since-এর জবাবে 304 Not Modified দিন। আপনার content poll করা agent অনেক কম খরচে কাজ করে যখন তারা সবকিছু আবার ডাউনলোড না করে revalidate করতে পারে।
4. Breaking change-এর version দিন। JSON shape বদলাতেই হলে, নতুন version path বা media type যোগ করুন এবং প্রকাশিত সময়ের জন্য পুরোনোটিকে রাখুন।
5. Automated access page-এর জন্য changelog প্রকাশ করুন। ভালো আচরণকারী agent-এর operator-রা এটি পড়ে, এবং এটি আপনাকে নতুন structured route ঘোষণা করার জায়গা দেয়।

app.get("/api/plans", async (req, res) => {
  const plans = await loadPlans();
  const etag = `"${plans.version}"`;
  res.set("ETag", etag);
  res.set("Cache-Control", "public, max-age=300");
  if (req.get("if-none-match") === etag) return res.status(304).end();
  return res.json({ updatedAt: plans.updatedAt, plans: plans.items });
});

এই অভ্যাসগুলো আপনার own frontend এবং partner integration-এরও উপকার করে। একটি structured path যা stable, cacheable এবং documented, দ্রুতই যেকোনো program-এর জন্য আপনার application-এর সাথে কাজ করার সবচেয়ে সহজ উপায় হয়ে ওঠে।

সাধারণ ভুল

• Agent এবং মানুষের কাছে ভিন্ন তথ্য দেওয়া। Structured version-এ page-এর মতো একই information থাকা উচিত। ভিন্ন content user-কে বিভ্রান্ত করে, যখন তারা আপনার product সম্পর্কে assistant-কে জিজ্ঞেস করে।
• Structured path লুকিয়ে রাখা। যদি এটি /llms.txt, আপনার API doc বা page-গুলোর নিজস্ব লিংক থেকে না থাকে, agent HTML scrape করতেই থাকবে।
• Claim-কে পুরস্কৃত করা। Higher limit verified client-এর জন্য হওয়া উচিত। নকল user agent string বড় budget পাওয়ার কথা নয়।
• Cache ভুলে যাওয়া। Vary: Accept ছাড়া cache ব্রাউজারে Markdown পরিবেশন করতে পারে।

Proof of Actor কোথায় প্রযোজ্য

Proof of Actor আপনাকে agent-কে structured content-এ route করতে এবং ন্যায্য limit নির্ধারণ করতে যে actor class এবং basis দরকার, তা দেয়। এটি signed, declared এবং inferred agent detect করে, তারা আপনার route কীভাবে ব্যবহার করে তা বুঝতে সাহায্য করে, এবং routing decision আপনার code-এই রেখে দেয়।

আপনার own application-এর জন্য আমাদের team-এর সাথে একটি structured path design করতে, early access-এর জন্য আবেদন করুন। বিশেষ করে API এবং MCP scenario-এর জন্য, APIs এবং MCP Servers দেখুন, এবং আপনার MCP server-এ কে কল করছে? পড়ুন, যেখানে actor context Model Context Protocol tool call-এ কীভাবে প্রযোজ্য তা ব্যাখ্যা করা হয়েছে।

উৎস

• RFC 9110: HTTP Semantics: content negotiation (Section 12), Vary (Section 12.5.5), conditional requests (Section 13) এবং Retry-After (Section 10.2.3)
• RFC 7763: The text/markdown Media Type: Markdown representation পরিবেশন করা
• RFC 8288: Web Linking: typed alternate link
• RFC 6585: Additional HTTP Status Codes, Section 4: 429 Too Many Requests
• llms.txt proposal: /llms.txt file format
• OpenAPI Specification: machine-readable API description
• Sitemaps protocol: sitemap file format
• OpenAI: Overview of OpenAI Crawlers: OpenAI-এর প্রকাশিত user agent এবং IP range
• Anthropic: crawler and fetcher documentation: ClaudeBot, Claude-User এবং Claude-SearchBot
• Model Context Protocol specification (2026-07-28): November 2026 অনুযায়ী বর্তমান MCP revision