La capa de protocolo de la web agente se está dividiendo en dos apuestas, y la mayoría de webs ya han hecho una de ellas sin saberlo. La primera apuesta es sobre la identidad: un archivo llamado llms.txt que le dice a los modelos de IA quién es usted y qué cubre su contenido. El segundo tiene que ver con la capacidad: un navegador estándar llamado WebMCP que le dice a un agente lo que realmente puede hacer en su sitio web una vez que llega. Parecen la misma idea. Responden a preguntas opuestas. Y la diferencia decide dónde debe dirigirse su esfuerzo durante el próximo año, porque una de estas apuestas se activa de forma predeterminada, mientras que la otra, la que realmente permite que un agente termine una tarea, requiere un trabajo deliberado.
2 archivos, 2 preguntas
Un agente que llega a su sitio web tiene dos cosas que quizás quiera saber. La primera es qué es este lugar y qué cubre. La segunda es, ahora que está aquí, cómo completa la tarea que le envió el usuario. Identidad, luego capacidad. La web agente está creando una respuesta separada para cada uno, y las dos respuestas provienen de dos archivos diferentes respaldados por dos campos diferentes.
La respuesta de identidad es llms.txt, un archivo de texto sin formato que publica en la raíz de su dominio. Es un mapa curado: aquí está quién soy, aquí están mis páginas más importantes, aquí está de qué trata cada una. La respuesta de capacidad es WebMCP, un estándar de navegador que permite que su sitio web exponga herramientas invocables a un agente, de modo que el agente pueda buscar, filtrar, fijar precios o reservar invocando una función en lugar de adivinar su interfaz.
Llms.txt y WebMCP se agrupan como dos versiones de la misma cosa: la preparación del agente. Responden a dos preguntas diferentes. La identidad es un folleto. La capacidad es la caja registradora. Y ahora mismo la industria está empujando a todos los sitios web hacia el folleto, la apuesta con la evidencia más débil detrás, mientras que la caja registradora, la apuesta que realmente hace avanzar una transacción, se deja en manos de los pocos equipos dispuestos a construirla.
La apuesta de la identidad: LLMs.txt
Llms.txt es un archivo de rebajas que se encuentra en yourdomain.com/llms.txt. Fue propuesto por Jeremy Howard, cofundador de Answer.AI, el 3 de septiembre de 2024, como una forma de entregar a los modelos de lenguaje un índice limpio y curado por humanos de su contenido en lugar de obligarlos a rastrearlo y reconstruirlo a partir de HTML repleto de navegación, anuncios y scripts. El tono es razonable a primera vista. Los modelos funcionan mejor con estructura, así que dales estructura.
El problema es que la evidencia de que hace algo es escasa. En respuesta a personas en Reddit en junio de 2026, John Mueller de Google llamó a llms.txt “puramente especulativo por ahora (el archivo existe desde hace años, pero ninguno de los sistemas de inteligencia artificial lo usa)” (informado por Search Engine Journal). Ese es un defensor de la Búsqueda de Google que dice la parte tranquila en voz alta. Un expediente que existe desde hace más de un año. Un archivo que ningún sistema de inteligencia artificial importante ha confirmado que lee. Un archivo que le pide que mantenga sincronizada una segunda copia de su propio contenido.
Incluso con pruebas tan escasas, llms.txt está activado para los sitios web de forma predeterminada. AIOSEO, un complemento utilizado en más de 3 millones de sitios web de WordPress, genera un llms.txt de forma predeterminada. Un gran número de propietarios de sitios web publican ahora un llms.txt que nunca decidieron publicar, describiendo su sitio web en un archivo que nunca han leído.
Para ser claros, no estoy en contra del expediente. Un llms.txt bien mantenido es un excelente índice de contenido. El problema es el predeterminado. La apuesta por la identidad está ganando en adopción, no porque funcione, sino porque la casilla de verificación del complemento se envió activada. Un archivo que usted no escribió, que ningún sistema de inteligencia artificial ha confirmado que lee, que se desincroniza con el sitio web que dice describir en el momento en que olvida que existe, es algo extraño que está en el centro de la estrategia de un agente. Pero ahí es donde ahora se ubican muchos sitios web, por defecto y no por elección.
La apuesta por la capacidad: WebMCP
WebMCP, abreviatura de Web Model Context Protocol, es un estándar de navegador que permite que su sitio web registre herramientas invocables que un agente puede invocar a través de un navigator.modelContext API. Parte de una pregunta diferente a la del expediente de identidad: no quién es usted, sino, dado que ya hay un agente en su sitio web, cómo realiza correctamente la tarea que vino a realizar. Así es como Mueller formuló sus propias preferencias en la misma conversación. Dijo que le gusta el enfoque WebMCP y las integraciones comerciales porque «tienen objetivos y procesos claros».
En lugar de que un agente tome una captura de pantalla de su página y adivine dónde hacer clic, su sitio web se lo dice directamente: aquí están las acciones que apoyo, aquí están los aportes que cada uno necesita, esto es lo que obtiene a cambio. El control se invierte. El sitio web declara sus capacidades en lugar de obligar al agente a aplicarles ingeniería inversa.
El estándar está siendo escrito a través del grupo comunitario de aprendizaje automático web del W3C por ingenieros de Google y Microsoft, y se publicó como borrador el 10 de febrero de 2026. Ahora se encuentra en una prueba de origen público que se ejecuta desde Chrome 149 hasta Chrome 156. Una prueba de origen es cómo Chrome permite que un sitio web active una función experimental para sus visitantes reales durante una ventana limitada, registrándose para obtener un token, en lugar de ocultarlo detrás de una bandera de solo desarrollador. Por lo tanto, ahora puede ejecutar herramientas WebMCP en tráfico en vivo, no solo en su propia máquina. El agente que consume esas herramientas en Chrome hoy es Gemini.
WebMCP es la apuesta más fuerte porque tiene un trabajo claro. Un archivo de identidad te describe y espera que alguien lo lea. Se invoca una herramienta de capacidad, devuelve datos estructurados y acerca una tarea a su finalización. El folleto espera ser leído. Suena la caja registradora.
Por qué las dos apuestas no son intercambiables
La forma más limpia de mantener la diferencia es a través de las dos limitaciones de diseño a las que sigo volviendo en Machine-First Architecture: identidad e interacción. La identidad es hacer que su marca y su contenido sean inequívocamente legibles por máquina. La interacción es permitir que un agente complete una acción con un resultado predecible. Llms.txt es un juego de palabras con la capa de identidad. WebMCP es un juego en la capa de interacción. Son herramientas para dos trabajos diferentes y un sitio web puede necesitar ambos, uno o ninguno, dependiendo de lo que quiera que hagan los agentes.
Esto es más importante ahora que los agentes no son un error de redondeo en su tráfico. El director ejecutivo de Cloudflare, Matthew Prince, dijo en junio de 2026 que el tráfico automatizado había superado al tráfico humano por primera vez, con un 57,3% de las solicitudes a páginas web frente a un 42,7% de personas, un cruce que había proyectado en SXSW no llegaría hasta 2027. Cuando la mayoría de las solicitudes que llegan a su sitio web son máquinas que actúan para las personas, si el agente sabía quién es usted deja de ser la pregunta interesante. Si el agente realmente pudo hacer lo que le pidió su cliente se convierte en todo el juego. La identidad sin capacidad es una máquina que lee su letrero y luego se para ante una puerta que no puede abrir.
Ésa es la inversión que hace la adopción por defecto. El archivo que se activa para todos responde a la pregunta que menos importa una vez que llega el agente. El estándar que responde a la pregunta más importante es el que casi nadie ha activado.
Hice ambas apuestas en mi propio sitio web, deliberadamente
Utilizo ambos en No Hacks, y el contraste entre cuánto cuesta colocar cada uno es todo el argumento en miniatura.
Para la identidad, mantengo un llms.txt y lo genero a partir del propio contenido del sitio web cada vez que lo actualizo, en lugar de dejar un complemento para escribir uno que nunca leo. Esa es la parte deliberada. Debido a que lo reconstruyo cada vez que cambia el sitio, se mantiene en sintonía con lo que realmente hay aquí, y si un sistema de inteligencia artificial alguna vez comienza a leer llms.txt, el mío estará listo cuando llegue ese día. No apuesto por eso. Lo mantengo actualizado y barato y no lo confundo con una estrategia.
Para mayor capacidad, implementé WebMCP. Cuando un navegador compatible con WebMCP carga el sitio web, registra cuatro herramientas invocables a través de navigator.modelContext. Dos cubren el glosario: uno enumera cada término para que un agente pueda descubrir qué está definido y el otro devuelve la definición canónica de un término con su enlace de origen. Dos cubren mi panorama actual de navegadores agentes y productos de agentes: uno enumera cada producto rastreado por categoría y el otro devuelve todos los detalles de un solo producto por nombre. Un agente no tiene que rastrear mis páginas para responder a qué me refiero con la apuesta de capacidad o qué navegadores agentes sigo. Llama a una herramienta y obtiene una respuesta clara y estructurada.
El detalle que más importa es desde dónde leen las herramientas. Cada uno se basa en los mismos datos que impulsan la página orientada a humanos. Las herramientas del glosario leen el glosario. Las herramientas de productos leen la lista de productos. De modo que la respuesta del agente y la respuesta humana nunca pueden estar en desacuerdo, porque una fuente alimenta a ambas. Esa es la diferencia entre exponer una capacidad y mantener una descripción separada de uno mismo, y es por eso que la apuesta de capacidad, construida de esta manera, no tiene una copia separada para mantener sincronizada.
Entonces tengo ambos archivos. Uno tomó una tarde y hace un trabajo real. El otro lo regenero a partir de mi propio contenido y lo trato como una cobertura, no como un plan.
Qué significa esto para su sitio web
Primero, averigüe lo que ya ha publicado. Abierto yourdomain.com/llms.txt en un navegador. Si algo se carga, su pila lo coloca allí, posiblemente un complemento predeterminado que nunca configuró. Léelo. Pregunte si realmente describe su sitio web, porque si un sistema de inteligencia artificial alguna vez comienza a leer llms.txt, uno inexacto es peor que ninguno. Esto cuesta cinco minutos y la mayoría de los propietarios de sitios web nunca lo han hecho. Si desea conservar uno, generelo a partir de su propio contenido para que no se desvíe.
En segundo lugar, decida si vale la pena colocar la capa de capacidad. Si los agentes tienen algún motivo para completar una tarea en su sitio web, buscar inventario, verificar un precio, iniciar una reserva, comenzar una devolución, entonces WebMCP es la apuesta que vale la pena y la prueba de origen significa que puede ejecutarlo con visitantes reales ahora en lugar de esperar a que se envíe. Si su sitio web es simplemente algo que los agentes leen en lugar de actuar, la capa de capacidad puede esperar y su esfuerzo debe centrarse en contenido limpio, renderizado por el servidor, que cualquier agente pueda extraer.
Lo que no debe hacer es asumir que el archivo que activó su complemento es su estrategia de agente. Es una afirmación de identidad que ningún sistema de inteligencia artificial puede leer y no dice nada sobre lo que un agente puede hacer una vez que llega.
Lo que aún está sin resolver
La incertidumbre sincera: la apuesta identitaria no está muerta; no está probado. Si un importante sistema de inteligencia artificial anuncia mañana que lee llms.txt y lo pondera, el cálculo cambia y el archivo que todos utilizaron de repente gana su lugar. Estoy buscando exactamente esa señal y aún no la he visto.
WebMCP tiene sus propias preguntas abiertas. Es un borrador del Grupo Comunitario, no una norma ratificada. Gemini en Chrome es el principal agente que lo consume hasta ahora. Y el soporte entre navegadores es menor de lo que sugiere la cobertura secundaria. Microsoft fue coautor del estándar, pero no pude encontrar WebMCP en las notas de la versión oficial de Microsoft Edge a partir de la versión 147, por lo que trataría cualquier afirmación de que Edge lo envía de forma nativa como no confirmada por ahora.
Hasta que llegue esa señal, mi apuesta es clara: para finales de 2026, la capacidad es la apuesta que importa y la identidad se desvanece hasta convertirse en una cobertura. El archivo que espera ser leído pierde frente a la herramienta que se invoca, porque los agentes se miden en función de si terminaron la tarea, no de si leyeron su letrero primero. Haga la apuesta de capacidad deliberadamente. Genere el archivo de identidad a partir de su propio contenido, si es que lo conserva. Y lea el que su complemento ya escribió antes de que hable por usted.
Más recursos:
Esta publicación se publicó originalmente en No Hacks.
Imagen de portada: Master1305/Shutterstock
