Like most designers exploring AI, I've been on a constant journey of trying new things — the one thread that stays the same in an era that keeps changing everything else.

From prompt engineering, to iterating on context, to building Skills and creating Agents — the design industry, and the software industry more broadly, has been turned upside down in the span of a year. My own identity as a manager has shifted too. From managing a team, to managing Agents.

Setting up a virtual design team is a genuinely interesting problem.

01

Roles in a Design Team — The Role Split

In a real design team, you have Design Operations, Researchers, Designers, and of course, someone managing all of it. These are distinct roles that require different ways of thinking — and they need to keep each other in check. The person doing the design shouldn't also be the person reviewing it. That's basic professional practice.

We also know that the more specialized an Agent is, the better it performs.

So the first thing I did was define five core roles:

Five roles — each independent
Research Specialist Competitive analysis and user research — the team's information antenna.
Requirements Writer Translates vague ideas into clear design briefs.
Design Specialist The core executor, making design decisions within established visual guidelines.
Usability Evaluator Rigorously audits proposals, looks for problems, no excuses.
Component Auditor The last checkpoint, ensures outputs align with the existing component library.
Each role is independent — with own persona (System Prompt), own model, own tools, and own state to maintain.

The most immediate benefit of this separation: context stays clean. The Research Specialist doesn't need to know component library specs. The Component Auditor doesn't need to know user research methodology. Everyone stays focused on what they're actually supposed to do.

02

How Does Knowledge Get Shared? — Decoupling Assets from Roles

Five roles solved the "who does what" problem. But it quickly created a new one.

WCAG accessibility standards, for instance — Research references them, Design follows them, Evaluation checks against them. If I write a copy into each role's prompt, it seems fine at first. Until the day I need to update those standards.

That's when I realized the role-splitting approach had only solved half the problem. Roles define who does what. But knowledge itself — methodologies, standards, guidelines — shouldn't belong to any single role. It should be a shared team asset.

So I did another round of splitting. This time, not roles — knowledge. I broke each role's "brain" into four distinct types of files, organized in a folder inside the project:

Four knowledge types — stored once, referenced by all
Role Definition Who this Agent is, where its responsibilities begin and end, what it should touch and what it shouldn't.
Methodology Reusable professional knowledge that any role can pull from, like "how to run a user goal analysis" or "how to conduct a heuristic evaluation."
Standards Hard constraints that outputs must meet, like visual tokens and accessibility requirements.
Workflow The sequence of prescribed actions, like "audit the component library before generating a PR."

After this, the knowledge fragmentation problem disappeared. WCAG standards live in exactly one place. I update that one file, and every role that uses it — Research, Design, Evaluation — picks up the latest version on its next run.

That's what decoupling assets from roles actually buys you: change the asset once, every role gets it.
03

The Evaluator's Role — Flag It, Don't Auto-Reject

The Usability Evaluator is supposed to be harsh. Its job is to find problems, not validate decisions. But that raises a question: if it flags an issue, does that automatically mean the proposal gets sent back?

My answer: not necessarily — but the findings should always be recorded and surfaced.

From a pure token-economics perspective, routing feedback back to the Design Agent, triggering a regeneration, and running the whole loop again is expensive in many scenarios. The more pragmatic setup is to have the Evaluator report what it found, rather than automatically kicking off another pass.

My hope is that as loop-based and graph-based agent frameworks become more flexible, I'll be able to get purposeful iterative refinement without the token cost becoming unmanageable.