The persistent brief-and-review table lives in Dock. The agent picks up a brief row, drafts variations in Figma, then writes one Dock row per variation with the rationale, the figma_node_id, and the open questions. The design lead reviews every variation in one queue, approves or rejects with a comment, and the row carries that decision forward to production. The brief stops being a Slack thread. The review stops being a string of canvas pins. Both become rows your editors can scan in a sitting.
Figma stays the system of record for the canvas: frames, layers, components, the design source files. Sketch, Adobe Creative Cloud, Webflow, and Framer keep the same role inside their tools. Dock is the system of record for what the agent and the team interpret around the canvas: the brief text, the review thread, the variation rationale, the approval status, the production-asset queue. Each Dock row carries a pointer to the platform record (figma_file_key, figma_node_id, webflow_collection_id), the agent identity that drafted the work, the reviewer, the decision, and a timestamp. The agent re-fetches Figma data via fresh API reads when it needs current state, since frames move and components rename. Dock holds the persistent interpretive layer that survives across sessions, model swaps, and design-lead handoffs. The wider architecture is mapped in the Dock for Design pillar.
Brief and review table
| brief_id | brief_title | figma_file_key | figma_node_id | drafted_by | variation_rationale | reviewer | decision | decided_at |
|---|---|---|---|---|---|---|---|---|
| BR-0411 | Pricing hero, Q3 refresh | aB12xY |
4:218 |
agent:pixel | Tightened headline to 7 words, raised contrast on CTA per WCAG AA | maya@studio | approved | 2026-05-28 14:02 |
| BR-0411 | Pricing hero, Q3 refresh | aB12xY |
4:241 |
agent:pixel | Alt layout, two-column with screenshot, tests product-density angle | maya@studio | rejected, asked for one-column with screenshot below fold | 2026-05-28 14:04 |
| BR-0412 | Feature card icon set | aB12xY |
7:88 |
agent:pixel | 12 icons drawn from existing 24px component, stroke 1.5 for consistency | rohan@studio | approved | 2026-05-29 09:31 |
A worked example
A product manager files brief BR-0412: a twelve-icon set for the feature grid. The agent (agent:pixel) reads the brief row, fetches the live component library from Figma, and drafts the icons inside the existing 24px grid. It writes one Dock row per icon variation with the figma_node_id, the stroke weight, and a short rationale tied to the component-library rules covered in the design component library piece. The design lead Rohan opens the review queue, filters by decision = pending, and walks the rows. He approves ten, rejects two with a note. The row's decision column flips, the timestamp lands, and the agent re-reads the rejected rows, redraws, and posts new variation rows. Once every row is approved, the brief moves to the production-asset queue described in the brand-asset production sub-essay, and the publish step runs behind a consent gate.
Why it matters
Attribution holds because every row names the drafting agent and the reviewing human. When the agent reorganizes a hero section six weeks later, the lead can trace which variation was approved, by whom, and why. The same audit trail powers agent audit and compliance for design work, which is rarely treated as auditable but should be.
Handoff holds because the brief row and its variation rows do not depend on a single Slack channel or a single reviewer remembering context. A new design lead opens the queue and reads the rationale column. The agent identity stays stable across the lifecycle described in agent identity lifecycle, so the same agent:pixel row history follows the agent across model versions.
Daily-driver experience holds because the design team reviews in one place. The canvas is for drawing. The Dock queue is for deciding. The Dock-Figma design-ops integration keeps the two layers in sync without forcing the lead to context-switch between Figma comments, Slack threads, and a Notion brief doc. According to Nielsen Norman Group's DesignOps 101, DesignOps exists to orchestrate people, processes, and craft so design scales; a persistent decision layer is what that orchestration looks like once an agent is on the team. The same group's note on design critiques treats the review conversation itself as the artifact worth preserving, which is exactly what the rationale and decision columns capture.
Ready to put briefs and reviews in one queue? Start with Dock.
FAQ
Where does the brief actually live, Figma or Dock?
The brief lives in Dock as a row. The canvas work it produces lives in Figma. The Dock row carries figma_file_key and figma_node_id so any reviewer or downstream agent can jump to the frame.
Does the agent edit the Figma file directly? Yes, through the Figma API or plugin, but the rationale for every edit is written to a Dock row. The canvas holds the result. Dock holds why the result looks the way it does.
What stops the agent from publishing a rejected variation?
The decision column. The production queue filters on decision = approved only. Publish steps for live web surfaces also pass through a consent gate, so a rejected row cannot reach Webflow or Framer without an explicit human approval event.
Can a design lead reject in bulk?
Yes. The review queue is a Dock table, so the lead can multi-select rows, set decision = rejected, and write a single shared comment. The agent reads the rejected rows on its next pass and redraws.