Sirve Markdown a agentes de IA con cabeceras Accept

Estoy de acuerdo con Roy Fielding sobre esto:

> Es un mal equilibrio de diseño enviar un montón de campos de cabecera en cada petición solo para decirle al servidor todas las variaciones posibles de preferencia que tiene el usuario, especialmente cuando hay muy poca probabilidad de que alguna de esas dimensiones sea aplicable al recurso objetivo. Ha sido un mal equilibrio de diseño desde el breve período de 1993-94 en que la gente no sabía qué formato de imagen sería utilizable en todos los navegadores y no había CSS ni JavaScript para permitir la adaptación del lado del cliente.

> ...El impacto en caché de la negociación proactiva es mucho peor que el viaje de ida y vuelta extra por sitio para la negociación reactiva, e incluso ese viaje de ida y vuelta no es necesario en formatos que soportan adaptación del lado del cliente.

Sobre el impacto en caché, Simon Willison escribió:

> ...no puedes desplegar una aplicación que use negociación de contenido mediante la cabecera Accept detrás del CDN de Cloudflare — por ejemplo, servir JSON o HTML para la misma URL dependiendo de la cabecera Accept entrante. Si lo haces, Cloudflare puede servir JSON en caché a un cliente HTML o viceversa.

Nota: publiqué esto en otro comentario con enlaces a esas dos citas que ahora no puedo copiar fácilmente - lo añadiré más tarde.

Haré eso cuando alguno de los 4 principales chatbots de IA diga que empezarán a hacer peticiones con esta cabecera. Antes de eso es solo una idea bonita sin adopción.

También creo que es extremadamente improbable que alguno de los 4 principales chatbots elija cargar sitios web de esta manera. Demasiados riesgos para una adopción del 0,01% incluso años después.

¿Qué tal HTML limpio y semántico?

Ya estaba optimizado para bots y motores de búsqueda (que son bots) y se ha usado durante décadas. ¿Por qué necesitamos servir en markdown ahora?

También hay muchas partes del HTML, como los menús de navegación, que son útiles para bots e IA y que podrían eliminarse en la versión markdown.

Viendo todas las preguntas en este hilo, recomiendo encarecidamente el artículo de Dachary Carey sobre el tema de documentación preparada para agentes: https://dacharycarey.com/2026/02/18/agent-friendly-docs/

Siento que me estoy volviendo loco. ¿Quién en su sano juicio alimentaría a un LLM con HTML crudo en primer lugar??

HTML es un lenguaje de marcado. Los agentes de usuario lo presentan de una manera que tiene sentido para el usuario—visualmente, o mediante tecnología de asistencia. Nada de añadir "usuarios" LLM debería cambiar esto—su agente de usuario, el arnés, debería presentar HTML de una manera que puedan entender de forma nativa, traduciéndolo a Markdown.

No vamos a reescribir toda la web porque los desarrolladores de arneses sean demasiado perezosos o estúpidos para sacar un paquete de HTML a markdown de npm. Si algunos sitios quieren hacerlo de todos modos, bien por ellos, en muchos casos me encantaría saltarme el CSS/JS y leer el markdown directamente (o mejor, bien formateado). Pero no culpes a los autores de sitios web por que tu arnés desperdicie tus tokens.

Esperando que esto se generalice para poder ver las páginas sin anuncios, JS y bloat

Vale, pero ¿qué agente usará realmente eso? Porque si ningún agente va a usar la cabecera accept html para obtener markdown, esto no tiene sentido.