The Web Context Layer: A Practical Architecture for AI Products

Most teams arrive at this layer by accident. A feature ships with a search tool bolted onto a model, quality complaints start, and the fix list grows: better prompts, a reranker, a bigger context window, a different model. Some of those help at the margin. None of them address the fact that the content reaching the model was chosen and cleaned by a process nobody designed.

What the web context layer actually is

Define it plainly: the web context layer is everything that happens between receiving a question and assembling the text a model sees. It owns source choice, fetching, cleaning, structuring, and provenance. It does not own generation, and it does not own the interface.

The reason to name it is ownership. When the layer is unnamed, its failures get attributed to the model, and the team spends its effort on the one component that is not at fault.

Why a more capable model does not fix this

Model knowledge is frozen at training time, and the questions people bring to a web-enabled product are usually about the part that changed: this quarter's pricing, last week's release notes, the current version of a policy page. No amount of model capability recovers information that was never in the context window.

The second-order effect matters more. A stronger model writes a more fluent, better-organized, more confident description of bad context. From the outside, upgrading the model can appear to improve quality while making errors harder to catch.

The five layers

Layer 1 — Retrieval plan

Before anything is fetched, the system should have an explicit statement of what it is looking for: the objective, an allowed source scope, a freshness requirement, the output shape, and what to do when the evidence is thin. This is the cheapest layer to build and the one most often skipped. See the retrieval-plan field note for the template.

Layer 2 — Source selection

Selection turns the plan into a candidate set. Generate several query phrasings rather than one, keep the query that produced each candidate, and score candidates before fetching them: does the domain belong to the scope, does the URL pattern look like a documentation page or a marketing page, has this URL been retrieved recently enough to reuse?

Selection must be able to return nothing. A candidate list of zero is a valid, informative result; a forced best-of-bad list is how confident wrong answers begin.

Layer 3 — Retrieval and normalization

Fetch, then verify that usable content arrived: a minimum quantity of meaningful text, at least one expected structural element, and no consent wall, challenge page, or login interstitial — all of which return 200. Then reduce the page to what a reader would call the page, keeping headings, lists, tables, code, and link targets. The mechanics are covered in turning a website into LLM-ready Markdown.

Layer 4 — Structured context

Decide what the model receives. For open questions, that may be cleaned passages with headings intact. For comparisons, catalogues, and anything downstream software consumes, it should be typed records produced by schema-first extraction, with explicit nulls where the page said nothing.

The distinction is practical: passages let a model reason and hedge; records let your application branch, sort, and validate. Products that need both should produce both, not blur them.

Layer 5 — Provenance and evaluation

Every value that leaves the layer carries a source URL, a retrieval timestamp, and the excerpt that supports it. That record is what makes evaluation possible: you can sample outputs, open the excerpt, and judge whether the claim survived the trip.

{  "question": "What are the current deployment regions?",  "plan": { "scope": ["docs.example.com"], "freshness_days": 30 },  "sources": [    {      "url": "https://docs.example.com/platform/regions",      "retrieved_at": "2026-09-14T09:12:04Z",      "content_chars": 4820,      "selected_by": "query: example platform regions list"    }  ],  "context": {    "regions": ["us-east", "eu-west", "ap-south"],    "as_of": "2026-09-14",    "missing": ["pricing_by_region"]  },  "claims": [    {      "text": "Three regions are generally available.",      "source_url": "https://docs.example.com/platform/regions",      "excerpt": "Regions currently generally available: us-east, eu-west, ap-south."    }  ]}

Choosing an access mode

Most real features combine two or three of these. The decision is per task, not per product, and it belongs in the retrieval plan rather than in the model's discretion. A fuller decision walkthrough lives here.

Constraints that shape the design

Refresh logic

Freshness is a product decision expressed as data. A documentation assistant can usually serve content retrieved within a week; a pricing comparison cannot. Attach a freshness requirement to the task, store retrieval timestamps, and let the layer decide between reuse, revalidation, and refetch. When content is older than the requirement and refresh fails, say so in the output rather than serving it silently.