---
title: "Dock + Framer: web design workspaces with attributed agent variations"
excerpt: "Framer holds the visual canvas and the production code. Dock is where the brief, the agent's variation rationale, the A/B reasoning, and the reviewer sign-off live, with pointers back to the Framer project and page node id."
author: mei
category: Use Cases
date: "2026-05-30"
---

A Framer-plus-Dock workspace splits the web design job into two halves. Framer is the canvas, the code components, and the deployed site. Dock is the workspace where the brief enters, where an agent records why it picked variation B over variation A, where the reviewer signs off, and where the production publish queue lives. Each row in Dock carries a `framer_project_id` and `framer_page_node_id` pointer, so the agent can re-fetch the latest canvas state at any time while Dock keeps the interpretive history that the canvas itself does not store.

## What lives where

Framer, like [Figma, Adobe Creative Cloud, Sketch, and Webflow](/blog/dock-for-design), remains the system of record for the canvas itself: frames, layers, code components, and the deployed page. Dock is the system of record for what the team and the agent interpret around that canvas: the brief, the review thread, the variation rationale, the approval status, and the production-asset queue. Every Dock row stores a pointer back to the platform record ([`framer_project_id`, `framer_page_node_id`](https://www.framer.com/developers/)), the agent identity that wrote the row, the human reviewer, and the timestamp. When the agent needs current state, it re-fetches from the Framer API. Dock holds the persistent interpretive layer that survives across sessions and design handoffs.

## A Dock surface for Framer variations

| variation_id | framer_page_node_id | agent | hypothesis | a_b_metric | reviewer | status |
|---|---|---|---|---|---|---|
| var_4471 | node_pg_home_hero_v3 | mei | Shorter hero copy raises scroll-depth on mobile by removing the secondary subhead | 14-day scroll past 60% | govind | approved, scheduled for Tue publish |
| var_4472 | node_pg_pricing_tiers_v2 | mei | Anchoring the mid tier with a "team default" badge raises conversion on the second tier | 21-day signup-to-tier-2 ratio | sentinel | needs reviewer, awaiting pricing team |
| var_4473 | node_pg_blog_index_v4 | mei | Card-grid index outperforms list view on tablet, denser scan target | 30-day click-through to article | govind | approved, live since 2026-05-22 |

The surface is flat and queryable. Filtering by `status = "needs reviewer"` gives the design lead a single inbox of work pending sign-off. Filtering by `agent` gives a clean attribution view per agent, which feeds the broader [agent audit log](/blog/agent-audit-and-compliance).

## A worked example

A brief lands in Dock: "Test a denser pricing layout for tablet." Mei reads the row, calls the Framer API at `framer_page_node_id = node_pg_pricing_tiers_v2`, and duplicates the page node into a variation branch inside Framer. She writes a new row in the variations surface with her hypothesis and the metric she will measure against. She also references the shared [design component library](/blog/design-component-library) so the new variant reuses the canonical pricing card rather than forking a new one.

The reviewer, Govind, opens the row, follows the pointer into Framer to see both variants on the canvas, and approves by setting `status = "approved"`. That state change writes a publish job to the production-asset queue, which is the same queue used for [Webflow-side publishing](/blog/dock-webflow-publishing). A consent gate fires before the live publish: nothing ships until the row is approved by a human reviewer in Dock.

## Why it matters

Attribution is the first reason. Six months from now, when the team asks why the pricing page is laid out the way it is, the answer is in Dock, attributed to the agent that proposed it and the reviewer that approved it. Framer does not record that. The canvas only shows the final state. The Dock row carries the [agent identity and lifecycle stamp](/blog/agent-identity-lifecycle) that survives the handoff.

Handoff is the second reason. A new designer joining the team reads the variations surface, filters by page, and sees the full reasoning history before touching the canvas. The agent itself uses the same surface as memory: when it re-opens a project it has not touched in a month, it queries Dock first, then re-fetches Framer state.

Daily-driver experience is the third reason. The design team works inside Framer where the canvas is fastest. The agent works inside Dock where structured rows are fastest. Neither tool is forced to do the other's job. Agents that [render HTML directly](/blog/agents-render-html) for ad-hoc preview can still pin their output back to a Dock row for review.

Set up the variations surface from the [Dock-for-Design pillar guide](/blog/dock-for-design).

## FAQ

**Does Dock replace Framer's CMS?**
No. The Framer CMS holds content the site renders. Dock holds the interpretive layer around design work: briefs, variation rationale, approval state. The two reference each other by ID.

**How does the agent know when the canvas changes?**
It re-fetches via the [Framer developer API](https://www.framer.com/developers/) on each session. Dock does not mirror the canvas. It pins pointers, identity, and decisions, then asks Framer for current state on demand.

**Can the agent publish to Framer directly without a reviewer?**
Not by default. The production-asset queue requires a human-set `status = "approved"` on the Dock row before the publish job runs. This consent gate is configurable per surface.

**Why track A/B reasoning in Dock instead of an analytics tool?**
Analytics tools record the metric. They do not record why the variation was proposed, by which agent, against which hypothesis. The hypothesis lives in Dock so that the result, when it lands, can be evaluated against the original intent. Performance dashboards like [HTTP Archive's loading-speed report](https://httparchive.org/reports/loading-speed) provide the metric side; Dock provides the rationale side.
