The layout layer the canvas used to hide

A useful community reply does not ask for a bigger button. It names the missing layer.

That is what happened under the Open Design 0.8.0-preview discussion. The launch thread argued for two shifts: stop treating the canvas as the primary work unit, and make the agent the first-class design worker. One reply agreed with the direction, then pointed at the hard part: when the canvas disappears, users still need a way to understand what the agent made before they can edit it with confidence.

The phrase in the reply was “Layout Understanding Layer.” It is a good name because it refuses the lazy answer. Agent-native design cannot mean “trust the screenshot.” It needs a readable model of the artifact: sections, intent, editable parts, stable references, and suggested edit moves. This post is an attempt to take that reply seriously — to sketch what such a layer could carry, where it should live in Open Design, and why it is a contribution path rather than a roadmap promise.

The canvas gave designers spatial confidence

Figma’s canvas is not only a drawing surface. It is also an explanation surface. You can zoom out, see the page hierarchy, click a frame, inspect constraints, rename layers, and understand where one piece of the work ends and another begins.

What you actually lose when the canvas goes away

That understanding is easy to underestimate until it is gone. A generated landing page can look correct in a sandboxed preview and still be hard to direct. The problem is not the pixels — it is the absence of a shared vocabulary between the human and the agent.

“Make the hero more confident” is useful only if the agent and the human agree on what the hero is. “Tighten the pricing section” works only if the artifact carries a stable section identity across revisions. Without that, every instruction degrades into pointing: the designer describes a region by its position (“the second block from the top”), the agent guesses from the rendered output, and the next regeneration quietly renumbers everything. The canvas used to absorb this cost silently. It named the parts for you, kept those names stable while you worked, and let you select one without describing it.

The clarity is worth keeping even if the unit is wrong

This is the part of the #DeFigma argument that needs care. The canvas may be the wrong unit of work for an agent-native system — it assumes a human dragging rectangles, not an agent writing files — but the clarity people got from the canvas is still valuable. The mistake would be to treat “drop the canvas” and “drop the understanding the canvas provided” as the same decision. They are not. Open Design has to move that clarity into the artifact model, not throw it away. The layout layer is the name for that relocation.

Open Design already has the right primitives

The reason this proposal fits Open Design is that the project is already built around explicit contracts. A skill is a SKILL.md file. A design system is a DESIGN.md file. A plugin adds an open-design.json sidecar. Nothing in the system is a binary blob you have to reverse-engineer; the contracts are text, and text is something both an agent and a human can read. The mechanics are covered in 31 skills, 72 systems: how the Open Design library works, and the product argument is in Why we built Open Design as a skill layer, not a product.

The layout layer should follow the same pattern. It should be text the agent can read, state the UI can render, and metadata another agent can reuse. If it cannot satisfy all three at once, it is the wrong shape.

In repo terms, that points at three surfaces:

Surface	What it should carry
Artifact manifest	Stable IDs for sections, components, assets, and generated files
Plugin snapshot	Which skill, design system, inputs, and pipeline stages produced the artifact
Review UI / headless output	A layout map, editable aspects, and suggested edit intents

The important constraint: the layer should not become a second proprietary canvas. The failure mode to avoid is rebuilding Figma’s scene graph under a new name — a rich, app-specific structure that only the Open Design UI can render and that dies the moment you leave the app. The layout layer should instead be a plain artifact map that travels with the files, so a contributor can read it in a text editor and a different agent can consume it without an SDK.

A wireframe layout skeleton lifting out as its own selectable layer above a blank canvas, in a green frame on a near-white editorial ground — The layout layer is the structure the canvas kept implicit — pulled out where an agent and a human can both read it.

A practical shape for the layout layer

Here is the smallest version that would make agent-native design feel less opaque:

Each generated artifact gets stable semantic IDs: hero, proof-strip, pricing, faq, final-cta.
Each ID carries an intent sentence: “Explain the product promise in one screen,” not “top section.”
Each section lists editable aspects: copy, density, layout, color, media, motion, data source.
Each generated file links back to the section ID that produced it.
Each review pass emits suggested edit intents: “shorten hero headline,” “increase contrast in pricing cards,” “split testimonial block.”
The UI renders this as a navigator, while headless users receive the same structure as JSON or Markdown.

What a manifest could actually look like

The point of writing it down is that the structure is unremarkable — which is exactly why it can be a public contract instead of a private trick. A manifest for a generated landing page might read like this:

{
  "artifact": "landing/index.html",
  "producedBy": { "skill": "magazine-poster", "system": "linear", "stage": "compose" },
  "sections": [
    {
      "id": "hero",
      "intent": "Explain the product promise in one screen",
      "editable": ["copy", "density", "media"],
      "files": ["landing/index.html#hero", "landing/hero.css"]
    },
    {
      "id": "pricing",
      "intent": "Let a visitor self-select a plan without scrolling back",
      "editable": ["copy", "layout", "data-source"],
      "files": ["landing/index.html#pricing", "landing/pricing.json"]
    }
  ],
  "suggestedEdits": [
    { "target": "hero", "intent": "shorten headline to one line" },
    { "target": "pricing", "intent": "drop from three plans to two" }
  ]
}

None of those keys are exotic. sections is a list, editable is an enum, files is a back-reference. The value is not in the schema’s cleverness — it is in the fact that the IDs survive a regeneration, so the same pricing block is still pricing after the agent rewrites it twice.

That is enough to let a designer say, “Change pricing from three plans to two,” and enough to let a code agent patch the right file without guessing from pixels. The instruction resolves to a section ID, the section ID resolves to a set of files, and the edit lands where it was meant to.

Why this is a contribution path, not a feature request

It also gives the community a clean contribution path. A contributor does not need to redesign the product to help here. They can write a skill that emits a manifest for one artifact type, a review atom that proposes edit intents, a manifest extension that adds a field other skills can read, or a test case that asserts section IDs stay stable across a regeneration. Each of those is a small, mergeable change that makes one output less opaque — and because the layer is plain text, two contributors working on a deck and a mobile screen do not have to coordinate a shared binary format. The layout layer becomes a public contract, not a private capability buried inside the app.

What to do next

If this is the kind of problem you want to work on, contribute a small skill or plugin that makes one artifact easier to inspect. Start with a concrete output: a landing page, a deck, or a mobile screen. Add stable section IDs, describe the editable aspects, emit them as JSON or Markdown alongside the artifact, and open the PR with a before/after artifact so a reviewer can see the difference an inspectable layer makes.

This is still a direction, not a shipped feature — the value of naming it now is that the primitives already exist, so the work is additive rather than a rewrite.

Contribute a skill.

31 skills, 72 systems: how the Open Design library works — the current file-driven primitives underneath the proposal
Why we built Open Design as a skill layer, not a product — the product shape that makes public artifact contracts possible
The open-source alternative to Figma — where “drop the canvas” lands against the incumbent that made the canvas central