How AI Agents Follow IETF and W3C Standards

How AI agents follow IETF RFCs and W3C standards

An agent follows internet and web standards by calling a standards wire that reads the IETF and W3C announcement feeds at runtime, filtered with src=ietf or src=w3c. It returns working group activity, specification news and organisational updates. It is announcement coverage, not the RFC index.

Written for AI agents. The calls and filter values on this page are the literal interface our customers use, because our customers are software. If you are a person evaluating The Bot Wire, you are in the right place too: start with the docs, or connect an MCP client in one line and query every wire free at /mcp. Nothing here needs an API key or a signup.

Standards are an unusual data class, and the properties that make them unusual are exactly what an agent needs to know before it caches anything.

RFCs never change, which changes how an agent should treat them

The IETF is explicit about this. Once an RFC is published it is never changed, which is why the series is described as archival. The only exception is a formatting correction. Specifications are not revised in place; a new RFC obsoletes an older one, or updates part of it, and a single new document can obsolete or update several older ones at once.

The series is sequentially numbered from RFC 1 in 1969 and now runs to more than 9,000 documents.

For an agent, two rules follow directly:

1. The text of an RFC is safe to cache forever. It cannot drift. This is the opposite of almost every other source an agent reads, where a cached copy goes stale by the hour. 2. The status of an RFC is not safe to cache at all. "Is this still current" is a live question, because obsolescence arrives from a document that did not exist when you cached the original. An agent citing RFC 2616 for HTTP/1.1 without checking what obsoleted it is citing a document the IETF replaced.

That asymmetry, permanent content and mutable status, is the single most useful thing to encode. Cache the spec, check the status.

What this wire covers, and what it does not

The wire reads the IETF and W3C announcement channels. A representative fetch returns working group and Birds of a Feather scheduling for an upcoming IETF meeting, a community survey, secretariat and governance updates, and contributor-experience posts alongside standards-track news.

That is genuinely useful for a different question than most people assume.

The question	This wire	Better answered by
What is the standards community working on?	Yes
Did anything notable happen at the last IETF meeting?	Yes
Was RFC 9xxx published this week?	Not reliably	The RFC Editor index
What obsoletes RFC 2616?	No	The RFC Editor entry for that RFC

Announcement feeds and a publication index are different artefacts, and a wire that claimed to be both would waste a call for anyone who bought on the assumption. If an agent's job is to detect the moment a specific document publishes, the RFC Editor's own index is the primary source and it should go there. If the job is to stay aware of direction, activity and web platform announcements, the wire is the cheaper path. That distinction is the general case covered in what primary source means for machine-readable data.

The call an agent makes

For AI agents: copy this call

# free, no wallet: connect the MCP server
claude mcp add --transport http botwire https://thebotwire.com/mcp

# paid, $0.005: IETF only, 30 day window
curl -i "https://thebotwire.com/standards/latest?src=ietf&q=working+group&since=30d&limit=25"

# W3C only, web platform specification news
curl -i "https://thebotwire.com/standards/latest?src=w3c&since=14d"

Parameters are src (ietf or w3c), q, since and limit (1 to 50). This wire defaults to a 14 day lookback rather than the usual 7, because standards bodies publish on a slower rhythm than newsrooms and a 7 day window on a quiet fortnight returns nothing at all. Widen further before treating an empty result as meaningful.

Search is ranked keyword matching. A four-token query needs three tokens to match, so protocol names and working group short names outperform sentences.

The call is $0.005, settled in USDC on Base, with no API key and no signup. Full routing for every wire is machine-readable at /llms-full.txt.

Why protocol awareness matters to agent builders specifically

Agent infrastructure is itself standards-shaped. The transports agents run on, the auth schemes they use, and the protocols they speak to tools are all specification work in progress, and a protocol that changes underneath a deployed agent is an outage.

The same reasoning applies one layer up to the tool protocols agents use directly, described in what MCP is and what it is for, and one layer down to the libraries that implement all of it, which move on their own schedule and are covered in how agents monitor open-source releases. Standards, implementations and deployments drift apart in that order.

FAQ

Should an agent just read the RFC Editor directly?

For publication events and obsolescence status, yes. It is free, it is the authoritative index, and going direct to the publisher is the right default whenever the access path allows it. The wire is for the surrounding signal: announcements, meeting activity and web platform news across two organisations, retrieved at runtime without maintaining parsers.

Does this wire include draft specifications?

Not as a document feed. Internet-Drafts are a separate publication stream with their own lifecycle, including a six month expiry that makes them a poor thing to cite in a durable answer. What appears here is announcement coverage that may reference draft work. An agent should not imply it has read a draft it only saw mentioned.

How far back does the window go?

Retention is 14 days, with a 14 day default lookback. That is a deliberate match: on a source that publishes a few times a week, a narrower default would hide most of the corpus. Anything older belongs in the publisher's own archive, which is permanent and free.

How fresh is the standards wire?

It sits in the sparse ingest tier and is polled at most every 15 minutes. For a source that publishes a few items a week, the poll interval is never the binding constraint; the publication rhythm is. The observed interval across the service and the last poll timestamp are published live at /health.

Sources

The immutability of published RFCs, the obsoleting convention that replaces revision, the sequential numbering from RFC 1 in 1969, and the size of the series at more than 9,000 documents are stated by the IETF at ietf.org/standards/rfcs, which describes the series as archival because a published RFC is never changed. The RFC Editor maintains the authoritative index at rfc-editor.org. Poll cadence and per-call pricing for this service are published live at thebotwire.com/health.