உங்கள் app-இல் AI agent-களை கட்டமைக்கப்பட்ட பாதையில் செலுத்துவது எப்படி

உங்கள் app-இல் AI agent-க்களுக்கு ஏன் வேறுபட்ட பாதை தேவை?

உங்கள் application-க்கு வரும் requests-இன் ஒரு வளர்ந்து வரும் பகுதி AI agents-இலிருந்து வருகிறது: ஒரு user-க்காக documentation-ஐ எடுத்துக் கொள்கிற assistants, product pages-ஐ படிக்கும் research tools, உங்கள் API-ஐ அழைக்கும் autonomous workflows. அவற்றில் பெரும்பாலானவை மக்களுக்காக வடிவமைக்கப்பட்ட interfaces வழியாக இயங்குகின்றன. அவை முழு HTML pages-ஐ download செய்கின்றன, layouts-ஐ parse செய்கின்றன, mouse-க்கு உகந்த navigation-ஐ பின்பற்றுகின்றன, மேலும் script-heavy page தங்களுக்குப் பரிந்துரைக்கப்பட்ட விதத்தில் render ஆகாதபோது மீண்டும் முயற்சிக்கின்றன.

அது அனைவருக்கும் செயல்திறன் குறைவானது. Agents-க்கு noisy content கிடைக்கிறது, மேலும் அவர்கள் தவறுகள் செய்கின்றனர். உங்கள் servers யாரும் பார்க்காத pages-ஐ render செய்ய resources செலவிடுகின்றன. மேலும் அந்த traffic-ஐப் புரிந்துகொள்வது கடினம், ஏனெனில் அது விசித்திரமாக நடக்கும் browser போலத் தெரிகிறது. இது உங்கள் traffic-இன் எவ்வளவு பகுதி என்பதை இன்னும் நிச்சயமாகத் தெரியாவிட்டால், website traffic AI agents-இலிருந்து வருகிறதா என்பதை எப்படி அறியலாம் என்பதிலிருந்து தொடங்குங்கள்.

மேலும் சிறந்த அணுகுமுறை agent-க்களுக்கு ஒரு கட்டமைக்கப்பட்ட பாதையை வழங்குவது: programs-க்கு ஏற்ற formats-இல் content மற்றும் actions, standard places-இல் discoverable ஆக, தங்களை முறையாக identify செய்யும் clients-ஐ reward செய்யும் limits உடன். இரண்டாவது application ஒன்றை உருவாக்காமல் இதை எப்படி செய்வது என்பதை இந்த guide காட்டுகிறது.

படி 1: agent-கள் என்ன செய்ய முடியும் என்பதை முடிவு செய்யுங்கள்

Technology-யை விட intent-இலிருந்து தொடங்குங்கள். நீங்கள் ஏற்கனவே agent traffic-ஐப் பார்க்கும் routes-ஐ ஆய்ந்து அவற்றை குழுப்படுத்துங்கள்:

• Content-ஐ படிக்கவும்: documentation, product information, pricing pages, help articles, public profiles.
• Data-வை query செய்யவும்: search, catalog lookups, availability, status.
• Actions எடுக்கவும்: ஒரு user-ன் சார்பில் ஏதாவது உருவாக்க, update செய்ய அல்லது delete செய்ய.

Reading மற்றும் querying ஆகியவை முறையாக நடக்கும் எந்த client-க்கும் திறந்திருக்கும் ஒரு கட்டமைக்கப்பட்ட பாதைக்கான நல்ல candidates ஆகும். Actions-க்கு client தன்னை எப்படி அடையாளப்படுத்துகிறது என்பதைக் கருத்தில் கொள்ளாமல் authentication மற்றும் authorization தேவைப்படுகிறது, மேலும் அவை sensitive actions-ஐ பாதுகாப்பது பற்றிய guide-இல் covered ஆகின்றன.

படி 2: machine-friendly formats-ஐ வழங்குங்கள்

Content routes-க்கு, page chrome இல்லாமல் அதே தகவலை வழங்குங்கள். பெரும்பாலான தேவைகளை இரண்டு formats cover செய்கின்றன:

• Markdown - documentation மற்றும் articles போன்ற prose content-க்கு, RFC 7763-இல் பதிவு செய்யப்பட்ட text/markdown media type உடன் வழங்கப்படுகிறது. இது 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-ஐயும் தனித்தனியாக store செய்கின்றன. பல teams documentation path-க்கு .md சேர்ப்பது போன்ற explicit alternate URL ஒன்றையும் expose செய்கின்றன, ஏனெனில் சில clients-க்கு negotiation-ஐ விட அது எளிதாக இருக்கும். அதை HTML page-இலிருந்து <link rel="alternate" type="text/markdown" href="..."> மூலம் link செய்யுங்கள், அப்போதுதான் அது discover செய்யப்பட முடியும். இப்படியான typed links Web Linking model-ஐப் பின்பற்றுகின்றன.

படி 3: agent-கள் உங்கள் கட்டமைக்கப்பட்ட பாதையை எப்படி discover செய்கின்றனர்?

Agent-கள் கண்டுபிடிக்க முடியாததைப் பயன்படுத்த முடியாது. 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-இல் Markdown அல்லது JSON versions-ஐச் சுட்டும் 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 open ஆக உள்ளன, எந்த limits பொருந்துகின்றன, மேலும் better treatment பெற signed requests-உடன் ஒரு client தன்னை எப்படி அடையாளப்படுத்த முடியும். தெளிவான rules guesswork-ஐ cooperation-ஆக மாற்றுகின்றன.

படி 4: user agent string-ஐ வைத்துப் பார்க்காமல் actor class-இன் அடிப்படையில் route செய்யுங்கள்

ஒருமுறை structured responses உங்களிடம் இருந்தால், அவற்றை யார் பெற வேண்டும் என்பதை இயல்பாக முடிவு செய்யுங்கள். user agent strings-ஐ ad hoc முறையில் parse செய்வதை விட actor class மற்றும் அதன் basis-ஐப் பயன்படுத்துங்கள். AI operators தங்கள் crawlers மற்றும் fetchers-க்கான user agents-ஐ வெளியிடுகின்றனர், OpenAI மற்றும் Anthropic செய்வதைப் போல, ஆனால் 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 எதுவாக இருந்தாலும் அதை வழங்குங்கள்.
• Defaults எதையும் பறிக்காது. Human அல்லது Unknown visitor எப்போதும் full page-ஐப் பெறுவார். agents-க்கு structured default ஒன்றைத் தேர்வுசெய்வது format-ஐ மாற்றும், அவர்கள் பார்க்க அனுமதிக்கப்பட்டதை அல்ல.

படி 5: AI agents-க்கு என்ன rate limits இருக்க வேண்டும்?

Rate limits என்பது actor context மிகத் தெளிவாக பயன் தரும் இடம். அனைவருக்கும் ஒரே limit-ஐ விட, class மற்றும் basis ஆகியவற்றின் ஒவ்வொரு சேர்க்கைக்கும் நியாயமான budget-ஐ வழங்குங்கள்:

மிகவும் நிலையான 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;
}

எண்கள் placeholders. நீங்கள் கவனித்த baseline-இலிருந்து உங்களுடையதை அமைக்கவும். ஒரு client ஒரு limit-ஐ மீறினால், 429 Too Many Requests உடன் Retry-After header-ஐவும் உங்கள் automated access page-க்கு ஒரு link-ஐயும் return செய்யுங்கள். நன்றாக உருவாக்கப்பட்ட agents back off செய்து அதை படிக்கின்றன.

படி 6: Actions-ஐ authorization-ன் பின்னால் வைத்திருங்கள்

Reading-க்கு ஒரு structured path இருப்பது உங்கள் security model-ஐ விலக்கிச் செல்லும் வழி அல்ல. data-வை மாற்றும் எந்த action-க்கும் இன்னும் இவை தேவை:

1. உங்கள் application வழங்கிய credential-உடன் authentication,
2. அந்த குறிப்பிட்ட action-க்கான authorization, மற்றும்
3. route-ன் risk tier கேட்கும் கூடுதல் checks எதுவாக இருந்தாலும்.

A verified signature என்பது எந்த client அழைக்கிறது என்பதை உங்களுக்குச் சொல்கிறது. அது அந்த client ஒரு குறிப்பிட்ட user-ன் சார்பில் செயல்படலாம் என்பதைக் கூறாது. அந்த கேள்விகளை தனித்தனியாக வைத்திருங்கள். signed AI agent requests என்ன நிரூபிக்கின்றன என்பதற்கான எங்கள் post வேறுபாட்டை விளக்குகிறது.

படி 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 எத்தனை.

இந்த எண்கள் structured path தன் வேலையைச் செய்கிறதா என்பதையும், அடுத்ததாக அதை எங்கே விரிவாக்க வேண்டும் என்பதையும் காட்டுகின்றன.

படி 8: Structured path-ஐ version செய்யவும், document செய்யவும்

Structured path-ஐ ஒரு public interface போலக் கருதுங்கள், ஏனெனில் agents அதன்மீது கட்டமைப்பார்கள். சில habits அதை நம்பகமாக வைத்திருக்கின்றன:

1. URLs-ஐ நிலையாக வைத்திருங்கள். ஒரு agent-க்கு /docs/getting-started.md உள்ளது என்று தெரிந்தால், அது தொடர்ந்து வேலை செய்ய வேண்டும். content நகரும்போது, 404-க்கு பதிலாக புதிய இடத்திற்கு ஒரு 301 return செய்யுங்கள்.
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 உடன் respond செய்யுங்கள். உங்கள் 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 செய்யக்கூடிய, document செய்யப்பட்ட ஒரு structured path, எந்த program-க்கும் உங்கள் application-உடன் வேலை செய்ய மிகவும் எளிய வழியாக விரைவில் மாறுகிறது.

பொதுவான தவறுகள்

• agents-க்கும் மக்களுக்கும் வேறு facts வழங்குதல். structured version-இல் page-இல் உள்ள அதே தகவல் இருக்க வேண்டும். வேறுபடும் content, உங்கள் product பற்றி ஒரு assistant-ஐக் கேட்கும் users-ஐ குழப்புகிறது.
• Structured path-ஐ மறைப்பது. அது /llms.txt, உங்கள் API docs அல்லது pages-இல் இருந்து link செய்யப்படவில்லை என்றால், agents HTML-ஐ scrape செய்வதைத் தொடர்வார்கள்.
• Claims-ஐ reward செய்வது. Higher limits verified 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-இல் விடுகிறது.

உங்கள் own application-க்கான structured path-ஐ எங்கள் team-உடன் வடிவமைக்க, early access-க்கு விண்ணப்பிக்கவும். குறிப்பாக 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) மற்றும் 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-ன் published user agents மற்றும் IP ranges
• Anthropic: crawler and fetcher documentation: ClaudeBot, Claude-User மற்றும் Claude-SearchBot
• Model Context Protocol specification (2026-07-28): November 2026 நிலவரப்படி தற்போதைய MCP revision