तुमच्या अॅपमधून AI एजंट्सना संरचित मार्ग कसा द्यावा

AI एजंट्सना तुमच्या अॅपमधून वेगळा मार्ग का हवा असतो?

तुमच्या application मधील requests चा वाढता हिस्सा AI agents कडून येतो: एखाद्या user साठी documentation आणणारे assistants, product pages वाचणारी research tools, तुमचा API कॉल करणारे autonomous workflows. त्यापैकी बहुतेक लोकांसाठी डिझाइन केलेल्या interfaces मधून काम करत असतात. ते पूर्ण HTML pages डाउनलोड करतात, layouts parse करतात, mouse साठी असलेले navigation follow करतात, आणि script-heavy page अपेक्षेप्रमाणे render न झाल्यास पुन्हा प्रयत्न करतात.

हे सर्वांसाठी अकार्यक्षम आहे. Agents ना गोंगाटयुक्त content मिळते आणि चुका होतात. तुमचे servers कोणालाही न दिसणारी pages render करण्यासाठी resources खर्च करतात. आणि traffic समजून घेणे कठीण होते, कारण तो विचित्र वागणाऱ्या browser सारखा दिसतो. तुमच्या traffic चा किती भाग असा आहे याबद्दल अजून खात्री नसेल, तर website traffic AI agents कडून येतो का ते कसे ओळखावे येथून सुरुवात करा.

चांगला दृष्टिकोन म्हणजे agents ना संरचित मार्ग देणे: programs साठी तयार केलेल्या स्वरूपांमध्ये content आणि actions, standard ठिकाणी discover होणारे, आणि स्वतःची योग्य ओळख करणाऱ्या clients ना बक्षीस देणाऱ्या limits सह. हे दुसरे application तयार न करता कसे करायचे ते ही मार्गदर्शिका दाखवते.

Step 1: एजंट्सना काय करता आले पाहिजे ते ठरवा

तंत्रज्ञानापेक्षा intent पासून सुरुवात करा. जिथे तुम्हाला आधीच agent traffic दिसतो अशा routes पहा आणि त्यांना गट करा:

• Content वाचा: documentation, product information, pricing pages, help articles, public profiles.
• Data query करा: search, catalog lookups, availability, status.
• Actions घ्या: user च्या वतीने काहीतरी create, update किंवा delete करा.

Reading आणि querying हे कोणत्याही नीट वागणाऱ्या client साठी खुले असलेल्या structured path साठी चांगले candidates आहेत. Actions साठी client स्वतःची ओळख कशी करतो याची पर्वा न करता authentication आणि authorization आवश्यक असते, आणि ते संवेदनशील actions संरक्षित करण्यावरील मार्गदर्शिकेत समाविष्ट आहेत.

Step 2: मशीन-मैत्रीपूर्ण स्वरूपे द्या

Content routes साठी, page chrome शिवाय तीच माहिती द्या. बहुतेक गरजा दोन स्वरूपे पूर्ण करतात:

• Markdown documentation आणि articles सारख्या prose content साठी, text/markdown media type सह सर्व्ह केलेले, जे RFC 7763 मध्ये नोंदवलेले आहे. यात 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 वेगळी साठवतील. अनेक teams एक स्पष्ट alternate URL पण expose करतात, जसे documentation path ला .md जोडणे, कारण काही clients ना negotiation पेक्षा ते सोपे वाटते. HTML page मधून <link rel="alternate" type="text/markdown" href="..."> सह त्याला link करा, म्हणजे ते discover करता येईल. अशा प्रकारचे typed links Web Linking मॉडेलचे अनुसरण करतात.

Step 3: एजंट्सना तुमचा structured path कसा सापडेल?

जे सापडत नाही ते agents वापरू शकत नाहीत. automated clients आधीच जिथे पाहतात तिथे entry points प्रकाशित करा:

1. साइट root वर /llms.txt: तुमची site काय देते याचा छोटा Markdown सारांश, सर्वाधिक उपयुक्त pages आणि त्यांच्या structured versions च्या links सह, llms.txt प्रस्ताव पाळून.
2. एक API description, जसे की OpenAPI document, तुमच्या developer documentation मधून आणि /llms.txt मधून link केलेली.
3. HTML pages मधील alternate links, जे Markdown किंवा JSON versions कडे निर्देश करतात.
4. तुमच्या canonical content URLs ची यादी असलेला sitemap, Sitemaps protocol ने परिभाषित केलेल्या स्वरूपात.

एक किमान 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

स्वयंचलित clients साठी तुमचे नियम स्पष्ट करणारे पान ठेवा: कोणते routes खुले आहेत, कोणत्या limits लागू होतात, आणि signed requests सह client स्वतःची ओळख कशी करून चांगले treatment मिळवू शकतो. स्पष्ट नियम अंदाजाला सहकार्यात रूपांतरित करतात.

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

दोन तत्त्वे हे सुरक्षित ठेवतात:

• Explicit requests नेहमी जिंकतात. जर एखादा client Markdown किंवा JSON मागत असेल, तर class काहीही असो, तेच द्या.
• Defaults कधीही काही हिरावून घेत नाहीत. Human किंवा Unknown visitor ला नेहमी पूर्ण page मिळतो. agents साठी structured default निवडल्याने format बदलतो, त्यांना काय पाहण्याची परवानगी आहे ते नाही.

Step 5: AI agents ना कोणत्या rate limits मिळाव्यात?

Rate limits हे actor context सर्वात स्पष्टपणे मूल्य देतो ते ठिकाण आहे. सर्वांसाठी एक limit ठेवण्याऐवजी, class आणि basis यांच्या प्रत्येक संयोजनाला योग्य budget द्या:

सर्वात स्थिर उपलब्ध identifier नुसार limit key करा. सत्यापित 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 वरून तुमच्या संख्या ठरवा. एखादा client limit ओलांडल्यास, 429 Too Many Requests पाठवा, त्यात Retry-After header आणि तुमच्या automated access page चा link असू द्या. नीट तयार केलेले agents थांबतात आणि ते वाचतात.

Step 6: Actions authorization मागे ठेवा

Reading साठीचा structured path हा तुमच्या security model भोवतीचा मार्ग नाही. data बदलणाऱ्या कोणत्याही action साठी अजूनही आवश्यक आहे:

1. तुमच्या application ने जारी केलेल्या credential सह authentication,
2. त्या विशिष्ट action साठी authorization, आणि
3. route च्या risk tier नुसार आवश्यक असलेली कोणतीही अतिरिक्त तपासणी.

सत्यापित signature तुम्हाला कोणता client कॉल करत आहे ते सांगतो. तो client एखाद्या विशिष्ट user च्या वतीने कृती करू शकतो का हे सांगत नाही. हे प्रश्न वेगळे ठेवा. signed AI agent requests काय सिद्ध करतात यावरची आमची पोस्ट हा फरक स्पष्ट करते.

Step 7: परिणाम मोजा

सुरुवातीला structured path observation mode मध्ये चालवा, मग तुलना करा:

• structured formats वापरणाऱ्या agent requests चा हिस्सा,
• agent traffic साठीचा server cost आणि latency, आधी आणि नंतर,
• agent clients साठीचे error आणि retry rates,
• तुमची signing guidance प्रकाशित केल्यावर declared मधून verified मध्ये जाणारे automated clients किती आहेत.

हे numbers सांगतात की structured path आपले काम करत आहे का आणि पुढे कुठे विस्तार करायचा.

Step 8: Structured path चे versioning करा आणि दस्तऐवजीकरण करा

Structured path ला public interface समजा, कारण agents त्यावर build करतील. काही सवयी ते विश्वासार्ह ठेवतात:

1. URLs स्थिर ठेवा. जर एखाद्या agent ने /docs/getting-started.md अस्तित्वात आहे असे शिकले असेल, तर ते काम करत राहिले पाहिजे. content move झाल्यास, 404 ऐवजी नवीन ठिकाणी 301 परत करा.
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 सह respond करा. जे agents तुमचे content poll करतात त्यांचा खर्च खूप कमी होतो, जेव्हा ते सर्वकाही पुन्हा download करण्याऐवजी revalidate करू शकतात.
4. Breaking changes चे versioning करा. जर 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 सोबत काम करण्याचा सर्वात सोपा मार्ग लवकरच बनतो.

Common pitfalls

• Agents आणि लोकांना वेगवेगळी तथ्ये देणे. Structured version मध्ये page मधील तीच माहिती असली पाहिजे. वेगळे content user ला गोंधळात टाकते, विशेषतः जेव्हा तो assistant ला तुमच्या product विषयी विचारतो.
• Structured path लपवणे. जर ते /llms.txt, तुमच्या API docs किंवा pages स्वतःमधून link केलेले नसेल, तर agents HTML scrape करत राहतील.
• दाव्यांना बक्षीस देणे. जास्त limits सत्यापित clients साठी असतात. कॉपी केलेला user agent string मोठे budget मिळवू नये.
• Caches विसरणे. Vary: Accept शिवाय, एक cache browser ला Markdown देऊ शकतो.

Proof of Actor कुठे बसते

Proof of Actor तुम्हाला agents ना structured content कडे route करण्यासाठी आणि न्याय्य limits ठरवण्यासाठी आवश्यक असलेला actor class आणि basis देते. ते signed, declared आणि inferred agents detect करते, तुमचे routes ते कसे वापरतात हे समजण्यास मदत करते, आणि routing decision तुमच्या code मध्येच ठेवते.

तुमच्या स्वतःच्या application साठी आमच्या team सोबत structured path design करण्यासाठी, early access साठी अर्ज करा. विशेषतः API आणि MCP scenarios साठी, APIs आणि MCP Servers पहा, आणि तुमच्या 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) आणि 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: मशीन-वाचनीय API descriptions
• Sitemaps protocol: sitemap file format
• OpenAI: Overview of OpenAI Crawlers: OpenAI चे प्रकाशित 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