Skip to content
Documentation menu

Building for agents

Why static output wins

Pre-built pages are faster, cheaper, harder to break, and legible to software by construction.

A static site is built once, in advance, into finished files. A request gets a file. Nothing is assembled while a visitor waits, and there is no server deciding anything in the moment.

What that buys

It is already readable. The content exists in the file before anyone asks for it, so the first response carries the words. That single property is most of what makes a site legible to an assistant — and it is a consequence of the architecture rather than an optimisation on top.

There is less to break. No runtime, no database in the request path, no dependency that has to be up when a customer arrives.

It is cheap to serve at any scale. The platforms behind this practice run 1,346,766 pages across two properties on static hosting, and the insurance platform holds Core Web Vitals of 100/100/100/100 on mobile across page families.

Sources — live sitemap indexes counted 2026-08-08; PageSpeed Insights, 2026-08-08.

The honest trade

Static is not free of cost. Content changes require a rebuild, genuinely per-user pages need something else, and a large site’s build takes real time.

Those are real constraints, and for a business site they are usually the right trade: your hours do not change per visitor, and your services do not need a database to render.

Why this matters for the argument

A static site is agent-ready almost by accident. Everything else in this section is deliberate work; this one is a property you get for choosing the simpler architecture.

navigate openesc close