agents.txt: el estándar que creé para que la IA sepa quién eres y qué puede hacer

Hace una semana, un agente IA visitó mi web y no supo qué hacer con ella. Encontró el robots.txt (sabía qué rastrear), el llms.txt (sabía quién soy), pero cuando quiso hacer algo — preguntar por un servicio, consultar precios, contactar — no encontró nada.

Así nació agents.txt.

Este es el tercer post de la serie. En el primero te conté cómo robots.txt y sitemap son la base para Google. En el segundo te expliqué llms.txt para que los LLMs te entiendan. Ahora vamos al siguiente nivel: un estándar que dice a la IA quién eres, qué ofreces, y qué puede hacer con ello.

El problema que agents.txt resuelve

Cuando un agente IA autónomo (no un chatbot, sino un sistema que actúa por su cuenta) llega a tu web, necesita responder cuatro preguntas:

Ningún estándar existente cubre las cuatro. Yo necesitaba uno. Así que lo creé.

Qué es agents.txt v2.0

agents.txt es un archivo markdown con bloques YAML embebido que se coloca en la raíz de tu web (/agents.txt). Tiene seis secciones:

Ejemplo real (mi agents.txt)

# agents.txt — asturwebs.es
# Version: 2.0
# Updated: 2026-05-12
# License: MIT

## Identity

---yaml
identity:
  name: AsturWebs
  owner: Pedro Luis Cuevas Villarrubia
  website: https://asturwebs.es
  email: pedro@asturwebs.es
  since: 1999
  location: Villaviciosa, Asturias, España
---

## Condiciones de uso

| Agent | Owner | Allowed usage | Conditions |
|-------|-------|---------------|------------|
| Googlebot | Google | Full indexing | — |
| GPTBot | OpenAI | Answer-engine only | Attribute source |
| Bytespider | ByteDance | Denied | — |

## Agentic Endpoints

---yaml
api_schema:
  type: openapi
  version: 3.1.0
  url: https://asturwebs.es/openapi.json
  auth_requirements: API Key required for mutations (POST). Read-only endpoints (GET) are public.
---

Un agente IA que lea esto sabe exactamente quién soy, qué me permite hacer, qué servicios tengo y cómo puede interactuar con mi API.

OpenAPI 3.1.0 para tool calling nativo

La sección api_schema es la que hace la diferencia. Apunta a un archivo openapi.json que describe tu API en formato OpenAPI 3.1.0. También acepta MCP (Model Context Protocol) como alternativa — el estándar de Anthropic para descubrimiento dinámico de herramientas.

Frameworks como LangChain, AutoGen, Claude Code, Copilot pueden consumir esta spec directamente y generar herramientas (tools) para interactuar con tu web:

{
  "openapi": "3.1.0",
  "info": {
    "title": "AsturWebs API",
    "version": "2.3.0"
  },
  "paths": {
    "/api/servicios": {
      "get": {
        "summary": "Listar servicios disponibles",
        "responses": {
          "200": {
            "description": "Lista de servicios con precios y descripciones"
          }
        }
      }
    },
    "/api/contacto": {
      "post": {
        "summary": "Enviar formulario de contacto",
        "security": [{ "apiKey": [] }],
        "requestBody": {
          "content": {
            "application/json": {
              "schema": {
                "type": "object",
                "required": ["nombre", "email", "mensaje"],
                "properties": {
                  "nombre": { "type": "string" },
                  "email": { "type": "string", "format": "email" },
                  "mensaje": { "type": "string" }
                }
              }
            }
          }
        }
      }
    }
  },
  "components": {
    "securitySchemes": {
      "apiKey": {
        "type": "apiKey",
        "in": "header",
        "name": "X-API-Key"
      }
    }
  }
}

Con esto, un agente puede consultar servicios libremente (GET /api/servicios, público) y enviar formularios si tiene API key (POST /api/contacto, autenticado). Los endpoints de solo lectura se exponen sin autenticación; las mutaciones requieren autenticación — un agente legítimo obtiene su key vía el mecanismo que definas (OAuth, email verification, etc.).

Condiciones de uso: lo que la IA sí y no puede hacer

Esta sección es clave. Define reglas explícitas:

Agentes específicos con condiciones:

La diferencia entre RAG (usar tu contenido para responder preguntas) y training (usarlo para entrenar un modelo fundacional) es crucial. En mi agents.txt, RAG está permitido por defecto (rag: true) pero el entrenamiento está prohibido (training: false). Cada agente puede tener sus propias reglas.

Es un contrato social — no tiene fuerza legal, pero establece expectativas claras. Y los principales proveedores de IA están empezando a respetar estos formatos.

Cómo lo implementé: Single Source of Truth

No mantengo tres versiones de los mismos datos. Todo sale de un archivo:

src/api/lib/business-data.ts  ← SSOT (identidad, servicios, precios, voz)
           │
           ├──→ scripts/generate-manifests.ts
           │       ├── public/agents.txt     (markdown + YAML)
           │       ├── public/openapi.json   (OpenAPI 3.1.0)
           │       └── public/llms.txt       (resumen markdown)
           │
           ├──→ src/api/lib/ai.ts            (system prompt del chatbot)
           │
           └──→ src/api/routes/agents.ts     (API JSON /api/agents)

Si cambio un precio en business-data.ts, se actualiza en el chatbot, en la API, en agents.txt, en llms.txt y en openapi.json. Un cambio, seis salidas.

De agents.txt a chatbot: datos que trabajan solos

El SSOT no solo alimenta archivos estáticos. Mi chatbot (BytIA) construye su system prompt directamente desde business-data.ts — los mismos datos que generan agents.txt, openapi.json y llms.txt.

El truco es separar comportamiento de datos:

Mensaje 1 (system):  "Eres BytIA, la IA asistente de AsturWebs..."
                     → Comportamiento, personalidad, seguridad, cierre

Mensaje 2 (system):  "## Servicios\n- Diseño web: 600-900€..."
                     → Datos de negocio (lo que agents.txt ya tiene)

Mensaje 3 (system):  "El usuario está en /servicios/seo/"
                     → Contexto de página (auto-detectado por el widget)

¿Por qué separarlos? Porque el comportamiento rara vez cambia, pero los precios, servicios y horarios sí. Si actualizo un precio en business-data.ts, el chatbot lo refleja al instante — sin tocar el prompt, sin riesgo de inconsistencias.

Esto mismo lo puedes hacer con cualquier chatbot: usa los datos de tu agents.txt como contexto de negocio y manten las instrucciones de comportamiento aparte. Si mañana añades un servicio o cambias un precio, el cambio se propaga a tu web, a la IA que lee tu site, y al chatbot que atiende a tus visitantes. Un cambio, todas las salidas.

El repo público: un estándar abierto

No quería que esto fuera solo para mi web. Así que creé un repositorio público:

La idea es simple: si robots.txt es para crawlers y llms.txt es para LLMs, agents.txt es para agentes autónomos. Y debería ser un estándar de la comunidad, no propiedad de nadie.

Las tres capas juntas

Para que tu web esté preparada para 2026 y más allá, necesitas las tres capas:

Si te fijas, cada capa añade capacidad sin reemplazar la anterior. No eliminas robots.txt porque tengas agents.txt. Los tres coexisten.

Un ecosistema en crecimiento

agents.txt no está solo. Hay media docena de estándares emergentes que cubren distintas capas de la interacción IA-web:

La IETF tiene 11 borradores compitiendo en este espacio y ninguno ha logrado adopción. Los estándares se imponen por uso real, no por comités. Por eso agents.txt está en producción desde el día uno.

Cómo empezar

El estándar es nuevo, la adopción está creciendo, y las herramientas de IA están empezando a usarlo. Es el momento de estar preparado.

---