INFRAESTRUCTURA
Negociación de contenido para agentes de IA: servir markdown con el header Accept
Los agentes de IA queman la mayor parte de su presupuesto de tokens interpretando HTML diseñado para navegadores. La negociación de contenido permite que la misma URL sirva una versión limpia en markdown cuando un agente la pide, sin tocar lo que ven humanos y bots de búsqueda. Así se hace bien, y este es el error a evitar.
Una página web moderna es en su mayor parte no-contenido. Marcado de framework, estilos, scripts y andamiaje de navegación envuelven unas pocas cientos de palabras de sustancia real. Los humanos nunca ven el envoltorio. Un agente de IA que descarga la página tiene que cargar todo eso en su ventana de contexto antes de poder usar nada.
Las renditions en markdown resuelven esto: una versión limpia y estructurada de cada página, una fracción del tamaño, con la sustancia intacta. La pregunta interesante no es si ofrecerlas sino como un agente las encuentra y las recibe.
El header Accept es el disparador correcto
HTTP tiene la respuesta desde el principio: negociación de contenido. El cliente declara que formatos acepta; el servidor elige la mejor representación del mismo recurso. Un agente que quiere markdown envia Accept: text/markdown a la URL canonica y recibe la rendition en markdown, con el content type correcto y un header Vary: Accept para que las caches mantengan separadas las representaciones. Todos los demas que piden la misma URL reciben HTML completo.
El descubrimiento es explícito, no supuesto: cada página declara su rendition con un tag link rel alternate apuntando a la ruta markdown, y un sitemap de markdown lista todas las renditions en un solo lugar. Un agente puede negociar, seguir el enlace o descargar la ruta .md directamente.
El error: disparar por user agent
El atajo tentador es detectar user agents de bots y forzar markdown a todo lo que parezca un crawler de IA. En pruebas en vivo esto rompe de una forma concreta y danina: los fetchers detras de la búsqueda con IA y de la navegación activada por usuarios esperan HTML, porque sus pipelines de extracción están construidos para HTML. Si les fuerzas markdown, sus extractores pueden volver vacios. El sitio se vuelve menos visible justo para los sistemas que la capa debia servir.
La regla que se deriva: negociar solo con el header Accept. Los agentes que piden markdown reciben markdown. Cada bot que no lo pide recibe lo que su pipeline espera, lo que lleva al segundo requisito.
El HTML prerenderizado sigue siendo el valor por defecto
Una capa markdown es un complemento, no un sustituto. La representación por defecto de cada ruta debe ser HTML renderizado en servidor y completamente poblado, porque la mayoría de los fetchers relacionados con IA no ejecutan JavaScript y nunca envian un Accept de markdown. Una carcasa JavaScript con un nodo raiz vacio es invisible para ellos por buena que sea la capa markdown.
Las renditions además se mantienen como contenido, no como una exportación. Cuando el copy de una página cambia, la rendition cambia en el mismo commit, o los agentes reciben una versión obsoleta del sitio mientras los humanos ven la actual.
Funcionando en vivo
Esto no es una propuesta. La capa descrita aquí funciona en producción en tkmstudio.com: pide cualquier página de este sitio con Accept: text/markdown y el servidor devuelve su rendition en markdown, con el recuento de tokens en un header de respuesta, el sitemap referenciado y Vary configurado. La página que estás leyendo tiene una. Es la misma capa que entregamos en los builds de clientes.