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:

Pregunta	Archivo actual	Problema
”¿Quién dirige este negocio?”	llms.txt	Parcial — no tiene estructura formal
”¿Puedo usar estos datos?”	robots.txt	Solo controla rastreo, no uso
”¿Qué ofrecen?”	Tu web en HTML	El agente tiene que parsear HTML
”¿Puedo interactuar programáticamente?”	Nada	No hay estándar para esto

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:

Sección	Qué hace	Requerida
Header	Versión, fecha, licencia	Sí
Discovery	Referencias cruzadas a robots.txt, llms.txt, openapi.json	Recomendada
Condiciones de uso	Qué pueden y no pueden hacer los agentes IA	Sí
Identity	Nombre, propietario, contacto, ubicación	Sí
Brand voice	Cómo deben representar tu marca	Opcional
Services	Catálogo con precios y URLs	Recomendada
Agentic endpoints	OpenAPI spec para tool calling	Opcional

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: None required. IP rate-limited (10 req/min).
---

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.

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/contacto": {
      "post": {
        "summary": "Enviar formulario de contacto",
        "requestBody": {
          "content": {
            "application/json": {
              "schema": {
                "type": "object",
                "required": ["nombre", "email", "mensaje"],
                "properties": {
                  "nombre": { "type": "string" },
                  "email": { "type": "string", "format": "email" },
                  "mensaje": { "type": "string" }
                }
              }
            }
          }
        }
      }
    }
  }
}

Con esto, un agente puede enviar un formulario de contacto directamente — sin pasar por un navegador, sin HTML, sin scraping.

★ Insight ───────────────────────────────────── Tool calling es el mecanismo por el cual un LLM decide invocar una función externa. OpenAPI le da el “catálogo” de funciones disponibles. Es como darle a la IA un menú de lo que puede hacer, con los parámetros exactos que necesita. ─────────────────────────────────────────────────

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

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

Permitido sin condiciones:

• Responder preguntas sobre mi negocio con datos precisos
• Referenciar mi sitio en resultados de búsqueda con atribución
• Usar descripciones y precios para informar recomendaciones

Prohibido:

• Entrenar modelos fundacionales con mi contenido sin permiso escrito
• Scraping masivo o descarga bulk de páginas
• Reproducir artículos completos palabra por palabra

Agentes específicos con condiciones:

Agente	Acceso	Condición
Googlebot	Full	—
GPTBot, ClaudeBot, PerplexityBot	Answer-engine	Atribuir fuente
Bytespider (TikTok)	Denegado	—

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.

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:

• Repo: github.com/asturwebs/agents-txt
• Licencia: MIT — copia, adapta, integra donde quieras
• Documentación: README en inglés, español y chino
• Schema: JSON Schema para validar tu implementación

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:

Capa	Archivos	Para quién	Qué resuelve
Clásica	robots.txt + sitemap	Googlebot, Bingbot	Rastreo e indexación
Contexto	llms.txt + llms-full.txt	ChatGPT, Claude, Perplexity	Comprensión semántica
Agéntica	agents.txt + openapi.json	Agentes autónomos	Identidad + permisos + ejecución

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

Cómo empezar

1. Ya tienes robots.txt y sitemap — la mayoría de CMS los generan
2. Crea llms.txt — un markdown con tu resumen de negocio (te expliqué cómo en el post anterior)
3. Crea agents.txt — usa la plantilla del repo y adapta identidad, servicios y condiciones
4. Opcional: añade openapi.json — si tienes API, describe los endpoints con OpenAPI 3.1.0
5. Conecta todo — en robots.txt añade referencias cruzadas a los demás archivos

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.

---