ଆପଣଙ୍କ app ମଧ୍ୟରେ AI agents କୁ ଗଠିତ ପଥ କିପରି ଦେବେ

AI agents କାହିଁକି ଆପଣଙ୍କ app ମଧ୍ୟରେ ଭିନ୍ନ ପଥ ଆବଶ୍ୟକ କରନ୍ତି?

ଆପଣଙ୍କ application କୁ ଆସୁଥିବା request ମଧ୍ୟରୁ ବଢ଼ୁଥିବା ଏକ ଅଂଶ AI agents ଠାରୁ ଆସେ: user ପାଇଁ documentation ଆଣୁଥିବା assistants, product pages ପଢ଼ୁଥିବା research tools, ଆପଣଙ୍କ API କୁ call କରୁଥିବା autonomous workflows. ସେମାନଙ୍କ ଅଧିକାଂଶ ଲୋକଙ୍କ ପାଇଁ ତିଆରି interfaces ମାଧ୍ୟମରେ କାମ କରୁଛନ୍ତି. ସେମାନେ ସମ୍ପୂର୍ଣ୍ଣ HTML pages download କରନ୍ତି, layout parse କରନ୍ତି, mouse ପାଇଁ ତିଆରି navigation ଅନୁସରଣ କରନ୍ତି, ଏବଂ script-heavy page ଆଶା କରାଯାଇଥିବା ଭାବରେ render ନହେଲେ retry କରନ୍ତି.

ଏହା ସମସ୍ତଙ୍କ ପାଇଁ ଅକ୍ଷମ. Agents ଅସ୍ପଷ୍ଟ content ପାଆନ୍ତି ଏବଂ ଭୁଲ କରନ୍ତି. ଆପଣଙ୍କ servers ସେମାନଙ୍କ ଦ୍ୱାରା କେହି ଦେଖୁନଥିବା pages render କରିବାରେ resource ଖର୍ଚ୍ଚ କରନ୍ତି. ଏବଂ traffic ବିଷୟରେ ଯୁକ୍ତି କରିବା କଠିନ, କାରଣ ଏହା ଅସାଧାରଣ ଭାବରେ ବ୍ୟବହାର କରୁଥିବା browser ପରି ଦିଶେ. ଯଦି ଆପଣଙ୍କ traffic ମଧ୍ୟରୁ କେତେ ଏହା ଅଛି ବୋଲି ଏପର୍ଯ୍ୟନ୍ତ ନିଶ୍ଚିତ ନୁହନ୍ତି, ତେବେ website traffic AI agents ଠାରୁ ଆସୁଛି କି ନାହିଁ କିପରି କହିବେ ଦେଖନ୍ତୁ.

ଏକ ଭଲ ପଦ୍ଧତି ହେଉଛି agents କୁ ଗଠିତ ପଥ ଦେବା: programs ପାଇଁ ତିଆରି formats ରେ content ଏବଂ actions, standard ସ୍ଥାନରେ discoverable, ଏବଂ ନିଜକୁ ସଠିକ ଭାବରେ identify କରୁଥିବା clients କୁ ପୁରସ୍କୃତ କରୁଥିବା limits ସହିତ. ଏହି guide ଦେଖାଏ କିପରି ଦ୍ୱିତୀୟ application ତିଆରି ନକରି ଏହା କରିବେ.

ପଦକ୍ଷେପ 1: agents କଣ କରିପାରିବା ଉଚିତ୍ ତାହା ସ୍ଥିର କରନ୍ତୁ

technology ରୁ ନୁହେଁ, intent ରୁ ଆରମ୍ଭ କରନ୍ତୁ. ଆପଣ ଯେଉଁ routes ରେ ପୂର୍ବରୁ agent traffic ଦେଖୁଛନ୍ତି, ସେଗୁଡ଼ିକୁ ଦେଖନ୍ତୁ ଏବଂ ସେମାନେ group କରନ୍ତୁ:

• Content ପଢ଼ନ୍ତୁ: documentation, product information, pricing pages, help articles, public profiles.
• Data ପ୍ରଶ୍ନ କରନ୍ତୁ: search, catalog lookups, availability, status.
• Action ନିଅନ୍ତୁ: user ଙ୍କ ପକ୍ଷରୁ କିଛି create, update କିମ୍ବା delete କରନ୍ତୁ.

Reading ଏବଂ querying ଗଠିତ ପଥ ପାଇଁ ଭଲ candidate, ଯାହା ଯେକୌଣସି well-behaved client ପାଇଁ ଖୋଲା. Actions ପାଇଁ client ନିଜକୁ କିପରି identify କରେ ତାହା ଯେପରି ହେଉ, authentication ଏବଂ authorization ଆବଶ୍ୟକ, ଏବଂ ସେମାନେ sensitive actions କୁ ସୁରକ୍ଷା କରିବା guide ରେ ଆବରଣ କରାଯାଇଛି.

ପଦକ୍ଷେପ 2: machine-friendly formats ପ୍ରଦାନ କରନ୍ତୁ

content routes ପାଇଁ, page chrome ଛଡ଼ା ସେହି ଅନୁଭୂତିର ସମାନ information ଦିଅନ୍ତୁ. ଦୁଇଟି format ଅଧିକାଂଶ ଆବଶ୍ୟକତାକୁ ଆବରଣ କରେ:

• Markdown prose content ପାଇଁ, ଯଥା documentation ଏବଂ articles, text/markdown media type ସହିତ served, ଯାହା RFC 7763 ରେ registered. ଏହା headings, lists, links ଏବଂ code blocks କୁ ରଖେ, ଏବଂ compact.
• JSON structured records ପାଇଁ, ଯଥା products, plans କିମ୍ବା status.

content negotiation ବ୍ୟବହାର କରନ୍ତୁ ଯାହାଦ୍ୱାରା URL ସମାନ ରହେ ଏବଂ client ନିଜେ ଚାହୁଁଥିବା format ପାଇଁ ask କରେ:

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 କୁ ଅଲଗାଭାବେ store କରେ. ବହୁ team ମାନେ ଏକ explicit alternate URL ମଧ୍ୟ expose କରନ୍ତି, ଯଥା documentation path କୁ .md ଯୋଡ଼ିବା, କାରଣ କେତେକ client ପାଇଁ negotiation ଠାରୁ ଏହା ସହଜ. HTML page ରୁ <link rel="alternate" type="text/markdown" href="..."> ସହିତ ଏହାକୁ link କରନ୍ତୁ, ଯାହାଦ୍ୱାରା ଏହା discover ହୋଇପାରିବ. ଏପରି typed links Web Linking model ଅନୁସରଣ କରେ.

ପଦକ୍ଷେପ 3: agents ଆପଣଙ୍କ ଗଠିତ ପଥ କିପରି ଖୋଜିବେ?

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 ରୁ link କରାଯାଇଥାଏ.
3. HTML pages ରେ alternate links, Markdown କିମ୍ବା JSON versions କୁ point କରୁଥିବା.
4. Sitemaps protocol ଦ୍ୱାରା defined 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 ଖୋଲା, କେଉଁ limits ଲାଗୁ ହୁଏ, ଏବଂ signed requests ସହିତ client କିପରି ନିଜକୁ identify କରି better treatment ପାଇପାରେ. ସ୍ପଷ୍ଟ rules guesswork କୁ cooperation ରେ ପରିଣତ କରେ.

ପଦକ୍ଷେପ 4: user agent string ନୁହେଁ, actor class ଅନୁଯାୟୀ route କରନ୍ତୁ

structured responses ପାଇଲେ, default ଭାବେ କେଉଁମାନେ ସେଗୁଡ଼ିକ ପାଆନ୍ତି ତାହା ନିଷ୍ପତ୍ତି କରନ୍ତୁ. ad hoc ଭାବରେ user agent strings parse କରିବା ପରିବର୍ତ୍ତେ actor class ଏବଂ ଏହାର basis ବ୍ୟବହାର କରନ୍ତୁ. AI operators ନିଜ user agents publish କରନ୍ତି, ଯେପରି 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 ଏହାକୁ safe ରଖେ:

• Explicit requests ସବୁବେଳେ ଜିତେ. ଯଦି client Markdown କିମ୍ବା JSON ଚାହୁଁଛି, class ଯାହାହେଉ ନାହିଁ, ତାହା serve କରନ୍ତୁ.
• Defaults କେବେ କିଛି କାଢ଼ି ନେଇନଥାଏ. Human କିମ୍ବା Unknown visitor ସବୁବେଳେ full page ପାଏ. agents ପାଇଁ structured default ଚୟନ କରିବା format ବଦଳାଏ, ସେମାନେ ଯାହା ଦେଖିପାରିବେ, ତାହା ନୁହେଁ.

ପଦକ୍ଷେପ 5: AI agents କେଉଁ rate limits ପାଇବା ଉଚିତ୍?

Rate limits ହେଉଛି ସେ ସ୍ଥାନ ଯେଉଁଠାରେ actor context ସବୁଠାରୁ ସ୍ପଷ୍ଟ ଭାବରେ ଲାଭ ଦେଉଛି. ସମସ୍ତଙ୍କ ପାଇଁ ଏକ limit ପରିବର୍ତ୍ତେ, class ଏବଂ basis ର ପ୍ରତ୍ୟେକ combination କୁ ଯୁକ୍ତିସଙ୍ଗତ budget ଦିଅନ୍ତୁ:

ସବୁଠାରୁ stable available identifier ଦ୍ୱାରା limit 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;
}

Numbers placeholder. ଆପଣ observe କରିଥିବା baseline ରୁ ନିଜ number set କରନ୍ତୁ. client limit ଅତିକ୍ରମ କଲେ, 429 Too Many Requests ସହିତ Retry-After header ଏବଂ ଆପଣଙ୍କ automated access page କୁ link ପଠାନ୍ତୁ. well-built agents back off କରନ୍ତି ଏବଂ ଏହା ପଢ଼ନ୍ତି.

ପଦକ୍ଷେପ 6: actions କୁ authorization ପଛରେ ରଖନ୍ତୁ

reading ପାଇଁ ଗଠିତ ପଥ ଆପଣଙ୍କ security model ର ଚାରିପାଖରେ ପଥ ନୁହେଁ. data ବଦଳାଉଥିବା କୌଣସି action ତଥାପି ଆବଶ୍ୟକ କରେ:

1. ଆପଣଙ୍କ application issue କରିଥିବା credential ସହିତ authentication,
2. ସେହି specific action ପାଇଁ authorization, ଏବଂ
3. route ର risk tier ଯାହାକୁ ଡାକେ, ସେହି additional checks.

verified signature ଆପଣଙ୍କୁ କେଉଁ client call କରୁଛି ତାହା କୁହେ. ଏହା କୁହେନାହିଁ ଯେ client କୌଣସି specific user ପାଇଁ act କରିପାରିବ. ସେହି ପ୍ରଶ୍ନଗୁଡ଼ିକୁ ଅଲଗା ରଖନ୍ତୁ. signed AI agent requests କଣ ପ୍ରମାଣ କରେ ବିଷୟରେ ଆମ post ଏହି ପାର୍ଥକ୍ୟ ବ୍ୟାଖ୍ୟା କରେ.

ପଦକ୍ଷେପ 7: ପ୍ରଭାବ ମାପନ କରନ୍ତୁ

ପ୍ରଥମେ observation mode ରେ structured path ଚଳାନ୍ତୁ, ତାପରେ compare କରନ୍ତୁ:

• structured formats ବ୍ୟବହାର କରୁଥିବା agent requests ର share,
• ପୂର୍ବ ଏବଂ ପରେ agent traffic ପାଇଁ server cost ଏବଂ latency,
• agent clients ପାଇଁ error ଏବଂ retry rates,
• ଆପଣଙ୍କ signing guidance publish କରିବା ପରେ declared ରୁ verified କୁ କେତେ automated clients move କରନ୍ତି.

ଏହି numbers ଦେଖାଏ structured path ନିଜ କାମ କରୁଛି କି ନାହିଁ ଏବଂ ପରବର୍ତ୍ତୀରେ କେଉଁଠାକୁ ବିସ୍ତାର କରିବେ.

ପଦକ୍ଷେପ 8: structured path କୁ version ଏବଂ document କରନ୍ତୁ

structured path କୁ public interface ଭାବେ ନିଅନ୍ତୁ, କାରଣ agents ଏଥିରେ build କରିବେ. କିଛି habit ଏହାକୁ dependable ରଖେ:

1. URLs stable ରଖନ୍ତୁ. ଯଦି ଏକ agent ଜାଣିଗଲା ଯେ /docs/getting-started.md ଅଛି, ତେବେ ଏହା କାମ କରିବା ଜାରି ରଖିବା ଉଚିତ୍. content move ହେଲେ, 404 ପରିବର୍ତ୍ତେ new location କୁ ଏକ 301 return କରନ୍ତୁ.
2. update times ସମ୍ମିଳିତ କରନ୍ତୁ. JSON responses ରେ updatedAt field ଏବଂ Markdown ରେ Last-Modified header ରଖନ୍ତୁ, ଯାହାଦ୍ୱାରା agents sensibly cache କରିପାରିବେ ଏବଂ କିଛି ବଦଳିଲେ ମାତ୍ର refresh କରିପାରିବେ.
3. conditional requests ସମର୍ଥନ କରନ୍ତୁ. If-None-Match ଏବଂ If-Modified-Since କୁ 304 Not Modified ସହିତ respond କରନ୍ତୁ. ଯେଉଁ agents ଆପଣଙ୍କ content poll କରନ୍ତି, ସେମାନେ ସବୁକିଛି ପୁଣି download ନକରି revalidate କରିପାରିଲେ ଖର୍ଚ୍ଚ ବହୁତ କମ୍ ହୁଏ.
4. breaking changes କୁ version କରନ୍ତୁ. ଯଦି JSON shape ବଦଳିବାକୁ ପଡ଼େ, ଏକ new version path କିମ୍ବା media type ଯୋଡ଼ନ୍ତୁ ଏବଂ old one କୁ ପ୍ରକାଶିତ period ପର୍ଯ୍ୟନ୍ତ ରଖନ୍ତୁ.
5. automated access page ପାଇଁ changelog ପ୍ରକାଶ କରନ୍ତୁ. well-behaved agents ର operator ମାନେ ଏହା ପଢ଼ନ୍ତି, ଏବଂ ଏହା ନୂତନ 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 ଆପଣଙ୍କ own frontend ଏବଂ partner integrations କୁ ମଧ୍ୟ ଲାଭ ଦେଉଛି. ଏକ structured path ଯାହା stable, cacheable ଏବଂ documented, ଶୀଘ୍ର ଯେକୌଣସି program ପାଇଁ ଆପଣଙ୍କ application ସହିତ କାମ କରିବାର ସବୁଠାରୁ ସହଜ ଉପାୟ ହୋଇଯାଏ.

ସାଧାରଣ ଭୁଲ

• agents ଏବଂ people ପାଇଁ ଭିନ୍ନ facts serve କରିବା. structured version page ସହିତ ସମାନ information ଧାରଣ କରିବା ଉଚିତ୍. divergent content ଏକ assistant କୁ ଆପଣଙ୍କ product ବିଷୟରେ ପ୍ରଶ୍ନ କରୁଥିବା users କୁ ଅସ୍ମଝସ୍ୟାରେ ପକାଏ.
• structured path କୁ ଲୁଚାଇ ରଖିବା. ଯଦି ଏହା /llms.txt, ଆପଣଙ୍କ API docs, କିମ୍ବା page ନିଜେରୁ link ହୋଇନାହିଁ, agents HTML scrape କରିବା ଜାରି ରଖିବେ.
• claims କୁ ପୁରସ୍କୃତ କରିବା. 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 କରିବା ଏବଂ fair limits ସେଟ୍ କରିବା ପାଇଁ ଆବଶ୍ୟକ. ଏହା signed, declared ଏବଂ inferred agents କୁ detect କରେ, ସେମାନେ ଆପଣଙ୍କ routes କିପରି ବ୍ୟବହାର କରନ୍ତି ତାହା ବୁଝିବାରେ ସହାୟତା କରେ, ଏବଂ routing decision କୁ ଆପଣଙ୍କ code ମଧ୍ୟରେ ରଖେ.

ଆପଣଙ୍କ own application ପାଇଁ ଏକ structured path ଆମ team ସହିତ design କରିବାକୁ, early access ପାଇଁ apply କରନ୍ତୁ. API ଏବଂ MCP scenarios ପାଇଁ ବିଶେଷଭାବେ, 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: the /llms.txt file format
• OpenAPI Specification: machine-readable API descriptions
• Sitemaps protocol: sitemap file format
• OpenAI: Overview of OpenAI Crawlers: OpenAI's published user agents and IP ranges
• Anthropic: crawler and fetcher documentation: ClaudeBot, Claude-User and Claude-SearchBot
• Model Context Protocol specification (2026-07-28): the current MCP revision as of November 2026