Yeah, the entire suite of proposed "standards" catering to agents looks like a temporary measure to duct-tape over the limitations and token costs of today's agents. They'll churn as quickly as Anthropic, Google, OpenAI et al. can release new versions of their frontier models.
> Yeah, the entire suite of proposed "standards" catering to agents looks like a temporary measure to duct-tape over the limitations and token costs of today's agents.
That's fine. We need a fix for today's problems today.
Let's just not get blinded by this to the true nature of the problem. The web being hard for agents isn't an accident - it was done on purpose. More specifically, it's a consequence of the web evolving to defeat automation and limit access.
Most websites are exist to make money from specific audiences in specific ways, often defined in contracts between hundreds of business entities, and none of them want you to be able to automate access, or interact with the website in any way other than the one that spins the money-making machine. Consider that the flip side of "basic tabular interface" is "skip website entirely, access underlying database"; the flip side of "screen readers" is "ad blockers"; the flip side of APIs is "competitors can scrape my listings and use them against me", etc.
Agents are hot right now, the whole business side is still blinded by hype, so things like MCP and .md endpoints are not just getting a pass, but are even pursued by the business people ("we have to do something with AI!"). This won't last long, though - they'll soon realize their mistake, close off access, and enshittify the web some more.
Just like they did in the past - e.g. when APIs and mashups briefly became a hot thing, then went away as businesses realized this defeats the very thing that makes them money: total control over platform/user channel.
--
[0] - Even your most basic blog showing some ads creates a money-making chain, made up of dozens or hundreds of business entities, bound by actual contracts, and the "blog author that just wants to show some ads" is merely one party at the end of that chain.
> No, we don't. It is Anthropic, Google, OpenAI et al. who need a fix for those problems today. Let them deal with it.
I don't think you understand what an instruction files or a agent skill is. They are nothing more than glorified custom prompts that are automatically integrated in sessions by the user agent. The likes of Anthropic are paid either way.
It's not Anthropic et al who seek to do less work to get models to do their work, nor do they care if prompts are shared. At most it is a minor UX improvement, and one which is shared across AI vendors.
> True, that's fine. As long as people don't elevate these transient "standards" to the same level as something like basic security and accessibility.
I don't think that's it at all, and I'm baffled as the suggestion it is. These things are just formats for ad-hoc interfaces to help share context used by agents.
It's in the same vein of designing cli apps with progressive disclosure in mind.
What requirments are you talking about? Human readability? IMHO, RSS is for feed readers, not humans. When looking at https://news.ycombinator.com/rss , the RSS isn't that human friendly at all, all line breaks are removed. The point is the simplicity and uniformity, regular escape works well for many cases, not just description.
That assumes that you don't have anything else to escape or sanitize.
I see people stuffing all sorts of HTML tags and nonstandard attributes in an RSS <description>, just because CDATA allows them to do so without breaking the parser. Images, videos, inline SVGs with maybe some scripts inside...
The RSS spec should never have allowed this. Reading a feed would have been much more pleasant (not to mention safer for everyone!) if the contents were required to be in plain text.
I’m not sure I understand why this is a problem. RSS is a spec for publishing a list of available content, or publishing the content directly. Formatting that content was always going to be something people wanted to do, so whether it was rich text, html or what became markdown, it was inevitable that aggregators were always going to have to deal with both publishes wanting their publication to have styles and users wanting their aggregator software to either handle that style or hide it.
At least with a cdata tag your being explicitly told “here be dragons”
I guess the difference is if you want the descriptions to be readable by simple tools, or if you assume that every reader has a full-fledged Chrome available.
If there's a query parameter that you have a legitimate use for, like `q` for searching, obviously you should configure your web server to let it through.
Even in that case, you might want to block unexpected values as early as possible in your stack. For example, if you have a legitimate use for a certain set of `utm_source` values, but someone sends you bobby tables, you probably shouldn't log it blindly.
Ditto for the Referer header -- there's a lot of spam, and some of those strings might even be dangerous. You can't trust any of them anymore.
Nope, properties must be an object (dictionary or null). Which means each property can only appear once.
The spec doesn't say what type the value of a property can be, though. Examples in the RFC show strings, floats, and a nested object. So you could probably put a list in there as well if you want to store multiple values under the same key, provided that your decoder knows what to do with such values. (GeoJSON is often converted to and from WKB/WKT, and unorthodox values may be lost in the conversion.)
What's the smallest unit of functionality to which your principle applies?
For example, each comment on HN has a line on top that contains buttons like "parent", "prev", "next", "flag", "favorite", etc. depending on context. Suppose I might one day want to remove the "flag" functionality. Should each button be its own file? What about the "comment header" template file that references each of those button files?
I think that if you continue along the logical progression of the parent poster, then maybe the smaller units of functionality would be represented by simple ranges of lines of text. Given that, deleting a single button would ideally mean a single contiguous deletion from a file, versus deleting many disparate lines.
The `comment_header` template would iterate over the files in `comment_header.d/*`, which would, admittedly, need forced sorted naming:
100_parent.template
150_context.template
200_prev_next.template
300_flag.template
350_favorite.template
Looks odd with the numbering, no?
But then you get the added benefit of being able to refer to them by numbers, just "100" or "300" without having to glue humanlang inflection, declension, punctuation onto identifiers that happen to be words...
Some places where you can see this pattern: BASIC's explicit line numbering; non-systemd init systems.
reply