તમારી એપ્લિકેશનમાં AI એજન્ટ્સને રચનાત્મક માર્ગ કેવી રીતે આપવો

AI એજન્ટ્સને તમારી એપ્લિકેશનમાં અલગ માર્ગની જરૂર શા માટે છે?

તમારી એપ્લિકેશનના requestsનો વધતો હિસ્સો AI એજન્ટ્સ પાસેથી આવે છે: વપરાશકર્તા માટે documentation લાવતાં assistants, product pages વાંચતાં research tools, તમારા APIને call કરતાં autonomous workflows. તેમાંના મોટા ભાગના લોકો માટે રચાયેલા interfaces મારફતે કામ કરે છે. તેઓ સંપૂર્ણ HTML pages ડાઉનલોડ કરે છે, layouts parse કરે છે, mouse માટે બનાવેલ navigation અનુસરે છે, અને જ્યારે script-heavy page તેમની અપેક્ષા મુજબ render ન થાય ત્યારે ફરી પ્રયત્ન કરે છે.

આ બધાના માટે અકાર્યક્ષમ છે. એજન્ટ્સને noisy content મળે છે અને ભૂલો થાય છે. તમારા servers એવા pages render કરવામાં resources ખર્ચે છે જેને કોઈ જોતું નથી. અને trafficને સમજવું મુશ્કેલ બને છે, કારણ કે તે અજીબ રીતે વર્તતા browser જેવું દેખાય છે. જો તમને હજી ખાતરી ન હોય કે તમારા trafficનો કેટલો ભાગ આ છે, તો website traffic AI agents પાસેથી આવે છે કે નહીં કેવી રીતે જાણવુંથી શરૂઆત કરો.

વધુ સારું અભિગમ એ છે કે એજન્ટ્સને રચનાત્મક માર્ગ આપવો: programs માટે બનેલા formatsમાં content અને actions, standard જગ્યાઓમાં discoverable, અને એવા limits સાથે જે યોગ્ય રીતે પોતાને ઓળખાવનારા clientsને ઇનામ આપે. આ માર્ગદર્શિકા બતાવે છે કે બીજી application બનાવ્યા વિના આ કેવી રીતે કરવું.

પગલું 1: એજન્ટ્સ શું કરી શકે તે નક્કી કરો

ટેકનોલોજીથી નહીં, intentથી શરૂઆત કરો. તમે જ્યાં પહેલેથી agent traffic જુઓ છો ત્યાંના routes જુઓ અને તેમને જૂથમાં વિભાજિત કરો:

• Content વાંચવું: documentation, product information, pricing pages, મદદ લેખો, public profiles.
• Data query કરવું: search, catalog lookups, availability, status.
• Action કરવી: વપરાશકર્તા તરફથી કંઈક create, update અથવા delete કરવું.

વાંચન અને query કરવું રચનાત્મક માર્ગ માટે સારા ઉમેદવારો છે જે કોઈપણ સારી રીતે વર્તતા client માટે ખુલ્લો હોય. Actions માટે client પોતાને કેવી રીતે ઓળખાવે છે તેની પરવા કર્યા વિના authentication અને authorization જરૂરી છે, અને તે સંવેદનશીલ actionsને સુરક્ષિત રાખવાની માર્ગદર્શિકામાં આવરી લેવાયા છે.

પગલું 2: machine-friendly formats ઓફર કરો

Content routes માટે, page chrome વગરની જ માહિતી ઓફર કરો. બે formats મોટાભાગની જરૂરિયાતો આવરે છે:

• Markdown prose content જેમ કે documentation અને articles માટે, જે text/markdown media type સાથે સર્વ થાય અને RFC 7763માં નોંધાયેલ હોય. તે headings, lists, links અને code blocks રાખે છે, અને compact છે.
• JSON structured records જેમ કે products, plans અથવા status માટે.

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 પર Vary) જેથી caches દરેક representationને અલગથી સંગ્રહે. ઘણા teams સ્પષ્ટ alternate URL પણ expose કરે છે, જેમ કે documentation pathમાં .md ઉમેરવું, કારણ કે કેટલાક clientsને negotiation કરતાં આ વધુ સરળ લાગે છે. HTML pageમાંથી <link rel="alternate" type="text/markdown" href="..."> સાથે તેને link કરો જેથી તે discover કરી શકાય. આવા typed links Web Linking મોડેલને અનુસરે છે.

પગલું 3: એજન્ટ્સ તમારા રચનાત્મક માર્ગને કેવી રીતે discover કરે છે?

જે શોધી શકતા નથી તેનો ઉપયોગ કરી શકતા નથી. automated clients જ્યાં પહેલેથી જુએ છે ત્યાં entry points publish કરો:

1. site root પર /llms.txt: તમારી site શું આપે છે તેનો ટૂંકો Markdown summary, સૌથી ઉપયોગી pages અને તેમની રચનાત્મક 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. A sitemap જે તમારી canonical content URLsની યાદી આપે છે, Sitemaps protocolમાં વ્યાખ્યાયિત formatમાં.

એક ન્યૂનતમ 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 clients માટેના તમારા નિયમો સમજાવે: કયા routes ખુલ્લા છે, કઈ limits લાગુ પડે છે, અને signed requests સાથે client પોતાને કેવી રીતે ઓળખાવી શકે જેથી તેને વધુ સારો treatment મળે. સ્પષ્ટ નિયમો અંદાજને સહકારમાં બદલે છે.

પગલું 4: user agent string નહીં, actor class પ્રમાણે રૂટ કરો

એકવાર તમારી પાસે structured responses હોય, પછી નક્કી કરો કે ડિફૉલ્ટ રીતે કોણ તેને મેળવે. 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");
}

બે સિદ્ધાંતો આને સુરક્ષિત રાખે છે:

• Explicit requests હંમેશાં જીતે છે. જો client Markdown અથવા JSON માંગે, તો તેને આપો, class જે પણ હોય.
• Defaults ક્યારેય કંઈ છીનવી લેતા નથી. Human અથવા Unknown visitorને હંમેશાં સંપૂર્ણ page મળે છે. agents માટે structured default પસંદ કરવાથી format બદલાય છે, તેઓ શું જોઈ શકે તે નહીં.

પગલું 5: AI agentsને કયા rate limits મળવા જોઈએ?

Rate limits એ સ્થળ છે જ્યાં actor context સૌથી સ્પષ્ટ રીતે લાભ આપે છે. બધા માટે એક limitની બદલે, class અને basisના દરેક સંયોજનને યોગ્ય budget આપો:

મર્યાદા માટે ઉપલબ્ધ સૌથી સ્થિર ઓળખકર્તા પ્રમાણે 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 કરે છે અને તેને વાંચે છે.

પગલું 6: actionsને authorization પાછળ રાખો

વાંચન માટેનો રચનાત્મક માર્ગ તમારી security modelને બાયપાસ કરવાનો માર્ગ નથી. data બદલતી કોઈપણ action માટે હજુ પણ આ જરૂરી છે:

1. તમારી application દ્વારા જારી કરાયેલા credential સાથે authentication,
2. તે ચોક્કસ action માટે authorization, અને
3. routeની risk tier જે વધારાની checks માંગે તે.

એક verified signature તમને જણાવે છે કે કયો client call કરી રહ્યો છે. તે આ નથી જણાવતું કે client ચોક્કસ user માટે કાર્ય કરી શકે છે. આ પ્રશ્નોને અલગ રાખો. અમારી signed AI agent requests શું સાબિત કરે છે અંગેની પોસ્ટ તફાવત સમજાવે છે.

પગલું 7: અસર માપો

પ્રથમ observation modeમાં structured path ચલાવો, પછી તુલના કરો:

• structured formatsનો ઉપયોગ કરતી agent requestsનો હિસ્સો,
• પહેલાં અને પછી agent traffic માટે server cost અને latency,
• agent clients માટે error અને retry rates,
• જ્યારે તમે તમારી signing guidance પ્રકાશિત કરો ત્યારે કેટલા automated clients declaredમાંથી verified તરફ જાય છે.

આ આંકડા બતાવે છે કે structured path તેનું કામ કરી રહ્યો છે કે નહીં અને તેને આગળ ક્યાં વિસ્તૃત કરવો.

પગલું 8: structured pathનું versioning કરો અને દસ્તાવેજ બનાવો

structured pathને public interface તરીકે ગણો, કારણ કે agents તેના પર build કરશે. થોડા habits તેને વિશ્વસનીય રાખે છે:

1. URLs સ્થિર રાખો. જો કોઈ agentને ખબર પડી કે /docs/getting-started.md અસ્તિત્વમાં છે, તો તે કામ કરતું રહેવું જોઈએ. content ખસે ત્યારે, નવા સ્થાન પર 301 પાછું આપો, 404 નહીં.
2. Update times સામેલ કરો. JSON responsesમાં updatedAt field અને Markdown પર Last-Modified header મૂકો, જેથી agents યોગ્ય રીતે cache કરી શકે અને કંઈ બદલાય ત્યારે જ refresh કરે.
3. conditional requestsને support કરો. If-None-Match અને If-Modified-Sinceને 304 Not Modified સાથે જવાબ આપો. જે agents તમારી contentને poll કરે છે તેઓ બધું ફરી ડાઉનલોડ કરવા બદલે 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 });
});

આ વ્યવહારો તમારી પોતાની frontend અને partner integrationsને પણ લાભ આપે છે. એક સ્થિર, cacheable અને દસ્તાવેજિત structured path ઝડપથી કોઈપણ program માટે તમારી application સાથે કામ કરવાનો સૌથી સરળ માર્ગ બની જાય છે.

સામાન્ય ખામીઓ

• agents અને લોકો માટે જુદા facts સર્વ કરવું. structured versionમાં page જેવી જ માહિતી હોવી જોઈએ. અલગ content વપરાશકર્તાઓને ગૂંચવે છે જેઓ assistantને તમારા product વિશે પૂછે છે.
• structured path છુપાવવો. જો તે /llms.txt, તમારી API docs અથવા pagesમાંથી link થયેલું ન હોય, તો agents HTML scraping કરતા રહેશે.
• દાવાઓને ઇનામ આપવું. ઊંચી limits verified clients માટે છે. copied user agent stringને મોટું budget મળવું જોઈએ નહીં.
• caches ભૂલી જવું. Vary: Accept વિના, cache browserને Markdown આપી શકે છે.

Proof of Actor ક્યાં ફિટ થાય છે

Proof of Actor તમને actor class અને basis આપે છે જે તમને agentsને structured content તરફ route કરવા અને ન્યાયસંગત limits સેટ કરવા માટે જોઈએ છે. તે signed, declared અને inferred agents શોધે છે, તેઓ તમારા routes કેવી રીતે ઉપયોગ કરે છે તે સમજવામાં મદદ કરે છે, અને routingનો નિર્ણય તમારા codeમાં જ રહેવા દે છે.

અમારી ટીમ સાથે તમારી પોતાની application માટે structured path ડિઝાઇન કરવા માટે, early access માટે અરજી કરો. ખાસ કરીને API અને MCP scenarios માટે, APIs અને MCP Servers જુઓ, અને તમારા MCP serverને કોણ call કરી રહ્યું છે? વાંચો જેથી જાણો કે 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) અને Retry-After (Section 10.2.3)
• RFC 7763: The text/markdown Media Type: Markdown representations સર્વ કરવું
• 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'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): November 2026 મુજબ current MCP revision