Agentic Design Process · Sourabh C C

The problem

A static mock-up gives engineers a picture and leaves them to guess the rest. Front-end teams rebuild each screen by hand. Drift creeps in between the design file and the component library. Copy, accessibility and domain accuracy get checked late, often after the code is written.

I wanted the prototype to be the first real version of the product. Built with the production design system, checked by agents against written standards, and approved by people before it ships.

The principle

Agents suggest, people decide. Every agent finding has to cite a rule. Every human decision is logged. Agents are read-only: they never edit, commit, push or publish.

Input

Prototype in codeBuilt with library components and design tokens

Specialist agents, in parallel

Design system agentComponents, tokens, spacing, focus states

Content agentTerminology, tone, labels, error and empty states

Domain expert agentFact-checks every claim the screen makes, with a citation

Review panel

One verdictFindings table, each row tied to a rule

BlockedFix firstReady

People

Human decisionsOpen questions go to a named owner and into a decision log

The review loop. Agents find and explain. People decide, and every decision is written down.

What the process runs on

The agents are only as good as what they read. So the process starts from sources of truth, not from prompts.

HelpersScripts for drift scanning, contrast checks and pull request review in continuous integration

ComponentsThe production React component library, documented in Storybook

AgentsDesign system, content and domain specialists, plus a review panel that runs all three

KnowledgeDomain primer, terminology list and the review protocol

StandardsRoot of trust. Design, copy, accessibility, code review, design-system review and data visualisation rules

Read from the bottom up. When an agent and a standard disagree, the standard wins.

The flow

Ten stages in five phases. Four gates where a person has to sign off before work moves on.

Frame

Stage 1Write the briefUser, moment, job of the screen, flow steps, facts it will state

Stage 2Ground the facts Gate 1Every claim verified with a source, or flagged with an owner

Stage 3Choose componentsMap each pattern to a library component. Gaps become decisions

Build and check

Stage 4Prototype in codeReal components, tokens only, copy drafted with the content agent

Stage 5Self-checkDrift scan and quick single-agent reviews↻ repeat until clean

Stage 6Panel review Gate 2No blockers left, and every open question has an owner↻ fix, re-run

Decide

Stage 7Human decisions Gate 3Each open question answered, or "ship without" accepted by name

Ship

Stage 8Pull request Gate 4Continuous integration runs the panel. A human reviewer approves

Stage 9Preview and productionProtected preview per pull request. Production from main only

Learn

Stage 10Feed it backEach human correction goes to the layer that caused it

↺ Stage 10 updates the standards, agents and knowledge that the next brief starts from.

Gates 1 to 4 are human checkpoints. Nothing moves past a gate on an agent's word alone.

Not every change needs every stage. The brief picks a track.

Track	Stages	What changes
New feature or flow	All 10 stages	Full panel review at stage 6
Iteration on an existing screen	Stages 1, 2 and 4 to 10	Only changed facts are checked. The brief lists what must not change
Dashboard or data visualisation	All 10 stages	Stage 3 follows the data visualisation rules. Every tile is scored, and every number gets a drill-in

Growing the design system

Sometimes the library has no component for a pattern. The easy fix is a lookalike built inside the prototype. That’s exactly how drift starts. Here, a gap becomes a contribution to the design system instead, reviewed and approved like any other code.

DesignerGap foundAt stage 3, no component fits the pattern. It's logged as a decision, not patched over

Design system leadApproved to buildNew component or a variant of an existing one

Designer + artificial intelligenceBuilt in the libraryTokens, every state, accessible names and a Storybook story

Agents + continuous integrationCheckedDrift scan, contrast, design-system review and content review on the pull request

Design system lead + engineerPull request approvedReviewed against the code review standards, with continuous integration checks green

Continuous integrationReleasedA new library version. The prototype and the product both pick it up

The component path. Engineers review and merge instead of rebuilding from a spec.

This is where the front-end effort drops. The prototype already uses production components, so the hand-off is working code. New components arrive through the same pull request flow engineers use every day. Their job shifts from translating a design to reviewing one.

Testing with agents

Each agent tests a different layer of the same screen. Cheap checks run on every change. The full panel runs before a pull request.

Design and components

No raw hex or off-scale values
Library component used wherever one exists
Contrast checked for every colour pair
Focus states kept, icon buttons named

Content

Terms checked against the terminology list
Sentence case, real labels, no placeholder-as-label
Errors and empty states say what to do next
Unknowns left in [brackets], never invented

Domain accuracy

Every claim on screen fact-checked
A source cited for each verified fact
"I don't know" outside the primer, with an owner to ask
Ship and end-of-life dates checked

Three lanes, one verdict. The panel merges them and lists what needs a human.

Where people stay in charge

Some calls never go to an agent. Legal or compliance copy, security-critical flows, destructive actions, and anything the standards don’t cover all go straight to a person. Silence in the standards is not permission.

Question	Owner
Rule gap, token or component choice	Design system lead
Wording, terminology, tone	Content lead
Technical or domain accuracy	Subject matter expert
Legal, compliance, disclosure of artificial intelligence use, pricing	Legal
Behaviour, scope, roadmap	Product manager

Shipping

Every change goes through GitHub. Continuous integration runs the review panel on each pull request. It’s read-only and fails the build on a “Blocked” verdict. A human reviewer still has to approve. Each pull request gets a protected Vercel preview for design review, with fixture data only. Production deploys come from main, after the last gate.

The learning loop

When a person overrules an agent, that correction is data. It goes to the layer that caused it, never into a patch that makes the agent disagree with a standard.

What happened	Where the fix goes
The rule was applied correctly, but the rule is wrong	The standards repo
The agent misread or skipped a rule	The agent’s instructions, with a worked example
A domain fact was wrong or missing	The domain primer, with a source
A term or product name was wrong	The terminology list

Real reviews and the human edits that followed are kept. They’re the start of an evaluation set for the agents themselves.