The architecture review is the engagement we recommend first, and the engagement we run most often. It is also the one whose value is hardest to explain in advance. People expect a report. What they get is a different question.
This note describes what tends to surface in the first hour, drawn from the engagements we have run since the practice opened.
The first thing we look at is not the site
Before any audit tooling, before any prompt construction, the review starts with a question to the operator: what does the answer look like, when an AI assistant works the way you want it to?
Most teams have not written that down. They have a homepage. They have a deck. They have a positioning brief written for human readers. None of it is the answer the AI is supposed to produce.
The first hour is mostly spent translating the operator’s intent into a small set of operator-style assertions: who the customer is, what the offer actually covers, what the boundary is, what the proof is. These become the test fixtures for everything downstream.
The recurring failure modes
Three patterns show up repeatedly:
- Category drift. The site describes a service one way; the AI summarizes it as something adjacent. Usually the cause is a single ambiguous paragraph that has been repeated across pages and now anchors the model’s interpretation.
- Evidence-poor authority claims. The site asserts expertise without the structured evidence (named methodology, named clients with permission, named outcomes) that an AI weighs. The model picks up the claim but cannot verify it, so it hedges or omits.
- Cross-source contradiction. The site is internally consistent. Third-party sources — directory listings, partner pages, reposts — describe the operator differently. The model averages, and the average is wrong.
None of these are visible in a content audit. All three are visible in the first hour of structured AI prompting against the live site.
What the deliverable actually is
The architecture review does not produce a list of pages to rewrite. It produces a small number of architectural decisions: what the canonical statement is, which third-party surfaces need correction, what the evidence layer is going to look like. The implementation is downstream — sometimes us, often the operator’s existing team.
The point of the first hour is to make sure those decisions are grounded in what the AI actually does with the site today, not in what the operator hopes it does.