The Design Agent

They are the same validator with the doctrine swapped. architect.validate scores agentic architecture, what the code does, against the 10 agentic principles. design.validate scores the perceptible surface, what the user sees, taps, scans, and remembers, against the 8 laws of the Experience Design Blueprint. Same first-pass pipeline, same ValidationResponse shape, same severity-weighted scorer, so a Blueprint Readiness Score is computed the same way on both. Runs share one validation-history dashboard: architecture runs are tagged architecture, surface runs are tagged surface. Pass the same repository and you get one project graded across three lenses: the spec (what to build), the machine behind the glass (architecture), and the interface in front of it (surface).

A Pro or Teams plan. design.validate has its own weekly run allocation, metered separately from the architecture bucket, so a heavy week of code review never eats your surface reviews and vice versa. Free and Basic accounts can read every doctrine principle, cluster, and example via the public MCP at no charge; the Design Agent is reserved for paid plans because it processes a real artefact under a no-training policy and persists per-project history. Current per-tier numbers are on the pricing page.

The eight laws are not weighted equally. On conflict, accessibility comes first and aesthetic polish comes last. In practice: a breach of the Fitts's-Law floor, an interactive target below the WCAG 2.2 24×24px minimum, a missing focus state, or a destructive confirmation the user cannot reach, is scored as a production_blocker. It caps the grade and must be fixed before you ship, the same way a failed trust boundary caps the architecture grade. A soft peak-end moment or a thin empty state is hardening_recommended or polish: it surfaces in a next-iteration list without dragging the score down. A high grade means the experience floors hold, not that the design won an award.

Not yet, and the tool says so on every run. design.validate v1 is a single-pass review at high reasoning effort. It has no consensus mode and no certification path, those stay architect.validate-only for now, and its score calibration is not yet tuned against a corpus of real runs the way the architect's was. Treat the grade as a directional craft signal, not a certified badge. The one part that is hard, not directional, is the accessibility floor: a production_blocker on a WCAG target-size or focus-visibility breach is a checkable fact, not a matter of taste.

Send the full artefact source verbatim as implementation_context, the JSX, the markup, the styles, no truncation and no … placeholders (they are read as literal code, and the reviewer will cite elements that are not there). If a surface is too large for your MCP client's tool-call budget, split into multiple calls scoped by component, never truncate one call. Non-visual code (a backend handler, a config file, a type alias) returns surface_classification: non_ui and tier: not_applicable, it is not failed, it is just not a surface. Submit the actual UI.

Your artefact source is sent to OpenAI (US) to generate the review, as a sub-processor under the EU Standard Contractual Clauses and UK Addendum, on a no-training basis, retained under OpenAI's API data-retention terms. AI Design Blueprint stores the structured result (score and per-law verdicts) plus, when you pass repository, a project identifier for grouping. Pass private_session=true to skip server-side run persistence; operational cost and audit records (never your artefact source) are still kept. Any instruction-shaped text inside your markup is treated as inert untrusted data, not as instructions to follow. Compute runs on Google Cloud Run; data at rest is in Cloud SQL, kept in the UK/EEA (Google Cloud europe-west2, London). Full detail on the trust and data handling page.