Introducing Agent Layer

Two requests can hit the same page:

1. A browser asks for text/html.
2. An AI agent asks for text/markdown.

Most web stacks give both of them the same HTML. That works well for the browser. For the agent, it can mean parsing navigation, scripts, layout, consent UI, and thousands of tokens that have very little to do with the page itself.

Our audit makes that mismatch easy to see. Fixing it is a different problem.

So we are building Agent Layer: a platform for serving agent ready content and understanding how agents use it.

It is not live yet. We are opening the waitlist now because we want to design the deployment and analytics around real traffic, not a tidy diagram of how we imagine agent traffic works.

Why we're building it

The audit does its job. You paste a URL, we crawl up to 10 pages, and the report shows where the agent experience breaks down. The recurring failure is simple: an agent asks for Markdown and gets the same HTML as everyone else.

The fix is less simple. Content negotiation touches the rendering and delivery stack. Even a small change can cross routing, caching, security, and ownership boundaries.

Then there is the measurement problem. A request can exist in a server log without answering the useful questions:

1. Which pages are agents requesting?
2. Which clients identify themselves?
3. Are they receiving clean content successfully?
4. Does agent traffic change after the content improves?

Agent Layer is our answer to both problems. It serves the content and makes the traffic visible.

What Agent Layer does

When a client requests a page and prefers text/markdown, Agent Layer returns a structured Markdown representation. Human visitors keep getting the existing HTML experience.

The response follows the same approach we describe in our own Markdown implementation and generate in the Agent Preview tool:

1. YAML frontmatter with the title, description, and canonical URL
2. Navigation, headers, footers, cookie banners, and scripts removed
3. A useful heading hierarchy, fenced code blocks, and descriptive link text
4. A site index that helps agents find related pages

Agent Layer will also track the requests it handles. We want to show page demand, request volume, self identified clients, response health, and changes over time in one place.

There is an important limit here. Client headers can be missing or misleading, so attribution will never be perfect. We would rather label traffic as unknown than manufacture certainty about which agent sent it.

How it fits into your stack

Agent Layer is designed to sit between an agent request and your existing web stack. Your normal visitors keep getting your normal site. The agent gets content in the format it requested.

The unresolved question is how traffic reaches the layer. That is not a footnote. It determines the security model, caching behavior, setup cost, and how much traffic touches the service.

Two approaches look plausible. You could point a hostname at Agent Layer with a CNAME. Or you could add a small rule at your existing edge that forwards only Markdown requests. The first asks less of your team. The second keeps browser traffic out of our path and serves Markdown from the canonical domain.

We have opinions. We do not yet have enough customer evidence to pretend they are requirements.

Join the waitlist

If you want a managed way to serve agent ready content and understand how agents use it, leave your email below. We will contact you when we are ready to onboard the first sites. No nurture sequence. No “just checking in” email three days later.

If you have not already, run the free audit first. Bring the score to the conversation. It tells both of us what Agent Layer would need to fix on day one.