Agentic Design Workflows: What They Are and How to Start

I needed a name for what changed in my work when I stopped asking AI for help and started handing it work. “Using AI” did not cover it. Neither did “prompting”. What I was doing was delegating: giving an agent a brief, the rules of my design system, and a definition of done, then reviewing what came back. I have called that an agentic design workflow ever since, and it is the thing this whole site teaches.

Now that the term is spreading through courses and conference talks, it is worth pinning down what it actually means, because the definition is what makes it work.

The definition

An agentic design workflow is design work you delegate to an AI agent, run under your design system’s rules, and review before it ships.

All three clauses carry weight:

• Delegate means the agent executes the steps, not you. It reads the files, runs the audit, builds the component, writes the doc. If you are doing the work with AI suggestions along the way, that is assistance, not delegation.
• Under your rules means the agent is constrained by a context layer you wrote: naming rules, semantic tokens, patterns, voice, templates. Without this, delegation produces confident nonsense at scale.
• Review before it ships means you are still the designer of record. The agent proposes; you accept, edit, or reject. The review gate is what makes delegation safe enough to be useful.

Remove any one clause and the workflow collapses into something else. Delegation without rules is slot-machine prompting. Rules without delegation is a style guide nobody reads. Delegation without review is how broken UI ships with a straight face.

Prompting is a conversation. A workflow is a delegation.

The difference is easiest to see side by side:

	Prompt-assisted design	Agentic design workflow
Who does the work	You, with suggestions	The agent, under constraints
Unit of work	A message	A brief with a definition of done
Context	Pasted into the chat	Lives in files the agent reads
Output	Fragments you assemble	A finished artifact you review
Repeatability	Starts from zero each time	Same workflow, same quality, any day

The last row is the one that matters. A good prompt produces a good answer once. A good workflow produces a good artifact every time anyone on the team runs it, because the quality lives in the system, not in the phrasing of one message.

The three parts every workflow needs

Every agentic workflow I run, and I run them daily, has the same anatomy.

1. A context layer. This is the design system rewritten for a reader that never attends your critiques: rules the agent must follow, semantic tokens that carry intent in their names, patterns it should reach for, the voice it writes in, and templates for the artifacts it produces. If you have read What Is an Agentic Design System?, this is the same foundation. Token naming does more work here than people expect: an agent picking between color.blue.500 and color.action.primary.background is the difference between guessing and knowing.

2. A loop. Brief in, artifact out: you describe the job and the definition of done, the agent works through the steps, and it hands back something finished enough to review. The brief is not a prompt you improvise. It is a short, reusable document: what to do, what files matter, what done looks like, what the agent may not touch.

3. Review gates. A short list of decisions the agent is not allowed to make: publishing, deleting, changing the token architecture, anything expensive to reverse. Everything inside the gates, the agent runs freely. Everything at a gate stops and waits for you. Writing this list down is ten minutes of work and it is the difference between an agent you trust and an agent you babysit.

Your first workflow: the token audit

Start with an audit, not a build. An audit is read-only, so the worst possible outcome is a wrong report, and it produces value on day one.

The shape:

1. Give the agent your rules. A single markdown file is enough to start: your naming convention, your token structure, the three mistakes you keep finding by hand.
2. Write the brief. “Audit these files against the rules. For every violation, report the file, the value found, the rule broken, and the fix. Output a table sorted by severity.”
3. Run it and review. The first run tells you two things: what is wrong in your files, and what is missing from your rules. Both are worth knowing.
4. Keep the brief. Next week the same workflow runs in one line. That is the moment it stops being a prompt and becomes infrastructure.

When the audit workflow feels boring and reliable, that is the signal to move up: component specs, documentation drafts, changelogs, redlines, then generation with your components and tokens as the vocabulary.

Where this goes next

The workflows are the practice; the system underneath them is the discipline. If you want to go deeper:

• What Is an Agentic Design System? covers the foundation the workflows run on.
• Building the Agentic Operating Model covers how a team, not just one designer, adopts this way of working.
• Designing Agentic UI Patterns covers the interface side: what you are designing when the user’s counterpart is an agent.

I publish new workflows, prompts, and templates weekly. The point of every one of them is the same: the agent does the grunt work, and you design.