AI agents for a pre-sales design studio
ARTICLE · AI AGENTS · DESIGN SYSTEMS
Pre-sales is where design work goes to get compressed.
An RFP lands on a Thursday. The response is due Tuesday. By the time the data and engineering leads have sized their parts, the design section is two slides and a stock wireframe nobody believes.
My team built a nine agent pipeline to fix the design half of that. It runs on Claude Code, it is now running on live client pursuits, and this piece is the walkthrough of what each part actually is. Not a framework post. The specific tools, the specific agents, and the specific boundaries between them, because that is the part I could not find written down anywhere when we started.
The plumbing, in one paragraph
Each agent is a markdown file with a defined input, a defined output, and the tools it is allowed to touch. Nothing exotic. The complexity lives in the agent files, not in the plumbing.
THE STACK
→
Claude Code by Anthropic, the runtime
→
Figma Console MCP by TJ Pitre, design file operations
→
Mobbin MCP, design inspiration
→
SAM.gov public API, the scouting stage
→
Our internal design system, the source of truth
The one architectural rule: a human gate sits between every stage. No agent triggers the next agent. A person does.
Stage zero: the scout
The scout is the odd one out. It does not touch design at all.
It polls the SAM.gov public opportunities API alongside a set of procurement RSS and Atom feeds. Everything it finds gets deduped against a ledger file, because the same solicitation appears on four sources under four different titles, and nobody should read the same opportunity four times.
Its output is a shortlist of requests worth a UX team’s time, with a fit assessment. That shortlist is the first human gate. We decide what enters the pipeline. The scout only fills the funnel.
The research agent
First pipeline stage. It takes the brief from whatever we admitted through the gate and produces the discovery groundwork: the domain context, the audience picture, the question set for the client.
The research lands in FigJam, where the team can actually work with it, rearrange it, and strike things out. Research that lands in a document gets read once. Research that lands on a board gets used.
This stage taught us the sharpest scoping lesson of the build. On a live pursuit, the first-pass question set mixed UX discovery with data latency, security enforcement, and metric definitions, none of which belong to a design team. Three iterations of the run prompt later, the questions stayed in the design lane and the engineering questions went back to the people who own them. The agent did not know where the scope boundary was. I did. The agent’s job was giving me a complete surface to cut.
The design system agent
This is the stage that makes everything after it trustworthy, and it is where Figma Console MCP earns its place in the stack.
Figma Console MCP, built by TJ Pitre at Southleft, treats the Figma file as a queryable API. It executes against the Figma Plugin API directly, which means the agent can traverse the full file, read variable collections, resolve alias chains, and extract component structure. Open source, MIT licensed, actively maintained.
The design system agent uses it to load the ground truth: which components exist, which tokens are bound to what, what the semantic layer actually resolves to. Every downstream agent works from that inventory rather than from its own imagination.
IMPLEMENTATION DETAIL
The MCP endpoint surfaces under two different tool namespaces depending on whether you are in an interactive or headless context. Agents worked perfectly in one mode and silently failed in the other until we carried both namespaces in every agent file. If you build on this tool, do that from day one.
The UI generation agent
The stage everyone asks about first, and the one governed by the strictest rule in the system: no invented variants.
If a pattern is not in the design system, the agent flags the gap. It does not draw something close. Values come from bound tokens, semantic and component level deep. An agent that hardcodes a hex value instead of reaching for the token has produced a picture of a design, not a design.
This rule was the hardest behavior to enforce and the most important. Without it, every run produced plausible-looking screens that fell apart the moment a designer opened the file. With it, the output is something a designer can review, reject, and rework, which is the entire point.
The QA audit agent
The stage I have seen nobody else build, and the one I would defend hardest.
It runs after generation and checks the output against the system: are the components real, are the tokens bound rather than hardcoded, did anything drift. It is the automated version of the review a design system lead does when an outside team submits work.
It exists because generation agents are confident, and confidence is not correctness. Having a separate agent whose only job is distrust turned out to be worth an entire stage.
The prototype agent
Takes the audited screens and produces two things: a clickable prototype and a code file for easy review.
The code file matters more than it sounds. A Figma file requires a designer to evaluate. A code file lets the engineers in the pursuit see structure immediately, which means design and engineering are looking at the same artifact in the proposal conversation instead of two different ones.
The proposal agent
Last stage. It assembles the run into a draft proposal doc and a pitch built on our proposal template.
It is deliberately self-contained: it works from the artifacts on disk, the brief, the research, the screens, and does not reach back into earlier stages. If something is missing, it flags the gap, including things it cannot know, like pricing and team composition. Those come from humans, and the honest response is a TBD, not an invention.
What stays human
Nothing this pipeline produces is shippable. The outputs are a starting base for refinement. A senior designer opens every file, rejects things, redraws. The framing we use internally is AI enabled, not AI generated, and the distinction is load-bearing.
And the most important gate is not in the pipeline at all. When I asked publicly which gate people would never let an agent through, the best answer came from Richard Alvarez, our Head of UX: the gate where you decide what problem you are actually solving. An agent can assemble a credible-looking proposal for the wrong ask. Every gate I built assumes the framing coming in was right. That first gate stays human, and I do not see a version of this where it does not.
Credit and setup
The staged structure, each agent with a defined contract at every boundary, came from the SDLC prompt system built by Venu Shivalingappa. I adapted a proven pattern. He invented it. Richard Alvarez and Umang Patel shaped the scope and direction.
The runtime is Claude Code by Anthropic. Design file operations are Figma Console MCP by TJ Pitre. Research boards in FigJam, scouting on the SAM.gov public API.
What is the one gate you would never let an agent through without a human?