From a Slack request to a finished Figma design in minutes. An AI agent I researched, sold to leadership, and built — AI fluency turned into a system that scales design across the org.
ROLEResearcher, strategist, builder
COMPANYDocusign
STATUSRUNNING · EARLY PHASE
STACKSlack → Jira → Claude subprocess → Figma
01Slackdesigner files a design request
→
02Jiraworkflow opens a ticket
→
03Pan agentpolls, picks it up, designs
→
04Figmadesign lands, ready to review
the pipeline — one front door, a queue, and an agent that ships to figma
5–10 minrequest to finished design
every 3 minagent polls the queue during work hours
1 front doorcentralized AI tooling for the org
meet pan
Pan (internal codename Kreacher) is an autonomous design agent. A designer or PM files a request in Slack; Pan opens a Jira ticket, picks it up, spawns a Claude subprocess to do the work, and pushes a finished design to Figma — in 5 to 10 minutes. Then it keeps iterating from Jira comments, the same loop a human designer runs, at machine speed.
pan — the agent's face, borrowed from a certain fictional house-elf
start with research, not a demo
I put forth an internal research study to understand how designers, product managers, and front-end engineers were actually using AI — and where the biggest pain points were. I synthesized the findings into an opportunity/solution tree to focus on the area with the most impact: system misalignment. Everyone was building their own bespoke AI tools, and none of it connected. I sold that framing to leadership — influencing without owning the roadmap — and got the mandate to build.
01 — the front door: a slack request
Pan lives where the work already happens. A designer opens a Design Request workflow in Slack, names the task, picks a fidelity, drops in a Figma link and the PRD, and describes what they need. No new tool to learn — just a form in a channel.
the slack "design request" workflow — name, fidelity, figma link, and the askpan confirms — task started, jira ticket opened, iterate by commenting on the ticket
02 — the queue: a jira ticket
Every request becomes a Jira ticket. That's deliberate: Jira is the work-tracking and queuing system, which gives the whole thing built-in flexibility. It's also where future "human-in-the-loop" rules will live — flagging requests that are missing tasks or carry risk for a designer to review before Pan attempts them.
ticket EPX-369 — the request, the PRD, and the figma link, all in one place
03 — the agent picks it up
Pan polls Jira for open tickets every three minutes during work hours. When it finds one, it spawns a Claude subprocess, does the design work directly in Figma, and reports success back with a link — then goes right back to polling.
agent log — poll → received → processing (spawning claude subprocess) → success → poll
04 — the output
Minutes later, a real, on-system design is waiting in Figma. Here Pan built an admin dashboard for AI token consumption straight from the PRD — metric cards, usage breakdowns, allocation controls, alert thresholds, and a cost table.
pan's output — the admin AI usage dashboard, generated from the ticket
then it iterates
The first design is a starting point, not the end. Leave a comment on the Jira ticket and Pan picks the feedback up and revises. Here I asked for a token-budget progress bar with a reset date — and it delivered.
the ask — a jira comment requesting a progress bar and reset datethe revision — "token budget · 75% remaining" bar, added and dated
why figma, not code
Instead of jumping straight to a coded prototype, all generated work lands in Figma. That's intentional: teams that depend on Figma as their source of truth — accessibility engineering, localization, marketing, support — stay in the loop instead of being cut out by an AI shortcut.
why it scales
Centralized tooling, easy front end. Several designers and PMs had built personal agents; none scaled to the org. Pan gives everyone one front door via Slack.
Jira as the work queue. Using Jira for tracking and queuing means built-in flexibility — including future human-in-the-loop rules for risky or incomplete requests.
early results
Still in its early phases, Pan has shown great promise. Designers and product managers use it to produce wireframes for PRDs and make quick revisions to higher-fidelity designs — reclaiming hours of production work for higher-leverage thinking.