अपने ऐप के भीतर AI एजेंटों को एक संरचित मार्ग कैसे दें

AI agents को आपके app के भीतर अलग path की आवश्यकता क्यों होती है?

आपके application पर आने वाली requests का एक बढ़ता हुआ हिस्सा AI agents से आता है: assistants जो किसी user के लिए documentation fetch करते हैं, research tools जो product pages पढ़ते हैं, autonomous workflows जो आपकी API call करते हैं। उनमें से अधिकांश लोगों के लिए बने interfaces के माध्यम से काम कर रहे होते हैं। वे पूरी HTML pages download करते हैं, layouts parse करते हैं, mouse के लिए बनी navigation का पालन करते हैं, और जब कोई script-heavy page उनकी अपेक्षा के अनुसार render नहीं होता, तो retry करते हैं।

यह सभी के लिए inefficient है। Agents को noisy content मिलता है और वे गलतियाँ करते हैं। आपकी servers उन pages को render करने में resources खर्च करती हैं जिन्हें कोई देखता ही नहीं। और traffic को समझना कठिन हो जाता है, क्योंकि वह एक ऐसे browser जैसा दिखता है जो अजीब तरह से behave कर रहा है। यदि आप अभी तक सुनिश्चित नहीं हैं कि आपके traffic का कितना हिस्सा ऐसा है, तो कैसे पता करें कि website traffic AI agents से आ रहा है से शुरुआत करें।

एक बेहतर approach यह है कि agents को एक structured path दिया जाए: programs के लिए बनाए गए formats में content और actions, standard places में discoverable, और ऐसे limits जिनमें वे clients rewarded हों जो खुद को properly identify करते हैं। यह guide दिखाती है कि दूसरी application बनाए बिना यह कैसे करें।

चरण 1: तय करें कि agents क्या कर सकें

तकनीक से नहीं, intent से शुरू करें। उन routes को देखें जहाँ आपको पहले से agent traffic दिखाई देता है और उन्हें समूहित करें:

• Content पढ़ना: 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 के लिए अच्छे candidates हैं जो किसी भी well-behaved client के लिए खुले हों। Actions के लिए authentication और authorization चाहिए, चाहे client खुद को कैसे भी identify करे, और इन्हें sensitive actions की protection वाले guide में कवर किया गया है।

चरण 2: machine-friendly formats दें

Content routes के लिए, page chrome के बिना वही information दें। दो formats अधिकांश needs कवर करते हैं:

• Markdown prose content जैसे documentation और articles के लिए, जो RFC 7763 में registered text/markdown media type के साथ serve किया जाता है। यह 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 on Vary) भेजें ताकि caches हर representation को अलग-अलग store करें। कई teams एक explicit alternate URL भी expose करती हैं, जैसे documentation path के अंत में .md जोड़ना, क्योंकि कुछ clients के लिए यह negotiation से आसान होता है। इसे HTML page से <link rel="alternate" type="text/markdown" href="..."> के साथ link करें ताकि यह discover हो सके। ऐसे typed links Web Linking model का पालन करते हैं।

चरण 3: agents आपके structured path को कैसे discover करें?

Agents उस चीज़ का उपयोग नहीं कर सकते जिसे वे ढूँढ नहीं सकते। Entry points उन जगहों पर publish करें जहाँ automated clients पहले से देखते हैं:

1. साइट 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. एक sitemap, जो आपके canonical content URLs को Sitemaps protocol द्वारा परिभाषित format में list करे.

एक 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 clients के लिए आपके rules समझाए: कौन से routes खुले हैं, कौन सी limits लागू होती हैं, और कोई client बेहतर treatment पाने के लिए signed requests के साथ खुद को कैसे identify कर सकता है। स्पष्ट rules अनुमान को cooperation में बदल देते हैं।

चरण 4: user agent string के बजाय actor class के आधार पर route करें

जब आपके पास structured responses हों, तो तय करें कि उन्हें डिफ़ॉल्ट रूप से किसे मिले। actor class और उसके basis का उपयोग करें, न कि user agent strings को ad hoc parse करने का। 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 दें:

Limit को सबसे स्थिर उपलब्ध 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;
}

संख्याएँ placeholders हैं। जो baseline आपने देखा है, उससे अपनी limits तय करें। जब कोई client limit पार कर जाए, तो 429 Too Many Requests के साथ Retry-After header और अपने automated access page का link लौटाएँ। अच्छी तरह बने agents back off करते हैं और उसे पढ़ते हैं.

चरण 6: actions को authorization के पीछे रखें

पढ़ने के लिए structured path, आपके security model के आसपास जाने का path नहीं है। कोई भी action जो data बदलता है, अभी भी आवश्यक है:

1. एक credential के साथ authentication, जिसे आपकी application ने issue किया हो,
2. उस specific action के लिए authorization, और
3. route की risk tier द्वारा मांगी गई कोई भी अतिरिक्त checks.

एक verified signature आपको बताती है कि कौन सा client call कर रहा है। यह नहीं बताती कि client किसी दिए गए user की ओर से act कर सकता है। इन प्रश्नों को अलग रखें। signed AI agent requests क्या साबित करते हैं पर हमारी post अंतर को समझाती है।

चरण 7: प्रभाव को मापें

Structured path को पहले observation mode में चलाएँ, फिर तुलना करें:

• agent requests का वह हिस्सा जो structured formats का उपयोग करता है,
• agent traffic के लिए server cost और latency, पहले और बाद में,
• agent clients के error और retry rates,
• कितने automated clients, आपके signing guidance प्रकाशित करने के बाद, declared से verified में बदलते हैं.

ये numbers दिखाते हैं कि structured path अपना काम कर रहा है या नहीं, और इसे आगे कहाँ बढ़ाना है.

चरण 8: structured path को version करें और document करें

Structured path को एक public interface की तरह मानें, क्योंकि agents इसी पर build करेंगे। कुछ habits इसे भरोसेमंद बनाए रखती हैं:

1. URLs स्थिर रखें। यदि किसी agent ने सीखा कि /docs/getting-started.md मौजूद है, तो उसे काम करते रहना चाहिए। जब content move हो, तो नए location पर 301 लौटाएँ, न कि 404.
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 दें। जो agents आपके content को poll करते हैं, उनका cost बहुत कम होता है जब वे सब कुछ फिर से download करने के बजाय revalidate कर सकते हैं.
4. Breaking changes को version करें। यदि JSON shape बदलनी ही पड़े, तो एक नया version path या media type जोड़ें और पुराने version को प्रकाशित अवधि तक बनाए रखें.
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 को भी लाभ देती हैं। एक structured path जो स्थिर, cacheable और documented है, जल्दी ही किसी भी program के लिए आपकी application के साथ काम करने का सबसे आसान तरीका बन जाता है.

सामान्य गलतियाँ

• Agents और लोगों को अलग facts देना। Structured version में page के समान ही information होनी चाहिए। अलग content users को भ्रमित करता है जो किसी assistant से आपके product के बारे में पूछते हैं.
• Structured path को छिपाना। यदि यह /llms.txt, आपकी API docs या खुद pages से link नहीं है, तो 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 करने और fair limits सेट करने के लिए आवश्यकता होती है। यह signed, declared और inferred agents का पता लगाता है, आपको यह समझने में मदद करता है कि वे आपके routes का कैसे उपयोग करते हैं, और routing decision आपके code में छोड़ देता है.

हमारी team के साथ अपनी application के लिए structured path design करने हेतु, early access के लिए आवेदन करें. विशेष रूप से API और MCP scenarios के लिए, APIs और MCP Servers देखें, और आपके MCP server को कौन call कर रहा है? पढ़ें कि actor context Model Context Protocol tool calls पर कैसे लागू होता है.

स्रोत

• 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 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): नवंबर 2026 तक का वर्तमान MCP revision