← the field
interviews · raw
“I never know what it did”“too many steps to undo”“I want to approve first”
researchClaude · argues back
decisions ledger
✓ approval before actions✓ status stays visible○ auth scope — open
documentationNotion · the team’s memory
DESIGN_SYSTEM.md
● waiting for approvalApprove
executionClaude Code · inside the rules
2026-08-08 · the composer hugs what you typewhat · why · decided by“I wanted the textbox to adapt according to the text.”
memoryGitHub · the change log

Building an agentic design pipeline

One designer, four jobs, and AI agents doing most of the production. What makes it hold is not the tools — it is a rules file, a permission queue, a change log, and one page every agent reads before it starts. All four are real, quoted here, and yours to copy.
scroll
interviews · raw
“I never know what it did”“too many steps to undo”“I want to approve first”
researchClaude · argues back
decisions ledger
✓ approval before actions✓ status stays visible○ auth scope — open
documentationNotion · the team’s memory
DESIGN_SYSTEM.md
● waiting for approvalApprove
executionClaude Code · inside the rules
2026-08-08 · the composer hugs what you typewhat · why · decided by“I wanted the textbox to adapt according to the text.”
memoryGitHub · the change log

Four jobs, one person

What breaks first when the work needs four people and there is one of you?

For the past six months I have been the only designer at an AI startup. The load, concretely: user interviews and their synthesis; a product of thirteen flows and roughly ninety screens, with the design system behind them; the front-end of the accounts app; and the marketing side — launch video, website, brand assets. The four jobs ran in overlapping phases, never one at a time.

At that load, the first thing that breaks is not output — you can always work longer. It is consistency and memory: whether screen sixty still obeys the decision made at screen six, and whether anyone can say why that decision was made at all.

I put AI on all four jobs anyway, starting from open skepticism — its output was a draft I expected to discard, on a leash I only lengthened where it earned it. What follows is what survived six months of that: not a tool list, but the written structure that turned throwaway drafts into production work. Every file quoted in this essay is real and in daily use.

Insight: The finding, up front: agents don’t fail from lack of skill. They fail from lack of written context — and every mechanism below is a way of writing context down once instead of re-issuing it forever.

Research: the first job handed over

Research climbed off the leash first, for a reason worth copying: it is the job where checking the AI costs the least. I run the interviews and hold the transcripts, so when Claude clusters them into themes I can lay its reading over mine and see exactly where it is right, wrong, or lazy. Trust earned where verification is cheap is real; trust granted anywhere else is hope.

A pass is mechanical: transcript lines in, candidate themes out, each theme carrying its evidence count. The model is a second reader — never the first, never the last. It reads what I collected and argues for a structure; the structure is a draft until I have pushed back on it.

The push-back matters more than the pass. In one round it labeled a cluster visibility — but the users could see the status fine; they wanted it to say more. Real cluster, wrong name, and changed what got built: status became something the product phrases, not just something it shows. A synthesis you have not argued with is an opinion with good formatting.

Insight: Start your own pipeline wherever you hold the raw material. That is where an agent’s mistakes are visible enough to teach you what it can and cannot yet be trusted with.

The rules file

Execution — Claude Code building real screens — has an entry fee: the rules must exist outside my head, because every agent session starts as a stranger with no memory of the last one. The first unruled sessions produced work that was plausible and subtly off, each in its own direction. The fix was not better prompting. It was a document: DESIGN_SYSTEM.md, written so “a contributor or an LLM can make aligned changes without re-deriving the product each time.” That sentence is its actual opening line, and it carries three layers.

Closed sets. The recurring choices as short, fixed lists whose power is what they exclude. Radius: 4 and 8 — “that is the whole scale.” Spacing: ten steps, with the reasoning attached — the jump between steps is the hierarchy signal, so “if 12 is tight and 16 is loose, ship 16.” Motion: four named transitions, because inventing a duration should feel like inventing a color.

Judgment. When to use which, and why — the layer a component library cannot hold, which is exactly where generated work drifts. Two habits make it strong: record the tradeoff, not just the verdict, and record reversals — when a decision gets made twice, the rule keeps both the answer and the scar:

DESIGN_SYSTEM.md — two judgment rules, verbatim
### Blue is load-bearing
Marks the single active, running, or awaiting-you element.
Never decoration. Never a default fill.

### Balances and plans are per agent
Not per workspace. This was reversed once mid-design —
do not rebuild it as a shared pool.

Guardrails. The never-list, written as data wherever possible. The product has a banned vocabulary — seven words it never says to a user (“runtime”, “tenant”, “thread”…; it says credits, never tokens) — and the list lives in code, not in a style note, because the next section reads it mechanically.

Insight: The test of every rule: a stranger with no context could follow it and produce work you’d keep. An agent session is that stranger — and a review that catches the same mistake twice has found a rule you haven’t written yet.

Enforcement, not vibes

Unguided sessions don’t produce chaos — they produce near-misses: four paddings, four almost-identical blues, three corner treatments, none of them wrong exactly, all of them different. The rules file names the end state this compounds into: “three button heights and four greys”, each invented in a hurry, under a deadline, by whoever was closest to the bug.

So the guardrails run as code. Every change to the design system runs drift:check: no raw color anywhere outside the token file, no radius off the 4-and-8 scale, no invented durations, and none of the banned words in anything a person reads. The check scans rendered text rather than code — export const runtime passes; a screen that says “runtime” to a user fails. Rules stated as data get enforced by machines; rules stated as prose get enforced by hoping.

Any craft has a mechanical layer like this: words you never publish, claims that need a source attached, values that have exactly one definition. It will not catch taste. It catches the 80% of drift that is not taste — which is what frees review to be about taste at all.

Insight: Drift is a decision you haven’t written down, being re-made — slightly differently — by every fresh session. Each violation the check catches is that decision finally getting written.

The pass gate

The real risk of a capable agent is not bad work — the checks catch bad work. It is confident invention: the agent hits something the design never covered and fills the gap with a plausible guess that quietly becomes the spec. The working agreement draws the line in one sentence: “Compose freely from what exists. Invent nothing at the decision layer.” New arrangements of existing decisions need no permission; new decisions go through a queue.

The queue is a markdown file. An entry states what is missing, why the product needs it, and the smallest version that unblocks— then the agent stops building that piece and keeps building everything else. Statuses run proposed → approved or rejected → built, and an approved entry must name its human approver; the automation fails the change if it doesn’t. The approvals keep the deciding human’s actual words:

design-requests.md — a real entry
## DR-7 · Line chart component
- Status: approved
- Needed: the dashboard charts growth over time, and
  nothing in the system draws a line.
- Smallest version: single series, hairline grid, one
  accent dot. Multi-series is deliberately out of scope.
- Approved-by: Hribhav, in session, 2026-08-02
  ("Design the line chart now")

And when a guess is genuinely unavoidable, it gets labeled on the work itself. The product needed a Files screen that 148 links pointed at and no design covered; the approved answer was “build a reasonable Files screen” — so the built screen carries a line saying it is an interpretation with no spec behind it, and a row in an invented-work table records what would replace it. When the real design arrives, the guess is replaced rather than adjusted, because adjusted guesses keep the shape of the guess.

Insight: The gate and the log that follows are two different instruments on purpose. In the queue’s own words: “a log is written by the same agent it holds accountable; a request is answered by someone else.”

What, why, decided by

The change log exists because of a failure, and it says so. Its first line admits the earliest entries were reconstructed from git history “because the log did not exist when the changes landed. That gap is the reason it exists now.” The rule since: any change that touches a protected surface — the design system, the rules, the published components — adds an entry in the same change, and the automation fails it otherwise. Three lines: what changed, why, and who decided.

The detail that makes it work is that “decided by” quotes the human verbatim. Not “per feedback” — the actual words: “the h1 header should still be there. It’s gone from all the pages right now.” That entry records me reversing the agent’s reasoning-driven simplification; others record the agent fixing what I described from the outside, like a composer that “counts the times someone pressed Enter and nothing else” while typed text scrolled out of view. Both directions get logged, which is what makes the log a memory rather than a report card.

This is also what became of version chaos. Design used to live in Drive folders named final_v2 and final_FINAL_approved; now every version is a commit with its entry attached, and the history is readable by the agents too — “go back to how it worked before the 6th” is an instruction, not an archaeology dig.

Insight: Thirty seconds of writing per change, in exchange for never reconstructing intent from a diff three weeks later. It is the cheapest trade in the whole pipeline.

The bridge

The hardest problem was never a single tool. It was that the two most important ones cannot talk: Claude, which researches and strategizes, and Claude Code, which builds — same company, no shared memory. For a while the bridge was me, retyping decisions from one window into the other, which is exactly the job I built a pipeline to stop doing.

The fix is shared pages in Notion, in two shapes. The first is a decisions ledger, whose header states its contract: “update this page whenever something locks — it is the team’s memory.” Ratified decisions carry their date and reason; open items name what is blocking them; and its convention line is the pipeline’s working temperament in one sentence: “discuss before executing; execute decisively once greenlit.”

The second is a brief per piece of work, addressed to the executing agent by name — the marketing-site brief literally opens “Audience: Claude Code” — with a header that settles conflicts before they happen:

the build brief — its sources-of-truth header, condensed
Audience: Claude Code.
Sources of truth:
  visuals & keyframes  = the Figma board
  motion, copy         = this doc
  product behavior     = docs 01-03
Where board and doc conflict: the board is newer
for layout, this doc is newer for motion values.

Every session starts by reading the rules and the newest ledger entries, and ends by writing one entry back. The agent never has to ask which source wins — the brief already says — and I never retype a decision twice.

Insight: This is why documentation is a role in the pipeline and not a chore: it is the integration layer. The tools will never share memory; the pages are the memory they share.

The tools are instances

Step back from the mechanisms and a shape appears: something researches, something executes, something remembers, and something carries decisions between the other three. Every tool in this essay is a hire into one of those seats, and every one is replaceable — the rules file, the queue, the log, and the ledger are plain text, which means any capable agent can read its way into the job in one session. The structure is the design; the tools are instances of it.

That inverts the question I started with. I began by asking which tool to use; I now ask which role is missing, and audition anything for it. And the honest accounting: I have not measured it formally, but iteration runs roughly ten times faster than my hands alone — a launch video in a day without knowing how to edit video, ninety screens with their front-end shipping, research synthesized the week it was gathered. What the pipeline does not supply is taste. The judgment is still mine — written into the files above where the crew can borrow it, and kept, because it was never for hire.

Take the starter

The rules file, request queue, change log, and ledger quoted throughout are the working documents behind NoInfra’s design system and the KriyAI product surfaces. The structure they share is the part that travels.

take it

Take the starter

The whole structure, as one file: the rules template with the real worked lines from this essay, the pass-gate entry format, the three-line log, the ledger and brief templates, the drift checks in both the mechanical and the by-hand version, a fifteen-minute weekly loop, and the day-one order for starting from zero. It is written for any craft — design is the worked example, not the requirement — and it is plain text, so the first thing you can do with it is hand it to an agent.

Download the fileagentic-pipeline-starter.md · Markdown · 12 KB