AI ಏಜೆಂಟ್‌ಗಳಿಗೆ ನಿಮ್ಮ app ಮೂಲಕ ಸಂರಚಿತ ಮಾರ್ಗವನ್ನು ಹೇಗೆ ನೀಡುವುದು

AI agents ಗೆ ನಿಮ್ಮ app ಮೂಲಕ ವಿಭಿನ್ನ ಮಾರ್ಗ ಏಕೆ ಬೇಕು?

ನಿಮ್ಮ application ಗೆ ಬರುವ requests ಗಳಲ್ಲಿ ಹೆಚ್ಚುತ್ತಿರುವ ಭಾಗ AI agents ಗಳಿಂದ ಬರುತ್ತಿದೆ: ಬಳಕೆದಾರರಿಗಾಗಿ documentation ಪಡೆಯುವ assistants, product pages ಓದುವ research tools, ನಿಮ್ಮ API ಅನ್ನು ಕರೆಸುವ autonomous workflows. ಅವುಗಳ ಬಹುಪಾಲು ಜನರಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ interfaces ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತಿವೆ. ಅವು ಸಂಪೂರ್ಣ HTML pages ಅನ್ನು download ಮಾಡುತ್ತವೆ, layouts ಅನ್ನು parse ಮಾಡುತ್ತವೆ, mouse ಗಾಗಿ ಉದ್ದೇಶಿಸಿದ navigation ಅನ್ನು ಅನುಸರಿಸುತ್ತವೆ, ಮತ್ತು script-heavy page ನಿರೀಕ್ಷಿಸಿದಂತೆ render ಆಗದಾಗ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತವೆ.

ಇದು ಎಲ್ಲರಿಗೂ ಅಸಮರ್ಥ. Agents ಗೆ noisy content ಸಿಗುತ್ತದೆ ಮತ್ತು ತಪ್ಪುಗಳು ಉಂಟಾಗುತ್ತವೆ. ಯಾರೂ ನೋಡದ pages ಅನ್ನು render ಮಾಡಲು ನಿಮ್ಮ servers ಸಂಪನ್ಮೂಲಗಳನ್ನು ಖರ್ಚು ಮಾಡುತ್ತವೆ. ಮತ್ತು traffic ಅನ್ನು ವಿವರಿಸುವುದು ಕಷ್ಟವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಅದು ವಿಚಿತ್ರವಾಗಿ ವರ್ತಿಸುವ browser ಹೋಲುತ್ತದೆ. ಇದು ನಿಮ್ಮ traffic ನ ಎಷ್ಟು ಭಾಗವೆಂದು ಇನ್ನೂ ಖಚಿತವಾಗಿಲ್ಲದಿದ್ದರೆ, website traffic AI agents ಗಳಿಂದ ಬರುತ್ತಿದೆಯೇ ಎಂದು ಹೇಗೆ ತಿಳಿಯುವುದು ಇಂದ ಪ್ರಾರಂಭಿಸಿ.

ಹೆಚ್ಚು ಉತ್ತಮವಾದ ವಿಧಾನವೆಂದರೆ agents ಗೆ ಸಂರಚಿತ ಮಾರ್ಗವನ್ನು ನೀಡುವುದು: programs ಗಾಗಿ ನಿರ್ಮಿತ formats ನಲ್ಲಿ content ಮತ್ತು actions, standard places ನಲ್ಲಿ discover ಆಗುವಂತೆ, ಮತ್ತು ತಮ್ಮನ್ನು ಸರಿಯಾಗಿ ಗುರುತಿಸುವ clients ಗಳಿಗೆ ಬಹುಮಾನ ನೀಡುವ limits ಜೊತೆಗೆ. ಈ guide ಎರಡನೇ application ನಿರ್ಮಿಸದೆ ಅದನ್ನು ಹೇಗೆ ಮಾಡುವುದು ಎಂದು ತೋರಿಸುತ್ತದೆ.

ಹಂತ 1: agents ಏನು ಮಾಡಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಿ

technology ಯಿಂದಲ್ಲ, intent ನಿಂದ ಪ್ರಾರಂಭಿಸಿ. ನೀವು ಈಗಾಗಲೇ agent traffic ಅನ್ನು ನೋಡುತ್ತಿರುವ routes ಗಳನ್ನು ನೋಡಿ ಮತ್ತು ಅವುಗಳನ್ನು ಗುಂಪುಮಾಡಿ:

• content ಓದುವುದು: documentation, product information, pricing pages, help articles, public profiles.
• data ಪ್ರಶ್ನಿಸುವುದು: search, catalog lookups, availability, status.
• actions ಕೈಗೊಳ್ಳುವುದು: ಬಳಕೆದಾರರ ಪರವಾಗಿ ಏನನ್ನಾದರೂ create, update ಅಥವಾ delete ಮಾಡುವುದು.

Reading ಮತ್ತು querying ಗಳು ಯಾವುದೇ well-behaved client ಗೆ ತೆರೆದಿರುವ structured path ಗಾಗಿ ಉತ್ತಮ candidates ಆಗಿವೆ. Actions ಗಳಿಗೆ client ತನ್ನನ್ನು ಹೇಗೆ ಗುರುತಿಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಲೆಕ್ಕಿಸದೇ authentication ಮತ್ತು authorization ಅಗತ್ಯ, ಮತ್ತು ಅವು sensitive actions ಅನ್ನು protect ಮಾಡುವ guide ನಲ್ಲಿ ಒಳಗೊಂಡಿವೆ.

ಹಂತ 2: machine-friendly formats ಒದಗಿಸಿ

content routes ಗಳಿಗಾಗಿ, page chrome ಇಲ್ಲದೆ ಅದೇ ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸಿ. ಎರಡು formats ಬಹುಪಾಲು ಅಗತ್ಯಗಳನ್ನು ಹೊರುತ್ತವೆ:

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

cache ಗಳು ಪ್ರತಿಯೊಂದು representation ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂಗ್ರಹಿಸುವಂತೆ ಮಾಡಲು Vary: Accept header (RFC 9110 on Vary) ಅನ್ನು ಕಳುಹಿಸಿ. ಹಲವಾರು 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: agents ನಿಮ್ಮ structured path ಅನ್ನು ಹೇಗೆ discover ಮಾಡುತ್ತಾರೆ?

agents ಗೆ ಕಂಡುಬರದದ್ದನ್ನು ಅವರು ಬಳಸಲಾಗದು. automated clients ಈಗಾಗಲೇ ಹುಡುಕುವ ಸ್ಥಳಗಳಲ್ಲಿ entry points ಗಳನ್ನು ಪ್ರಕಟಿಸಿ:

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 ಗಳಲ್ಲಿ Markdown ಅಥವಾ JSON versions ಗಳನ್ನು ಸೂಚಿಸುವ alternate links.
4. ನಿಮ್ಮ canonical content URLs ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುವ ಒಂದು sitemap, 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

automated clients ಗಾಗಿ ನಿಮ್ಮ rules ಗಳನ್ನು ವಿವರಿಸುವ ಒಂದು page ಅನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ: ಯಾವ routes open ಇವೆ, ಯಾವ limits ಅನ್ವಯಿಸುತ್ತವೆ, ಮತ್ತು ಉತ್ತಮ treatment ಪಡೆಯಲು signed requests ಮೂಲಕ client ತನ್ನನ್ನು ಹೇಗೆ ಗುರುತಿಸಿಕೊಳ್ಳಬಹುದು. ಸ್ಪಷ್ಟ rules ಗಳು ಊಹಾಪೋಹವನ್ನು ಸಹಕಾರವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತವೆ.

ಹಂತ 4: user agent string ಮೂಲಕ ಅಲ್ಲ, actor class ಮೂಲಕ route ಮಾಡಿ

ನೀವು structured responses ಗಳನ್ನು ಹೊಂದಿದ ನಂತರ, ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಅವುಗಳನ್ನು ಯಾರು ಪಡೆಯುತ್ತಾರೆ ಎಂದು ನಿರ್ಧರಿಸಿ. user agent strings ಗಳನ್ನು ad hoc ರೀತಿಯಲ್ಲಿ parse ಮಾಡುವ ಬದಲು, actor class ಮತ್ತು ಅದರ basis ಅನ್ನು ಬಳಸಿ. AI operators ಗಳು ತಮ್ಮ user agents ಗಳನ್ನು ಪ್ರಕಟಿಸುತ್ತಾರೆ, ಉದಾಹರಣೆಗೆ ತಮ್ಮ crawlers ಮತ್ತು fetchers ಗಳಿಗಾಗಿ 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");
}

ಎರಡು ತತ್ವಗಳು ಇದನ್ನು ಸುರಕ್ಷಿತವಾಗಿರಿಸುತ್ತವೆ:

• Explicit requests ಯಾವಾಗಲೂ ಗೆಲ್ಲುತ್ತವೆ. client Markdown ಅಥವಾ JSON ಅನ್ನು ಕೇಳಿದರೆ, class ಯಾವುದು ಇದ್ದರೂ ಅದನ್ನೇ serve ಮಾಡಿ.
• Defaults ಯಾವುದನ್ನೂ ಕಿತ್ತುಕೊಳ್ಳುವುದಿಲ್ಲ. Human ಅಥವಾ Unknown visitor ಗೆ ಯಾವಾಗಲೂ ಸಂಪೂರ್ಣ page ಸಿಗುತ್ತದೆ. agents ಗಾಗಿ structured default ಆಯ್ಕೆ ಮಾಡುವುದು format ಅನ್ನು ಬದಲಿಸುತ್ತದೆ, ಅವರಿಗೆ ನೋಡಲು ಅನುಮತಿಸಿರುವುದನ್ನು ಅಲ್ಲ.

ಹಂತ 5: AI agents ಗೆ ಯಾವ rate limits ಇರಬೇಕು?

Rate limits ಗಳಲ್ಲಿ actor context ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಾಗಿ ಫಲ ನೀಡುತ್ತದೆ. ಎಲ್ಲರಿಗೂ ಒಂದೇ limit ಬದಲು, class ಮತ್ತು basis ನ ಪ್ರತಿಯೊಂದು ಸಂಯೋಜನೆಗೂ ಸೂಕ್ತ 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;
}

ಸಂಖ್ಯೆಗಳು placeholder ಗಳು. ನೀವು ಗಮನಿಸಿದ 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 ಅನ್ನು bypass ಮಾಡುವ ಮಾರ್ಗವಲ್ಲ. data ಅನ್ನು ಬದಲಿಸುವ ಯಾವುದೇ action ಇನ್ನೂ ಇದನ್ನು ಅಗತ್ಯಪಡಿಸುತ್ತದೆ:

1. ನಿಮ್ಮ application ನೀಡಿದ credential ಮೂಲಕ authentication,
2. ಆ ನಿರ್ದಿಷ್ಟ action ಗಾಗಿ authorization, ಮತ್ತು
3. route ನ risk tier ಕೇಳುವ ಯಾವುದೇ ಹೆಚ್ಚುವರಿ checks.

ಒಂದು verified signature ಯಾವ client ಕರೆ ಮಾಡುತ್ತಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಅದು client ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರರ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು ಎಂದು ಹೇಳುವುದಿಲ್ಲ. ಆ ಪ್ರಶ್ನೆಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಟ್ಟುಕೊಳ್ಳಿ. signed AI agent requests ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ ಎಂಬ ನಮ್ಮ post ವ್ಯತ್ಯಾಸವನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಹಂತ 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 ಅನ್ನು version ಮಾಡಿ ಮತ್ತು ದಾಖಲೆಗೊಳಿಸಿ

structured path ಅನ್ನು public interface ಎಂದು ಪರಿಗಣಿಸಿ, ಏಕೆಂದರೆ agents ಅದರ ಮೇಲೆ ನಿರ್ಮಿಸುತ್ತವೆ. ಕೆಲವು ಅಭ್ಯಾಸಗಳು ಅದನ್ನು dependable ಆಗಿ ಇಡುತ್ತವೆ:

1. URLs ಗಳನ್ನು stable ಆಗಿ ಇಡಿ. 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 ಅನ್ನು support ಮಾಡಿ. 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 ಪ್ರಕಟಿಸಿ. well-behaved 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 ಗಳು ನಿಮ್ಮ own frontend ಮತ್ತು partner integrations ಗಳಿಗೂ ಉಪಯುಕ್ತ. stable, cacheable ಮತ್ತು documented ಆಗಿರುವ structured path ಯಾವುದೇ program ನಿಮ್ಮ application ಜೊತೆಗೆ ಕೆಲಸ ಮಾಡುವ ಅತಿ ಸುಲಭ ಮಾರ್ಗವಾಗುತ್ತದೆ.

ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು

• agents ಮತ್ತು ಜನರಿಗೆ ವಿಭಿನ್ನ facts ನೀಡುವುದು. structured version page ನಲ್ಲಿರುವ ಅದೇ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿರಬೇಕು. ವಿಭಿನ್ನ content ಬಳಕೆದಾರರು ನಿಮ್ಮ product ಬಗ್ಗೆ assistant ಗೆ ಕೇಳಿದಾಗ ಗೊಂದಲ ಉಂಟುಮಾಡುತ್ತದೆ.
• 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 ನಿಮಗೆ agents ಗಳನ್ನು structured content ಗೆ route ಮಾಡಲು ಮತ್ತು ನ್ಯಾಯಸಮ್ಮತ limits ಹೊಂದಿಸಲು ಅಗತ್ಯವಿರುವ actor class ಮತ್ತು basis ಅನ್ನು ನೀಡುತ್ತದೆ. ಇದು signed, declared ಮತ್ತು inferred agents ಗಳನ್ನು detect ಮಾಡುತ್ತದೆ, ಅವರು ನಿಮ್ಮ routes ಗಳನ್ನು ಹೇಗೆ ಬಳಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಮತ್ತು routing ನಿರ್ಧಾರವನ್ನು ನಿಮ್ಮ code ನಲ್ಲೇ ಬಿಡುತ್ತದೆ.

ನಿಮ್ಮ own application ಗಾಗಿ ನಮ್ಮ ತಂಡದೊಂದಿಗೆ structured path ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲು, early access ಗೆ apply ಮಾಡಿ. ವಿಶೇಷವಾಗಿ API ಮತ್ತು MCP scenarios ಗಾಗಿ, APIs ಮತ್ತು MCP Servers ನೋಡಿ, ಮತ್ತು who is calling your MCP server? ಅನ್ನು ಓದಿ, 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 ಸೇವೆ ನೀಡುವುದು
• 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 ಮತ್ತು Claude-SearchBot
• Model Context Protocol specification (2026-07-28): November 2026 ರ ವೇಳೆಗೆ current MCP revision