আপোনাৰ app-ৰ মাজেৰে AI agents-ক এটা সংগঠিত পথ কেনেকৈ দিব

AI agents-ক আপোনাৰ app-ৰ ভিতৰত এটা ভিন্ন পথ কিয় লাগে?

আপোনাৰ application-লৈ অহা requests-ৰ এটা বাঢ়ি অহা অংশ AI agents-ৰ পৰা আহে: user-ৰ বাবে documentation আনিবলৈ assistant, product pages পঢ়িবলৈ research tools, আপোনাৰ API call কৰা autonomous workflows. সিহঁতৰ অধিকাংশই মানুহৰ বাবে ডিজাইন কৰা interfaces-ৰ মাজেৰে কাম কৰি আছে. সিহঁতে পূৰ্ণ HTML pages download কৰে, layouts parse কৰে, mouse-ৰ বাবে উদ্দেশ্য কৰা navigation অনুসৰণ কৰে, আৰু script-heavy page-এ আশা কৰা ধৰণে render নকৰিলে retry কৰে.

এইটো সকলোৰে বাবে inefficient. Agents-এ noisy content পায় আৰু ভুল কৰে. আপোনাৰ servers-এ কোনোবাই চোৱা নথকা pages render কৰিবলৈ resources খৰচ কৰে. আৰু traffic-টো বুজিবলৈ কঠিন, কাৰণ ই অদ্ভুত আচৰণ কৰা এটা browser-ৰ দৰে দেখায়. যদি আপোনাৰ traffic-ৰ কিমান অংশ এইটো এতিয়াও নিশ্চিত নহয়, তেন্তে website traffic AI agents-ৰ পৰা আহিছে নেকি কেনেকৈ জানিব তে আৰম্ভ কৰক.

এটা উত্তম পন্থা হৈছে agents-ক এটা structured path দিয়া: programs-ৰ বাবে নিৰ্মিত formats-ত content আৰু actions, standard places-ত discoverable, আৰু নিজকে সঠিকভাৱে চিনাকি দিয়া clients-ক reward কৰা limits-ৰ সৈতে. এই guide-এ দেখুৱায় কেনেকৈ দ্বিতীয়টো application নিৰ্মাণ নকৰাকৈ সেইটো কৰিব পাৰি.

Step 1: Agents-এ কি কৰিব পাৰিব সেয়া সিদ্ধান্ত লওক

technology-ৰ পৰা নহয়, intent-ৰ পৰা আৰম্ভ কৰক. ইতিমধ্যে যি routes-ত agent traffic দেখিছে সেইবোৰ চাই group কৰক:

• Content read কৰা: documentation, product information, pricing pages, help articles, public profiles.
• Data query কৰা: search, catalog lookups, availability, status.
• Actions লোৱা: user-ৰ হৈ কিবা create, update বা delete কৰা.

Reading আৰু querying হৈছে structured path-ৰ ভাল candidate, যি ভাল আচৰণ কৰা যিকোনো client-ৰ বাবে open. Actions-ৰ বাবে client-এ নিজকে কেনেকৈ identify কৰে তাৰ পৰা স্বাধীনভাৱে authentication আৰু authorization লাগে, আৰু সেইবোৰ sensitive actions ৰক্ষা কৰাৰ guide-ত আৱৰা আছে.

Step 2: Machine-friendly formats আগবঢ়াওক

content routes-ৰ বাবে, page chrome নোহোৱাকৈ একে তথ্য আগবঢ়াওক. অধিকাংশ প্ৰয়োজন দুটা format-এ সামৰি লয়:

• Markdown prose content যেনে documentation আৰু articles-ৰ বাবে, RFC 7763-ত নিবন্ধিত text/markdown media type-ৰ সৈতে serve কৰা. ই headings, lists, links আৰু code blocks ৰাখে, আৰু compact.
• JSON structured records যেনে products, plans বা 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 });
});

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

Step 3: Agents-এ আপোনাৰ structured path কেনেকৈ discover কৰে?

Agents-এ যি বিচাৰি নাপায় সেয়া ব্যৱহাৰ কৰিব নোৱাৰে. automated clients ইতিমধ্যে য'ত চায়, সেই ঠাইবোৰত entry points publish কৰক:

1. site root-ত /llms.txt: আপোনাৰ site-এ কি আগবঢ়ায় তাৰ এটা সংক্ষিপ্ত Markdown summary, আটাইতকৈ উপযোগী pages আৰু সিহঁতৰ structured versions-লৈ links-সহ, llms.txt proposal অনুসৰণ কৰি.
2. এটা API description যেনে OpenAPI document, আপোনাৰ developer documentation-ৰ পৰা আৰু /llms.txt-ৰ পৰা linked.
3. HTML pages-ত Markdown বা JSON versions-লৈ pointing কৰা alternate links.
4. Sitemaps protocol-ত নিৰ্ধাৰিত format-ত আপোনাৰ canonical content URLs-ৰ তালিকা থকা এটা sitemap.

এটা 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

Automated clients-ৰ বাবে আপোনাৰ rules ব্যাখ্যা কৰা এটা page ৰাখক: কোন routes open, কি limits apply কৰে, আৰু signed requests-ৰ সৈতে client-এ কেনেকৈ নিজকে identify কৰি উত্তম treatment পাব পাৰে. স্পষ্ট rules-এ অনুমানক cooperation-লৈ ৰূপান্তৰ কৰে.

Step 4: user agent string-ৰ ওপৰত নহয়, actor class-ৰ ওপৰত route কৰক

Structured responses থাকিলে, default-ত কোনে সিহঁত পায় সেয়া সিদ্ধান্ত লওক. ad hoc ভাবে user agent strings parse কৰাৰ পৰিৱৰ্তে actor class আৰু তাৰ basis ব্যৱহাৰ কৰক. AI operators-এ নিজৰ user agents প্ৰকাশ কৰে, যেনে OpenAI আৰু Anthropic-এ সিহঁতৰ crawlers আৰু fetchers-ৰ বাবে কৰে, কিন্তু 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");
}

দুটা principle এইটো সুৰক্ষিত ৰাখে:

• Explicit requests সদায় জয়ী হয়. যদি client-এ Markdown বা JSON বিচাৰে, class যিয়েই নহওক, সেয়া serve কৰক.
• Defaults-এ একো কাঢ়ি নলয়. Human বা Unknown visitor-এ সদায় পূৰ্ণ page পায়. agents-ৰ বাবে structured default বাছিলে format সলায়, সিহঁতে দেখিব পাৰা বস্তু নহয়.

Step 5: AI agents-এ কি rate limits পোৱা উচিত?

Rate limits হৈছে য'ত actor context-এ আটাইতকৈ স্পষ্টভাৱে লাভ দিয়ে. সকলোৰে বাবে একেটা limit-ৰ পৰিৱৰ্তে, class আৰু basis-ৰ প্ৰতিটো সংমিশ্ৰণক যুক্তিসংগত budget দিয়ক:

Limit-টো উপলব্ধ আটাইতকৈ stable identifier-ৰ সৈতে key কৰক. verified agents-ৰ বাবে, সেইটো হৈছে 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-ৰ পৰা সেইবোৰ set কৰক. যদি এটা client-এ limit অতিক্ৰম কৰে, 429 Too Many Requests with a Retry-After header আৰু আপোনাৰ automated access page-লৈ link সহ return কৰক. ভালকৈ নিৰ্মিত agents-এ back off কৰে আৰু সেয়া পঢ়ে.

Step 6: Actions authorization-ৰ আঁৰত ৰাখক

Reading-ৰ বাবে structured path আপোনাৰ security model-ৰ পৰা বাহিৰলৈ যোৱা পথ নহয়. data সলনি কৰা যিকোনো action-এ এতিয়াও এইবোৰ লাগে:

1. আপোনাৰ application-এ issue কৰা credential-ৰ সৈতে authentication,
2. সেই নিৰ্দিষ্ট action-ৰ বাবে authorization, আৰু
3. route-ৰ risk tier-এ যি অতিৰিক্ত checks বিচাৰে সেয়া.

Verified signature-এ কোন client call কৰিছে সেয়া জনায়. ই এইটো নকয় যে client-এ কোনো নিৰ্দিষ্ট user-ৰ হৈ কাম কৰিব পাৰে. সেই প্ৰশ্নবোৰ পৃথক ৰাখক. signed AI agent requests-এ কি প্ৰমাণ কৰে বিষয়ক আমাৰ post-এ পাৰ্থক্যটো ব্যাখ্যা কৰে.

Step 7: প্ৰভাৱ measure কৰক

প্ৰথমে structured path observation mode-ত চলাওক, তাৰ পাছত compare কৰক:

• structured formats ব্যৱহাৰ কৰা agent requests-ৰ অংশ,
• আগে আৰু পাছত agent traffic-ৰ বাবে server cost আৰু latency,
• agent clients-ৰ error আৰু retry rates,
• আপোনাৰ signing guidance publish কৰাৰ পাছত declared পৰা verified-লৈ সৰা automated clients-ৰ সংখ্যা.

এই সংখ্যাবোৰে দেখুৱায় structured path-এ নিজৰ কাম কৰি আছে নে নাই আৰু ক'ত ইয়াক আগলৈ বিস্তাৰ কৰিব লাগিব.

Step 8: Structured path version কৰক আৰু document কৰক

Structured path-টোক public interface হিচাপে বিবেচনা কৰক, কাৰণ agents-এ ইয়াৰ ওপৰত build কৰিব. কেইটামান habit-এ ইয়াক dependable ৰাখে:

1. URLs stable ৰাখক. যদি কোনো agent-এ শিকিছিল যে /docs/getting-started.md আছে, তেন্তে সেয়া কাম কৰি থাকিব লাগে. content সৰিলে, 404-ৰ পৰিৱৰ্তে নতুন location-লৈ এটা 301 return কৰক.
2. Update times অন্তৰ্ভুক্ত কৰক. JSON responses-ত এটা updatedAt field আৰু Markdown-ত এটা Last-Modified header ৰাখক, যাতে agents-এ যুক্তিসংগতভাৱে cache কৰিব পাৰে আৰু কিবা সলনি হ’লে মাথোঁ refresh কৰে.
3. conditional requests সমৰ্থন কৰক. If-None-Match আৰু If-Modified-Since-ৰ উত্তৰত 304 Not Modified দিয়া. আপোনাৰ content poll কৰা agents-এ সকলো পুনৰ download কৰাৰ পৰিৱৰ্তে revalidate কৰিব পাৰিলে বহুত কম খৰচ হয়.
4. Breaking changes version কৰক. যদি JSON shape সলনি হ’বই লাগে, এটা নতুন version path বা media type যোগ কৰক আৰু প্ৰকাশিত সময়কালৰ বাবে পুৰণি সংস্কৰণটো ৰাখক.
5. Automated access page-ৰ বাবে changelog প্ৰকাশ কৰক. ভাল আচৰণ কৰা agents-ৰ operators-এ সেয়া পঢ়ে, আৰু ই আপোনাক নতুন structured routes ঘোষণা কৰাৰ ঠাই দিয়ে.

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 });
});

এই practices-এ আপোনাৰ নিজৰ frontend আৰু partner integrations-কো লাভ দিয়ে. এটা stable, cacheable আৰু documented structured path অতি সোনকালে আপোনাৰ application-ৰ সৈতে যিকোনো program-এ কাম কৰাৰ আটাইতকৈ সহজ উপায় হৈ পৰে.

সাধাৰণ ভুলসমূহ

• Agents আৰু মানুহক ভিন্ন তথ্য দিয়া. Structured version-এ page-ৰ দৰে একে তথ্য থাকিব লাগে. divergent content-এ আপোনাৰ product বিষয়ে assistant-এ কথা পতা user-সকলক বিভ্ৰান্ত কৰে.
• Structured path লুকাই ৰখা. যদি সেয়া /llms.txt, আপোনাৰ API docs বা pages-ৰ পৰা linked নহয়, agents-এ HTML scrape কৰি থাকিব.
• Claims reward কৰা. Higher limits verified clients-ৰ বাবে. Copied user agent string-এ ডাঙৰ budget পোৱা উচিত নহয়.
• Caches পাহৰি যোৱা. Vary: Accept নাথাকিলে, এটা cache-এ browser-লৈ Markdown serve কৰিব পাৰে.

Proof of Actor ক'ত fit কৰে

Proof of Actor-এ আপোনাক actor class আৰু basis দিয়ে, যাৰ সহায়ত agents-ক structured content-লৈ route কৰিব আৰু ন্যায্য limits set কৰিব পাৰি. ই signed, declared আৰু inferred agents detect কৰে, আপোনাক সিহঁতে আপোনাৰ routes কেনেকৈ ব্যৱহাৰ কৰে সেয়া বুজিবলৈ সহায় কৰে, আৰু routing decision আপোনাৰ code-ত এৰি দিয়ে.

আমাৰ team-ৰ সৈতে আপোনাৰ নিজৰ application-ৰ বাবে structured path design কৰিবলৈ, early access-ৰ বাবে আবেদন কৰক. বিশেষকৈ API আৰু MCP scenario-ৰ বাবে, APIs আৰু MCP Servers চাওক, আৰু who is calling your MCP server? পঢ়ক যাতে actor context-এ Model Context Protocol tool calls-ত কেনেকৈ প্ৰযোজ্য হয় সেয়া বুজি পায়.

Sources

• RFC 9110: HTTP Semantics: content negotiation (Section 12), Vary (Section 12.5.5), conditional requests (Section 13) and Retry-After (Section 10.2.3)
• RFC 7763: The text/markdown Media Type: Markdown representations serve কৰা
• RFC 8288: Web Linking: typed alternate links
• RFC 6585: Additional HTTP Status Codes, Section 4: 429 Too Many Requests
• llms.txt proposal: /llms.txt file format
• OpenAPI Specification: machine-readable API descriptions
• Sitemaps protocol: sitemap file format
• OpenAI: Overview of OpenAI Crawlers: OpenAI-ৰ published user agents আৰু IP ranges
• Anthropic: crawler and fetcher documentation: ClaudeBot, Claude-User আৰু Claude-SearchBot
• Model Context Protocol specification (2026-07-28): November 2026 অনুযায়ী current MCP revision