നിങ്ങളുടെ ആപ്പിലൂടെ AI ഏജന്റുകൾക്ക് ഘടിതമായ പാത എങ്ങനെ നൽകാം

AI agents-ന് നിങ്ങളുടെ ആപ്പിലൂടെ വ്യത്യസ്തമായ ഒരു പാത എന്തുകൊണ്ടാണ് വേണ്ടത്?

നിങ്ങളുടെ application-ലേക്കുള്ള അഭ്യർത്ഥനകളിൽ വർദ്ധിച്ചുവരുന്ന ഒരു പങ്ക് AI agents-ൽ നിന്നാണ് വരുന്നത്: ഉപയോക്താവിനായി documentation എടുക്കുന്ന assistants, product pages വായിക്കുന്ന research tools, നിങ്ങളുടെ API വിളിക്കുന്ന autonomous workflows. അവയിൽ പലതും ആളുകൾക്കായി രൂപകൽപ്പന ചെയ്ത interfaces വഴിയാണ് പ്രവർത്തിക്കുന്നത്. അവ മുഴുവൻ HTML pages download ചെയ്യുന്നു, layouts parse ചെയ്യുന്നു, mouse-നായി ഉദ്ദേശിച്ച navigation പിന്തുടരുന്നു, script-heavy page അവർ പ്രതീക്ഷിക്കുന്ന വിധത്തിൽ render ചെയ്യാത്തപ്പോൾ വീണ്ടും ശ്രമിക്കുന്നു.

അത് എല്ലാവർക്കും കാര്യക്ഷമമല്ല. Agents-ന് ശബ്‌ദമേറിയ content ലഭിക്കുകയും അവർ പിഴവുകൾ ചെയ്യുകയും ചെയ്യുന്നു. ആരും നോക്കാത്ത pages render ചെയ്യുന്നതിന് നിങ്ങളുടെ servers വിഭവങ്ങൾ ചെലവഴിക്കുന്നു. കൂടാതെ ഈ traffic മനസ്സിലാക്കാൻ ബുദ്ധിമുട്ടാണ്, കാരണം അത് വിചിത്രമായി പെരുമാറുന്ന ഒരു browser പോലെയാണ് കാണുന്നത്. നിങ്ങളുടെ traffic-ന്റെ എത്ര ഭാഗം ഇതാണെന്ന് നിങ്ങൾക്ക് ഇതുവരെ വ്യക്തമായില്ലെങ്കിൽ, website traffic AI agents-ൽ നിന്നാണോ എന്ന് എങ്ങനെ മനസ്സിലാക്കാം എന്നതിൽ നിന്ന് തുടങ്ങുക.

ഇതിലും മെച്ചപ്പെട്ട സമീപനം agents-ന് ഘടിതമായ ഒരു പാത നൽകുന്നതാണ്: programs-ിനായി നിർമ്മിച്ച formats-ലുള്ള content and actions, standard places-ൽ discover ചെയ്യാനാകുന്നവ, ശരിയായി സ്വയം തിരിച്ചറിയുന്ന clients-നെ പുരസ്കരിക്കുന്ന limits എന്നിവയോടെ. രണ്ടാമത്തെ application നിർമ്മിക്കാതെ അത് എങ്ങനെ ചെയ്യാം എന്നതാണ് ഈ guide കാണിക്കുന്നത്.

Step 1: ഏജന്റുകൾക്ക് എന്ത് ചെയ്യാൻ കഴിയണം എന്ന് തീരുമാനിക്കുക

Technology-യിൽ അല്ല, intent-ിൽ നിന്നാണ് ആരംഭിക്കേണ്ടത്. നിങ്ങൾ ഇതിനകം agent traffic കാണുന്ന routes നോക്കി അവയെ ഇങ്ങനെ group ചെയ്യുക:

• Content വായിക്കുക: documentation, product information, pricing pages, help articles, public profiles.
• Data query ചെയ്യുക: search, catalog lookups, availability, status.
• Actions എടുക്കുക: ഉപയോക്താവിന്റെ പേരിൽ എന്തെങ്കിലും create, update അല്ലെങ്കിൽ delete ചെയ്യുക.

വായിക്കുകയും query ചെയ്യുകയും ചെയ്യുന്നത്, സുസ്ഥിരമായി പ്രവർത്തിക്കുന്ന ഏത് client-നും തുറന്നിരിക്കുന്ന ഘടിത പാതയ്ക്ക് നല്ല candidates ആണ്. Actions-ന് client സ്വയം എങ്ങനെ തിരിച്ചറിയുന്നുവെന്നതിനെക്കുറിച്ച് നോക്കാതെ തന്നെ authenticationയും authorizationഉം വേണം, കൂടാതെ അവ sensitive actions സംരക്ഷിക്കുന്ന guide-ൽ ഉൾപ്പെടുത്തിയിരിക്കുന്നു.

Step 2: Machine-friendly formats നൽകുക

Content routes-ക്കായി, page chrome ഇല്ലാതെ തന്നെ അതേ information നൽകുക. മിക്ക ആവശ്യങ്ങളും രണ്ട് formats കൊണ്ട് ഉൾക്കൊള്ളാം:

• Markdown എന്നത് documentation, articles പോലുള്ള prose content-യ്ക്ക്. ഇത് text/markdown media type-ോടുകൂടി, RFC 7763-ൽ registered ചെയ്തതുപോലെ, നൽകുക. ഇത് headings, lists, links, code blocks എന്നിവ നിലനിർത്തുകയും compact ആയിരിക്കുകയും ചെയ്യുന്നു.
• JSON എന്നത് products, plans, status പോലുള്ള structured records-ിനായി.

content negotiation ഉപയോഗിക്കുക, അതുവഴി URL അതേപോലെ തുടരുകയും client തനിക്കാവശ്യമായ format ചോദിക്കുകയും ചെയ്യാൻ കഴിയും:

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) അയയ്ക്കുക, അതുവഴി caches ഓരോ representation-ഉം വേർതിരിച്ച് സംഭരിക്കും. പല ടീമുകളും appending .md പോലുള്ള ഒരു explicit alternate URL കൂടി expose ചെയ്യുന്നു, ഉദാഹരണത്തിന് documentation path-ലേക്ക്, കാരണം ചില clients-ന് അത് negotiation-നെക്കാൾ എളുപ്പമാണ്. HTML page-ൽ നിന്ന് <link rel="alternate" type="text/markdown" href="..."> ഉപയോഗിച്ച് അത് link ചെയ്യുക, അതുവഴി അത് കണ്ടെത്താനാകും. ഇത്തരത്തിലുള്ള typed links Web Linking model പിന്തുടരുന്നു.

Step 3: ഏജന്റുകൾ നിങ്ങളുടെ ഘടിത പാത എങ്ങനെ കണ്ടെത്തും?

Agents-ന് കണ്ടെത്താൻ കഴിയാത്തത് അവർക്ക് ഉപയോഗിക്കാനാവില്ല. Automated clients ഇതിനകം നോക്കുന്ന സ്ഥലങ്ങളിൽ entry points publish ചെയ്യുക:

1. Site root-ൽ /llms.txt: നിങ്ങളുടെ site എന്താണ് നൽകുന്നതെന്ന് ചുരുക്കമായി വിവരിക്കുന്ന ഒരു Markdown summary, ഏറ്റവും ഉപകാരപ്രദമായ pages-ിലേക്കും അവയുടെ structured versions-ിലേക്കും ഉള്ള links-ോടുകൂടെ, llms.txt proposal പിന്തുടർന്ന്.
2. ഒരു API വിവരണം, ഉദാഹരണത്തിന് ഒരു OpenAPI document, നിങ്ങളുടെ developer documentation-ൽ നിന്നും /llms.txt-ൽ നിന്നും link ചെയ്തിരിക്കുന്നത്.
3. HTML pages-ൽ നിന്ന് Markdown അല്ലെങ്കിൽ JSON versions-ലേക്ക് pointing ചെയ്യുന്ന alternate links.
4. Sitemaps protocol നിർവചിച്ച format-ൽ, നിങ്ങളുടെ canonical content URLs-നെ പട്ടികപ്പെടുത്തുന്ന ഒരു sitemap.

ഒരു കുറഞ്ഞ 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 ബാധകമാണ്, മികച്ച treatment ലഭിക്കാൻ signed requests ഉപയോഗിച്ച് ഒരു client എങ്ങനെ സ്വയം തിരിച്ചറിയാം എന്നിവ. വ്യക്തമായ rules guesswork-നെ cooperation-ആക്കി മാറ്റുന്നു.

Step 4: User agent string നോക്കാതെ actor class അനുസരിച്ച് route ചെയ്യുക

Structured responses ലഭ്യമായ ശേഷം, അവ ആരാണ് default ആയി ലഭിക്കേണ്ടത് എന്ന് തീരുമാനിക്കുക. User agent strings-നെ ad hoc ആയി 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");
}

ഈ രണ്ട് principles സുരക്ഷിതത്വം നിലനിർത്തുന്നു:

• Explicit requests എല്ലായ്പ്പോഴും ജയിക്കും. ഒരു client Markdown അല്ലെങ്കിൽ JSON ചോദിക്കുന്നുവെങ്കിൽ, class എതായാലും അത് serve ചെയ്യുക.
• Defaults ഒന്നും എടുത്തുകളയില്ല. Human അല്ലെങ്കിൽ Unknown visitor-ന് എല്ലായ്പ്പോഴും മുഴുവൻ page ലഭിക്കും. Agents-ിനായി ഒരു structured default തിരഞ്ഞെടുക്കുന്നത് format മാറ്റുന്നു, അവർക്ക് കാണാൻ അവകാശമുള്ളത് അല്ല.

Step 5: AI agents-ന് എന്ത് rate limits നൽകണം?

Actor context ഏറ്റവും വ്യക്തമായി ലാഭം തരുന്നത് rate limits-ലാണ്. എല്ലാവർക്കും ഒരേ limit നൽകുന്നതിനു പകരം, ഓരോ class-ും basis-ഉം ചേർന്ന ഓരോ combination-ക്കും യുക്തിസഹമായ budget നൽകുക:

ലഭ്യമായ ഏറ്റവും സ്ഥിരമായ 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 placeholders ആണ്. നിങ്ങൾ കണ്ട baseline-ൽ നിന്ന് നിങ്ങളുടെത് നിർണ്ണയിക്കുക. ഒരു client limit മറികടക്കുമ്പോൾ, ഒരു 429 Too Many Requestsവും ഒരു Retry-After header-ഉം, കൂടാതെ നിങ്ങളുടെ automated access page-ലേക്കുള്ള ഒരു link-ഉം തിരികെ നൽകുക. നന്നായി നിർമ്മിച്ച agents back off ചെയ്ത് അത് വായിക്കും.

Step 6: Actions authorization-ിന് പിന്നിൽ തന്നെ നിലനിർത്തുക

Reading-ിനായുള്ള ഘടിത പാത നിങ്ങളുടെ security model-ന് ചുറ്റുമുള്ള ഒരു വഴിയല്ല. Data മാറ്റുന്ന ഏതൊരു action-ക്കും ഇപ്പോഴും ഇവ വേണം:

1. നിങ്ങളുടെ application പുറത്തിറക്കിയ ഒരു credential ഉപയോഗിച്ചുള്ള authentication,
2. ആ പ്രത്യേക action-ിനായുള്ള authorization, കൂടാതെ
3. route-ിന്റെ risk tier ആവശ്യപ്പെടുന്ന മറ്റു അധിക checks.

ഒരു verified signature ഏത് client ആണ് വിളിക്കുന്നതെന്ന് പറയുന്നു. എന്നാൽ ഒരു നിശ്ചിത ഉപയോക്താവിന്റെ പേരിൽ client പ്രവർത്തിക്കാമോ എന്ന് അത് പറയുന്നില്ല. ആ ചോദ്യങ്ങൾ വേർതിരിച്ച് സൂക്ഷിക്കുക. what signed AI agent requests prove എന്ന ഞങ്ങളുടെ post-ൽ അതിലെ വ്യത്യാസം വിശദീകരിക്കുന്നു.

Step 7: ഫലം അളക്കുക

Structured path ആദ്യം observation mode-ൽ പ്രവർത്തിപ്പിക്കുക, തുടർന്ന് ഇവ compare ചെയ്യുക:

• structured formats ഉപയോഗിക്കുന്ന agent requests-ന്റെ share,
• മുമ്പും ശേഷവും agent traffic-ിനുള്ള server cost, latency,
• agent clients-ന്റെ error, retry rates,
• നിങ്ങളുടെ signing guidance publish ചെയ്തതിന് ശേഷം declared-ിൽ നിന്ന് verified-ലേക്ക് മാറുന്ന automated clients-ന്റെ എണ്ണം.

ഈ numbers structured path തന്റെ ജോലി ചെയ്യുകയാണോ എന്നും, അടുത്തതായി എവിടേക്ക് അത് വികസിപ്പിക്കണം എന്നും കാണിക്കുന്നു.

Step 8: Structured path version ചെയ്യുകയും document ചെയ്യുകയും ചെയ്യുക

Structured path-നെ ഒരു public interface ആയി കൈകാര്യം ചെയ്യുക, കാരണം agents അതിന്മേൽ നിർമ്മിക്കും. കുറച്ച് habits അത് വിശ്വസനീയമാക്കുന്നു:

1. URLs സ്ഥിരമായി നിലനിർത്തുക. ഒരു agent-ന് /docs/getting-started.md നിലവിലുണ്ടെന്ന് അറിഞ്ഞാൽ, അത് പ്രവർത്തനം തുടരേണ്ടതാണ്. Content മാറുമ്പോൾ, പുതിയ location-ലേക്ക് ഒരു 301 തിരികെ നൽകുക, ഒരു 404-യ്ക്ക് പകരം.
2. Update times ഉൾപ്പെടുത്തുക. JSON responses-ൽ ഒരു updatedAt field-ും Markdown-ൽ ഒരു Last-Modified header-ഉം ഇടുക, അതുവഴി agents യുക്തിപരമായി cache ചെയ്യാനും എന്തെങ്കിലും മാറുമ്പോൾ മാത്രം refresh ചെയ്യാനും കഴിയും.
3. conditional requests പിന്തുണയ്ക്കുക. 304 Not Modified ഉപയോഗിച്ച് If-None-Matchനും If-Modified-Sinceനും പ്രതികരിക്കുക. നിങ്ങളുടെ content poll ചെയ്യുന്ന agents എല്ലാം വീണ്ടും download ചെയ്യുന്നതിനുപകരം revalidate ചെയ്യാൻ കഴിയുമ്പോൾ ചെലവ് വളരെ കുറയുന്നു.
4. Breaking changes version ചെയ്യുക. ഒരു JSON shape മാറ്റേണ്ടതുണ്ടെങ്കിൽ, ഒരു പുതിയ version path അല്ലെങ്കിൽ media type ചേർക്കുക, പഴയതിനെ പ്രസിദ്ധപ്പെടുത്തിയ ഒരു കാലയളവുവരെ നിലനിർത്തുക.
5. Automated access page-ിനായി ഒരു changelog publish ചെയ്യുക. നന്നായി പെരുമാറുന്ന 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-നും സഹായകരമാണ്. സ്ഥിരതയുള്ള, cache ചെയ്യാനാകുന്ന, രേഖപ്പെടുത്തിയ ഒരു structured path ഏതൊരു program-നും നിങ്ങളുടെ application-നൊപ്പം പ്രവർത്തിക്കാൻ ഏറ്റവും എളുപ്പമുള്ള മാർഗമായി മാറുന്നു.

സാധാരണ പിശകുകൾ

• Agents-നും ആളുകൾക്കും വ്യത്യസ്ത facts നൽകുക. Structured version page-ലെ അതേ information തന്നെ ഉൾക്കൊള്ളണം. വ്യത്യസ്ത content നിങ്ങൾക്കുള്ള product-നെക്കുറിച്ച് ഒരു assistant-നോട് ചോദിക്കുന്ന users-നെ குழപ്പിക്കും.
• Structured path മറയ്ക്കുക. അത് /llms.txt-ൽ നിന്നും, നിങ്ങളുടെ API docs-ൽ നിന്നും അല്ലെങ്കിൽ pages-ിൽ നിന്നും link ചെയ്തിട്ടില്ലെങ്കിൽ, agents HTML scrape ചെയ്യുന്നത് തുടരും.
• Claims-നെ പുരസ്കരിക്കുക. Higher limits verified clients-ക്കാണ് നൽകേണ്ടത്. പകർത്തിയ user agent string-ന് വലിയ budget ലഭിക്കരുത്.
• Caches മറക്കുക. Vary: Accept ഇല്ലെങ്കിൽ, ഒരു cache browser-ിന് Markdown serve ചെയ്യാം.

Proof of Actor എവിടെ സ്ഥാനം പിടിക്കുന്നു

Proof of Actor-ന് നിങ്ങൾക്ക് വേണ്ട actor class-ഉം basis-ഉം നൽകുന്നു, അതിലൂടെ agents-നെ structured content-ലേക്ക് route ചെയ്യാനും fair limits സജ്ജീകരിക്കാനും കഴിയും. ഇത് signed, declared, inferred agents-നെ detect ചെയ്യുന്നു, നിങ്ങളുടെ routes അവർ എങ്ങനെ ഉപയോഗിക്കുന്നു എന്ന് മനസ്സിലാക്കാൻ സഹായിക്കുന്നു, routing തീരുമാനത്തെ നിങ്ങളുടെ code-ൽ തന്നെ വിട്ടുതരുന്നു.

നിങ്ങളുടെ സ്വന്തം application-ിനായി structured path രൂപകൽപ്പന ചെയ്യാൻ നമ്മുടെ ടീമിനൊപ്പം, early access-ിന് അപേക്ഷിക്കുക. APIയും MCP സാഹചര്യങ്ങളും പ്രത്യേകമായി മനസ്സിലാക്കാൻ APIsയും MCP Serversയും കാണുക, കൂടാതെ who is calling your MCP server? വായിക്കുക, Model Context Protocol tool calls-ിൽ actor context എങ്ങനെ ബാധകമാകുന്നു എന്നറിയാൻ Model Context Protocol സംബന്ധിച്ച്.

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: serving Markdown representations
• 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