Una parte cada vez mayor de quienes leen tu documentación no son personas. Los asistentes de programación la consultan para responder «¿cómo integro X?»; los agentes de soporte leen artículos de ayuda para resolver las dudas de los usuarios; los agentes de investigación resumen registros de cambios para evaluar proveedores. Los servicios de alojamiento de documentación ya cuentan que una gran parte de su tráfico llega de agentes de IA y no de navegadores. Si tu contenido solo lo entiende una persona que recorre una página renderizada, eres invisible para un canal que decide cada vez más si tu producto se recomienda, se integra o se descarta.
Preparar el contenido para los agentes se reduce a tres capas: un índice que se pueda encontrar, un protocolo que una máquina pueda usar y un contenido lo bastante bien estructurado como para que valga la pena leerlo.
Capa 1: llms.txt, el índice que buscan los agentes
llms.txt es una convención inspirada en robots.txt: un archivo Markdown en la raíz de tu sitio (yourapp.com/llms.txt) que explica a los agentes basados en modelos de lenguaje qué es tu sitio y dónde está su contenido importante. Si robots.txt dice lo que los rastreadores no pueden hacer, llms.txt dice qué vale la pena leer: una breve descripción del producto y, después, una lista seleccionada de enlaces a las páginas clave, como las secciones de la documentación, la referencia de la API, el registro de cambios y los precios.
Un buen archivo cumple dos condiciones:
Seleccionado, no concatenado. El archivo es un mapa, no un volcado. Enlaza tus páginas canónicas de documentación; los agentes siguen los enlaces y leen las páginas por su cuenta. (Una convención complementaria,
llms-full.txt, es la variante con el contenido completo para los agentes que lo quieren todo en una sola petición. Es útil, pero lo primero que hay que hacer bien es el índice).Generado, no mantenido a mano. Igual que un sitemap, un llms.txt editado a mano se queda obsoleto. Genéralo desde la misma API de contenido que alimenta tus páginas, para que cada artículo publicado aparezca en el índice automáticamente. Si tu contenido vive en un backend de contenido, basta con una pequeña ruta en el servidor: obtener las listas e imprimir enlaces en Markdown.
Lo que cuesta: una tarde. Lo que ganas: los asistentes del IDE y los agentes de investigación que piden /llms.txt (y ya lo hacen hoy) reciben tu manera de presentar el producto en lugar de una suposición.
Capa 2: MCP, de legible a operable
El Model Context Protocol (MCP) es el estándar que se está imponiendo para conectar agentes de IA con sistemas externos en forma de herramientas. Si llms.txt hace que tu contenido se pueda encontrar, un servidor MCP hace que se pueda operar: un agente llama a search_entries con la pregunta de un usuario, a get_entry para obtener un artículo completo o lista tu registro de cambios. Son operaciones estructuradas que devuelven datos estructurados, sin tener que extraerlos del HTML.
En la práctica, esto cambia quién puede trabajar con tu contenido:
El agente de programación de un desarrollador consulta tu centro de ayuda y tu registro de cambios desde el editor mientras integra tu API.
El agente de redacción de un equipo escribe una entrada del registro de cambios, la guarda como borrador y deja que una persona la publique. Si el servidor ofrece herramientas de edición, las tareas de contenido se pueden delegar.
Tus propios agentes internos clasifican las publicaciones del tablero de comentarios o responden preguntas de soporte a partir del mismo contenido, sin integraciones a medida.
El sector de los CMS ha llegado aquí rápido: varias plataformas de contenido importantes lanzaron servidores MCP durante el último año, y empieza a ser un requisito más cuando se evalúa una plataforma. Kookee tiene uno: un servidor MCP sobre el contenido de un proyecto, al que cada miembro del equipo se conecta con un token personal, de solo lectura salvo que decida otra cosa. Incluye herramientas de lectura (listar, buscar, obtener) y de edición (crear, actualizar, publicar, categorizar, clasificar comentarios), así que las dos mitades del ciclo funcionan desde el primer momento: los agentes que leen tu contenido y los agentes que ayudan a producirlo. Uses la plataforma que uses, la pregunta para evaluarla es la misma: ¿puede un agente acceder a mi contenido mediante herramientas, con una autenticación limitada a la persona en cuyo nombre actúa?
Capa 3: contenido que merezca los tokens
Los índices y los protocolos llevan tu contenido hasta los agentes; la estructura decide qué pueden hacer con él. Los hábitos que ayudan a los agentes son, por suerte, los mismos que ya ayudaban a las personas y a los buscadores:
Una pregunta por artículo, y la respuesta primero. Los agentes recuperan fragmentos. Un artículo que empieza por la respuesta produce un fragmento útil; uno que la entierra bajo una introducción produce ruido.
Encabezados reales y URL estables. La recuperación y la cita dependen de secciones con dirección propia. Si un agente puede citar
yourapp.com/help/billing/refunds#timeline, el usuario puede comprobar su respuesta.Campos estructurados en lugar de convenciones en prosa. Una entrada del registro de cambios con una categoría tipada («Corrección») y un campo de versión se puede filtrar; la misma información metida en un párrafo obliga a analizar texto.
Texto, no capturas de texto. Las imágenes son opacas para la mayoría de los sistemas de recuperación. Usa la captura como ilustración, nunca como el único soporte de un paso.
Fechas honestas. La documentación desactualizada engaña a los agentes (y a sus usuarios) igual que a las personas, pero a escala. Las fechas en las entradas y un registro de cambios al día les dan la señal para preferir el contenido actual.
Un patrón propio de la era de los agentes: los artículos de contexto interno. Hay conocimiento (limitaciones conocidas, detalles de soluciones provisionales, matices de una migración) que quieres que use tu capa de soporte con IA sin publicarlo en el centro de ayuda que ve todo el mundo. Si tu backend de contenido admite artículos solo para la IA, que no aparecen en el centro de ayuda público, la IA responde con más detalle que tu documentación pública. Eso sí, esos artículos no son privados: el asistente los cita a cualquiera que pregunte.
Lo que ganas, en concreto
Preparar el contenido para agentes suena abstracto hasta que sigues un recorrido. Un desarrollador le pregunta a su asistente de programación «¿cómo pagino los resultados en {tu producto}?». El asistente pide /llms.txt, sigue el enlace a la documentación de la API, lee la sección de paginación y genera código que funciona, con una cita. Esa interacción ocurrió o con tu contenido o con una respuesta de Stack Overflow de hace dos años. Multiplícalo por cada decisión de integración, cada comparación de proveedores y cada pregunta de soporte que hoy pasa por un agente, y queda claro lo que está en juego.
Un orden práctico
Arregla primero la estructura: artículos que empiezan por la respuesta, encabezados, campos tipados. Mejora ya la documentación para las personas, y todo lo demás se apoya en ella.
Publica
/llms.txt, generado desde tu API de contenido.Añade o adopta un servidor MCP, el de tu plataforma de contenido si tiene uno.
Revisa los logs del servidor en busca de user agents de agentes de IA y de peticiones a llms.txt; deja que el tráfico real te diga dónde profundizar.
Ninguno de estos pasos es grande, y todos se refuerzan entre sí: el mismo contenido estructurado y servido por API que renderiza tus páginas y alimenta tu búsqueda es lo que hace que te entienda el público que más rápido crece entre los lectores de tu documentación.