ਤੁਹਾਡੇ app ਵਿਚੋਂ AI agents ਲਈ ਇਕ ਸੰਰਚਿਤ ਰਸਤਾ ਕਿਵੇਂ ਦਿੱਤਾ ਜਾਵੇ

AI agents ਨੂੰ ਤੁਹਾਡੇ app ਵਿਚੋਂ ਵੱਖਰਾ ਰਸਤਾ ਕਿਉਂ ਚਾਹੀਦਾ ਹੈ?

ਤੁਹਾਡੀ application ਲਈ ਆਉਣ ਵਾਲੀਆਂ requests ਦਾ ਵਧਦਾ ਹਿੱਸਾ AI agents ਤੋਂ ਆਉਂਦਾ ਹੈ: assistants ਜੋ user ਲਈ documentation fetch ਕਰਦੇ ਹਨ, research tools ਜੋ product pages ਪੜ੍ਹਦੇ ਹਨ, autonomous workflows ਜੋ ਤੁਹਾਡੀ API ਨੂੰ call ਕਰਦੇ ਹਨ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਬਹੁਤੇ ਉਹਨਾਂ interfaces ਰਾਹੀਂ ਕੰਮ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ ਜੋ ਲੋਕਾਂ ਲਈ ਬਣਾਏ ਗਏ ਸਨ। ਉਹ ਪੂਰੇ HTML pages download ਕਰਦੇ ਹਨ, layouts parse ਕਰਦੇ ਹਨ, mouse ਲਈ ਬਣੀ navigation follow ਕਰਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਕੋਈ script-heavy page ਉਮੀਦ ਮੁਤਾਬਕ render ਨਹੀਂ ਹੁੰਦੀ ਤਾਂ retry ਕਰਦੇ ਹਨ।

ਇਹ ਹਰ ਕਿਸੇ ਲਈ inefficient ਹੈ। Agents noisy content ਲੈਂਦੇ ਹਨ ਅਤੇ ਗਲਤੀਆਂ ਕਰਦੇ ਹਨ। ਤੁਹਾਡੇ servers ਉਹ pages render ਕਰਨ ਵਿੱਚ resources ਖਰਚ ਕਰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕੋਈ ਦੇਖਦਾ ਹੀ ਨਹੀਂ। ਅਤੇ traffic ਨੂੰ ਸਮਝਣਾ ਔਖਾ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ browser ਵਾਂਗ ਦਿਖਦਾ ਹੈ ਜੋ ਅਜੀਬ ਵਰਤਾਓ ਕਰ ਰਿਹਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਹਾਲੇ ਇਹ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਤੁਹਾਡੀ traffic ਦਾ ਕਿੰਨਾ ਹਿੱਸਾ ਇਹ ਹੈ, ਤਾਂ how to tell if website traffic comes from AI agents ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।

ਇੱਕ ਵਧੀਆ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ agents ਨੂੰ ਇਕ ਸੰਰਚਿਤ ਰਸਤਾ ਦਿੱਤਾ ਜਾਵੇ: programs ਲਈ ਬਣੇ formats ਵਿਚ content ਅਤੇ actions, standard ਥਾਵਾਂ 'ਤੇ discoverable, ਅਤੇ ਅਜਿਹੀਆਂ limits ਜਿਨ੍ਹਾਂ ਨਾਲ ਉਹ clients ਇਨਾਮਿਤ ਹੁੰਦੇ ਹਨ ਜੋ ਆਪਣੇ ਆਪ ਨੂੰ ਠੀਕ ਤਰੀਕੇ ਨਾਲ identify ਕਰਦੇ ਹਨ। ਇਹ guide ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਦੂਜੀ application ਬਣਾਏ ਬਿਨਾਂ ਇਹ ਕਿਵੇਂ ਕਰਨਾ ਹੈ।

Step 1: Decide what agents should be able to do

Technology ਨਹੀਂ, intent ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਉਹ routes ਦੇਖੋ ਜਿੱਥੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ agent traffic ਵੇਖ ਰਹੇ ਹੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ group ਕਰੋ:

• 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 ਲਈ open ਹੈ। Actions ਲਈ authentication ਅਤੇ authorization ਲੋੜੀਂਦੇ ਹਨ, ਭਾਵੇਂ client ਆਪਣੇ ਆਪ ਨੂੰ ਕਿਵੇਂ ਵੀ identify ਕਰੇ, ਅਤੇ ਇਹ sensitive actions ਨੂੰ protect ਕਰਨ ਵਾਲੀ guide ਵਿੱਚ covered ਹਨ।

Step 2: Machine-friendly formats ਦਿਓ

Content routes ਲਈ, page chrome ਤੋਂ ਬਿਨਾਂ ਉਹੀ ਜਾਣਕਾਰੀ ਦਿਓ। ਦੋ formats ਜ਼ਿਆਦਾਤਰ ਲੋੜਾਂ ਨੂੰ cover ਕਰਦੇ ਹਨ:

• Markdown prose content ਲਈ, ਜਿਵੇਂ documentation ਅਤੇ articles, ਜੋ text/markdown media type ਨਾਲ serve ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ RFC 7763 ਵਿੱਚ registered ਹੈ। ਇਹ 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 ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ।

Step 3: Agents ਤੁਹਾਡਾ structured path ਕਿਵੇਂ discover ਕਰਦੇ ਹਨ?

Agents ਉਹ ਨਹੀਂ ਵਰਤ ਸਕਦੇ ਜੋ ਉਹ ਲੱਭ ਨਹੀਂ ਸਕਦੇ। Entry points ਉਹਨਾਂ ਥਾਵਾਂ 'ਤੇ publish ਕਰੋ ਜਿੱਥੇ automated clients ਪਹਿਲਾਂ ਹੀ ਦੇਖਦੇ ਹਨ:

1. /llms.txt site root 'ਤੇ: ਤੁਹਾਡੀ site ਕੀ offer ਕਰਦੀ ਹੈ, ਇਸਦਾ ਇੱਕ ਛੋਟਾ Markdown summary, ਸਭ ਤੋਂ useful pages ਅਤੇ ਉਹਨਾਂ ਦੇ structured versions ਦੇ links ਨਾਲ, llms.txt proposal ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹੋਏ.
2. ਇੱਕ API description ਜਿਵੇਂ OpenAPI document, ਜੋ ਤੁਹਾਡੀ developer documentation ਅਤੇ /llms.txt ਤੋਂ link ਹੋਵੇ.
3. Alternate links HTML pages ਵਿੱਚ, ਜੋ Markdown ਜਾਂ JSON versions ਵੱਲ point ਕਰਦੇ ਹੋਣ.
4. ਇੱਕ sitemap ਜੋ ਤੁਹਾਡੇ canonical content URLs list ਕਰਦਾ ਹੋਵੇ, Sitemaps protocol ਵੱਲੋਂ define ਕੀਤੇ format ਵਿੱਚ.

ਇੱਕ 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 open ਹਨ, ਕਿਹੜੀਆਂ limits ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ signed requests ਨਾਲ ਕੋਈ client ਆਪਣੇ ਆਪ ਨੂੰ ਕਿਵੇਂ identify ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਜੋ ਉਸਨੂੰ ਵਧੀਆ treatment ਮਿਲੇ। ਸਪੱਸ਼ਟ rules ਅਨੁਮਾਨ ਨੂੰ cooperation ਵਿੱਚ ਬਦਲਦੇ ਹਨ।

Step 4: User agent string ਦੀ ਥਾਂ actor class ਮੁਤਾਬਕ route ਕਰੋ

ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ structured responses ਆ ਜਾਂਦੀਆਂ ਹਨ, ਤੈਅ ਕਰੋ ਕਿ default ਰੂਪ ਵਿੱਚ ਉਹ ਕਿਨ੍ਹਾਂ ਨੂੰ ਮਿਲਣਗੀਆਂ। Ad hoc user agent strings parse ਕਰਨ ਦੀ ਥਾਂ actor class ਅਤੇ ਉਸਦੀ basis ਵਰਤੋ। AI operators ਆਪਣੇ user agents publish ਕਰਦੇ ਹਨ, ਜਿਵੇਂ 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");
}

ਦੋ principles ਇਸ ਨੂੰ safe ਰੱਖਦੇ ਹਨ:

• Explicit requests ਹਮੇਸ਼ਾਂ ਜਿੱਤਦੇ ਹਨ। ਜੇ client Markdown ਜਾਂ JSON ਮੰਗਦਾ ਹੈ, ਤਾਂ ਉਹੀ serve ਕਰੋ, class ਭਾਵੇਂ ਜੋ ਮਰਜ਼ੀ ਹੋਵੇ.
• Defaults ਕਦੇ ਕੁਝ ਨਹੀਂ ਘਟਾਉਂਦੇ। Human ਜਾਂ Unknown visitor ਨੂੰ ਹਮੇਸ਼ਾਂ ਪੂਰਾ page ਮਿਲਦਾ ਹੈ। Agents ਲਈ structured default ਚੁਣਨ ਨਾਲ format ਬਦਲਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਉਹ ਕੀ ਦੇਖ ਸਕਦੇ ਹਨ.

Step 5: AI agents ਨੂੰ ਕਿਹੜੇ rate limits ਮਿਲਣੇ ਚਾਹੀਦੇ ਹਨ?

Rate limits ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ actor context ਸਭ ਤੋਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਲਾਭ ਦਿੰਦਾ ਹੈ। ਸਾਰਿਆਂ ਲਈ ਇੱਕ limit ਦੀ ਥਾਂ, class ਅਤੇ basis ਦੇ ਹਰ combination ਲਈ ਇੱਕ ਢੁੱਕਵਾਂ budget ਦਿਓ:

Limit ਨੂੰ ਸਭ ਤੋਂ stable 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;
}

Numbers placeholders ਹਨ। ਆਪਣਾ baseline ਜੋ ਤੁਸੀਂ observe ਕੀਤਾ ਹੈ, ਉਸ ਤੋਂ set ਕਰੋ। ਜਦੋਂ client limit ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ, ਤਾਂ 429 Too Many Requests ਨਾਲ ਇੱਕ Retry-After header ਅਤੇ ਤੁਹਾਡੇ automated access page ਲਈ link return ਕਰੋ। ਚੰਗੇ agents back off ਕਰਦੇ ਹਨ ਅਤੇ ਇਸਨੂੰ ਪੜ੍ਹਦੇ ਹਨ।

Step 6: Actions ਨੂੰ authorization ਦੇ ਪਿੱਛੇ ਰੱਖੋ

ਪੜ੍ਹਨ ਲਈ structured path, ਤੁਹਾਡੇ security model ਦੇ ਆਲੇ ਦੁਆਲੇ ਦਾ ਰਸਤਾ ਨਹੀਂ ਹੈ। ਕੋਈ ਵੀ action ਜੋ data ਬਦਲਦੀ ਹੈ, ਫਿਰ ਵੀ ਇਹ ਲੋੜੀਂਦਾ ਹੈ:

1. ਤੁਹਾਡੀ application ਵੱਲੋਂ issue ਕੀਤੇ credential ਨਾਲ authentication,
2. ਉਸ ਖਾਸ action ਲਈ authorization, ਅਤੇ
3. route ਦੇ risk tier ਵੱਲੋਂ ਮੰਗੀਆਂ ਹੋਰ ਕੋਈ ਵਾਧੂ checks.

ਇੱਕ verified signature ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜਾ client call ਕਰ ਰਿਹਾ ਹੈ। ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ client ਕਿਸੇ ਦਿੱਤੇ user ਲਈ act ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਇਨ੍ਹਾਂ ਸਵਾਲਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ। what signed AI agent requests prove ਬਾਰੇ ਸਾਡੀ post ਫਰਕ ਸਮਝਾਉਂਦੀ ਹੈ।

Step 7: ਪ੍ਰਭਾਵ ਨੂੰ ਮਾਪੋ

Structured path ਨੂੰ ਪਹਿਲਾਂ observation mode ਵਿੱਚ ਚਲਾਓ, ਫਿਰ compare ਕਰੋ:

• agent requests ਦਾ ਉਹ ਹਿੱਸਾ ਜੋ structured formats ਵਰਤਦਾ ਹੈ,
• agent traffic ਲਈ server cost ਅਤੇ latency, ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ,
• agent clients ਲਈ error ਅਤੇ retry rates,
• ਕਿੰਨੇ automated clients declared ਤੋਂ verified ਵੱਲ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੀ signing guidance publish ਕਰਦੇ ਹੋ.

ਇਹ numbers ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ structured path ਆਪਣਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਇਸਨੂੰ ਅੱਗੇ ਕਿੱਥੇ ਵਧਾਉਣਾ ਹੈ।

Step 8: Structured path ਨੂੰ version ਅਤੇ document ਕਰੋ

Structured path ਨੂੰ ਇੱਕ public interface ਵਾਂਗ treat ਕਰੋ, ਕਿਉਂਕਿ agents ਇਸ ਦੇ ਉੱਤੇ build ਕਰਨਗੇ। ਕੁਝ habits ਇਸਨੂੰ dependable ਬਣਾਉਂਦੀਆਂ ਹਨ:

1. URLs stable ਰੱਖੋ। ਜੇ ਕਿਸੇ agent ਨੇ ਸਿੱਖ ਲਿਆ ਕਿ /docs/getting-started.md ਮੌਜੂਦ ਹੈ, ਤਾਂ ਉਹ ਕੰਮ ਕਰਦੀ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ। ਜਦੋਂ content move ਹੋਵੇ, ਤਾਂ ਨਵੇਂ location ਵੱਲ ਇੱਕ 301 return ਕਰੋ, ਨਾ ਕਿ ਇੱਕ 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 publish ਕਰੋ। ਚੰਗੇ behavior ਵਾਲੇ agents ਦੇ operators ਇਸਨੂੰ ਪੜ੍ਹਦੇ ਹਨ, ਅਤੇ ਇਹ ਤੁਹਾਨੂੰ ਨਵੇਂ structured routes announce ਕਰਨ ਲਈ ਥਾਂ ਦਿੰਦਾ ਹੈ.

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 ਜੋ stable, cacheable ਅਤੇ documented ਹੋਵੇ, ਜਲਦੀ ਹੀ ਕਿਸੇ ਵੀ program ਲਈ ਤੁਹਾਡੀ application ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਬਣ ਜਾਂਦਾ ਹੈ।

Common pitfalls

• Agents ਅਤੇ people ਨੂੰ ਵੱਖਰੇ facts ਦੇਣਾ। Structured version ਵਿੱਚ page ਵਾਲੀ ਹੀ ਜਾਣਕਾਰੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। Divergent content ਉਹਨਾਂ users ਨੂੰ confuse ਕਰਦੀ ਹੈ ਜੋ ਆਪਣੇ 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 set ਕਰਨ ਲਈ ਲੋੜ ਹੈ। ਇਹ signed, declared ਅਤੇ inferred agents ਨੂੰ detect ਕਰਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਤੁਹਾਡੇ routes ਨੂੰ ਕਿਵੇਂ ਵਰਤਦੇ ਹਨ, ਅਤੇ routing decision ਤੁਹਾਡੇ code ਵਿੱਚ ਛੱਡ ਦਿੰਦਾ ਹੈ।

ਸਾਡੀ team ਨਾਲ ਆਪਣੀ application ਲਈ structured path design ਕਰਨ ਲਈ, apply for 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) and Retry-After (Section 10.2.3)
• RFC 7763: The text/markdown Media Type: serving Markdown representations
• RFC 8288: Web Linking: typed alternate links
• RFC 6585: Additional HTTP Status Codes, Section 4: 429 Too Many Requests
• llms.txt proposal: the /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): the current MCP revision as of November 2026