Loom Book a conversation

See it · Shape it · Govern it · Run it

The next level of your design system.

Loom turns the system you have, or the one you are missing, into clear, governed decisions that your teams and your AI tools follow. Your product keeps its look. Your people stay in control, with expert help and agents doing the routine work.

Take the free health check Book a conversation

About three minutes, and your answers stay in your browser. Or see a real audit and the product tour.

Built and backed by a group of design-system specialists.

Four threads, one system. Your look stays; the structure underneath becomes clear.

The problem

Design systems are run by too few people. It shows.

Most systems were built for an earlier product, then left to one or two people to look after. Now AI tools build screens every day, and they copy whatever they find.

  • 16%of design systems are run by one person
  • 23%of teams say they are adequately resourced
  • 56%name staffing as their biggest challenge

Source: zeroheight Design Systems Report 2026 (survey closed 14 Jan 2026, 147 respondents), figures as published in the “We need more people” webinar.

Systems drift and break.

Raw values bypass tokens, teams rebuild components locally, and guidance stops matching the code. Nobody has time to find all of it, let alone fix it.

Agents amplify what they find.

Figma said it plainly at Config 2026: agents without design-system context produce interface that feels “unfamiliar and generic”. Given a broken system, they produce broken interface faster.

Figma, Config 2026 announcements

The tools document. They do not repair.

Supernova, zeroheight, Knapsack, Figma and Storybook now serve your system to agents over MCP. Each assumes a healthy system already exists. Serving a broken one spreads the problems further.

Sources: Supernova, zeroheight, Knapsack, Figma, Storybook

One system, four jobs

See it. Shape it. Govern it. Run it.

Most tools do one of these. A design system needs all four, and they work best when they share one record of what was decided and why.

Our aim: design systems that never fall behind.

  1. See it

    Know what you really have, before you change anything.

    • A free health check
    • Usage intelligence across your code, with Figma next
    • A score per area, findings ranked by impact
    See a real audit

  2. Shape it

    Turn it into a next-generation system, without changing how it looks.

    • Typed tokens and component contracts
    • React and React Native components from one contract, checked before review (three so far)
    • Brand, illustration and microcopy as rules (in development)
    • Clickable prototypes from your own components (partly working)
    How creation works

  3. Govern it

    Decide once, at the right level, and see where reality differs.

    • Layers from global brand to product (concept)
    • Owners for each area; autonomy modes (concept)
    • Drift checks against your rules on demand; continuous monitoring and a timeline are concepts
    How change works

  4. Run it

    Let agents do the routine work, on your own model, under your rules.

    • Agents through MCP
    • An unmet-needs radar (concept)
    • Figma and Storybook from the same source (partly working); CI planned
    How teams work with it

01 · See it

Know what you really have, before you change anything.

The health check asks plain questions and shows your gaps area by area. With access to your code, Loom’s audit goes further: it reads every token, component and screen, and reports where the system is used, bypassed or missing.

Try it on your own code

Paste your CSS or tokens. See a first reading at once.

Runs in your browser · a subset of the full audit

Nothing is sent anywhere. The checks are Loom’s own audit code, built into this page: it reads raw colours, spacing, token tiers, modes and contrast, and scores the two areas a stylesheet can show. The full audit reads your whole repository.

Runs on this page only: no upload, no storage, no tracking. Do not paste secrets anyway.

Example result, computed by the same code for the CSS on the left. With scripting on, it updates as you type.

15 / 100 on the subset · grade F · Foundations and tokens 28 · Usage 0

  1. High
    2 of 2 semantic/component tokens hold literals instead of aliasing a lower tier
  2. High
    3 colour pairs below WCAG AA
  3. High
    11 raw colour values in styles (8 distinct)
  4. Medium
    13 raw pixel values with no spacing scale to check against

Before · an app with no design system

takenote a public, open-source notes app

Audit result, 2026-10-24 · github.com/taniarascia/takenote · MIT

14/ 100 overall
  • 91raw colour values in product code (44 distinct)
  • 0 / 43components with a usage contract
  • 0 / 37components an agent could find by name with an import
  • 117raw pixel values outside a spacing scale
  • Foundations and tokens27
  • Components14
  • Patterns and pages
  • Usage17
  • Governance10
  • Brand, illustration, microcopy and localisation0
  • Tools and sync26
  • AI readiness0

Top findings

  1. Critical
    0 of 43 components have a usage contract

    Contract stubs are generated for every component with the evidence we could find and explicit 'missing' fields for purpose, when/when-not, states, behaviour, a11y and content.

  2. High
    37 proto-tokens live in preprocessor variables with no types, roles or descriptions

    Promote these to typed DTCG tokens and add a semantic layer (text, surface, border, action, status) on top; generated proposal in artefacts/tokens.

  3. High
    5 role tokens duplicate another token's literal colour

    Replace each duplicate with an alias ({palette.x}); two literals with the same value drift apart on the first edit.

A strong system that still has real gaps

Story Atelier the design system of Seamline, the first converted with Loom

Audit result, 2026-10-24 · private repository, summary only

59/ 100 overall
  • 455uses of system components in the product
  • 3local copies of system components
  • 63raw pixel values outside a spacing scale
  • 12interface elements in use with no contract or rule
  • Foundations and tokens63
  • Components56
  • Patterns and pages100
  • Usage58
  • Governance49
  • Brand, illustration, microcopy and localisation24
  • Tools and sync43
  • AI readiness77

Top findings

  1. High
    48 of 48 semantic/component tokens hold literals instead of aliasing a lower tier

    Make every semantic token an alias of a primitive and every component token an alias of a semantic token. Without aliases a palette change does not propagate and dark/high-contrast modes cannot remap roles without touching components.

  2. High
    3 role tokens duplicate another token's literal colour

    Replace each duplicate with an alias ({palette.x}); two literals with the same value drift apart on the first edit.

  3. High
    Required modes missing: dark, high contrast

    Declare light, dark and high-contrast as token modes that remap semantic aliases, and contrast-check every pair in every mode. A recorded 'not supported' decision is honest but does not meet the 2026 baseline.

Explore the audit

Eight areas, one rubric. Pick an area to see what was checked and found.

Real audit output
Story Atelier: scores per area, overall 59 of 100, with takenote (14) for comparisonFoundationsComponentsPatternsUsageGovernanceBrandToolsAI

Story Atelier (filled) and takenote (outline), from the audit reports above. With scripting on, you can switch systems and open each area’s checks and findings.

Real output from Loom’s audit engine, run on 24 October 2026. Static analysis only: no code is executed. Seamline is the founder’s own product and its code is private, so only the summary is shown.

Take the free health check

02 · Shape it

Change the structure. Keep the look.

Conversion turns what you have into a next-generation system: typed tokens and one contract per component, generated from your code with the evidence for each value. Rules for brand, illustration and microcopy come next. Loom also writes components from its contracts and checks them before your team reviews them; today that covers three components.

  • Tokens

    DTCG tokens working · tiers and modes in development

    Typed tokens in the DTCG 2025.10 format, generated from your code with the evidence for each value and checked against the format’s rules for every type. Today: a primitive and a semantic tier in one file. In development: a component tier, and modes for themes and brands. Planned: build outputs for CSS variables, Tailwind and CSS-in-JS.

  • Contracts

    Working

    Conversion drafts one contract per component from your code: purpose, anatomy, API, states, behaviour, accessibility and content, with every gap marked as a question for your team. For the components Loom writes (three so far), behaviour is also written as data, so React and React Native are tested against the same rules.

  • Components, written and checked

    Working for three components

    Loom writes components for React and React Native from one contract and checks them before review: axe on every state, keyboard and focus scripts, and parity between platforms. Today this covers three components (Button, Switch and Dialog); writing your own components this way, and visual regression checks, are planned. A person gives the final approval.

  • Brand, illustration and microcopy

    In development

    Brand rules, a managed illustration library and a message catalogue become checks that agents and reviewers can run, instead of documents nobody opens.

Before and after

The same button. A new structure underneath.

Tokens from real output · rewrite by hand

The base button rule of takenote, an open-source notes app (MIT), before and after conversion. After conversion, the same rule reads the tokens Loom generated for it. Move the slider: the rule converts value by value, and the look stays the same.

Before · _buttons.scss (takenote)
%buttons {
  border: 2px solid $primary;
  border-radius: 0.3rem;
  background: $primary;
  color: white;
  font-weight: 600;
  font-size: 1rem;
  padding: 0.5rem 0.75rem;
  margin: 0 0 0.5rem 0;
  line-height: 1;
}
After · on generated tokens
.button {
  border: 2px solid var(--semantic-action-primary);
  border-radius: 0.3rem; /* no token yet */
  background: var(--semantic-action-primary);
  color: var(--palette-gray-10);
  font-weight: 600;
  font-size: 1rem;
  padding: var(--space-3) 0.75rem; /* 12px: off scale */
  margin: 0 0 var(--space-3) 0;
  line-height: 1;
}

What each token resolves to, in the generated file

  • var(--semantic-action-primary) → {proto.primary} → #5183f5 needs a human decision
  • var(--palette-gray-10) → #ffffff needs a human decision
  • var(--space-3) → 8px needs a human decision

Token names, values and statuses are copied from the token file Loom’s conversion generated for takenote (24 October 2026). The after rule was written by hand for this page from those names; rewriting stylesheets automatically (codemods) is a concept.

One contract, two platforms

Working for three components

Each component Loom writes has one contract. Loom writes it for React and React Native and tests both against the same behaviour; today that is three components. Every pilot includes a parity report like this one.

An illustrative summary of the parity checks for the Button contract. Both writers and their tests work today for three components; the React Native tests run in a simulated environment (Jest), not yet on devices.

CheckReactReact Native
StatesDefault, hover, pressed, disabled, busyDefault, pressed, disabled, busy
Role, name and stateaxe on every stateAccessibility tree on every state
FocusKeyboard scriptsScreen-reader focus order
TokensCSS variablesA theme object from the same tokens
ContentMessage catalogueThe same message catalogue

Prototype in your system

Partly working

If a design system does not let you prototype, test and explore ideas quickly, it is not doing its job. Compose a screen and Loom builds a clickable prototype from your system’s own components, checked against its rules as you go. Describing a screen in words, and letting an agent build it, comes next.

Working today, for the reference system: the workbench Composer builds pages from system components. The product tour shows it as a screenshot. Next: other systems, and prototypes built by agents from a written brief, held to the same rules.

  1. Describe “A settings page with a danger zone”
  2. Compose Only system components, with their real props and states
  3. Check Tokens, contracts and accessibility rules, as you build
  4. Click through A prototype you can test with people the same day

How Loom transforms the system you have

Loom starts from your Figma library and your code in their current state. It audits them, captures your look as tokens and contracts, migrates your products with codemods and agent pull requests, and leaves you with one governed system in code, Figma, documentation and agents.

Working today: the audit, and the tokens and contracts generated from it. Codemods and agent pull requests with before and after screenshots are concepts.

Your system todayThe Figma library and the code, as they really are
AuditEvery token, component and screen read and scored
Tokens and contractsYour look, captured as typed tokens and one contract per component
MigrationCodemods for mechanical changes; agent pull requests with before and after screenshots
A governed systemIn code, Figma, documentation and every agent, kept in step
Every change is a reviewable pull request
Your system todayThe Figma library and the code, as they really are
AuditEvery token, component and screen read and scored
Tokens and contractsYour look, captured as typed tokens and one contract per component
MigrationCodemods for mechanical changes; agent pull requests with before and after screenshots
A governed systemIn code, Figma, documentation and every agent, kept in step

How creation happens

A need becomes a contract, the contract uses tokens, and Loom writes the component for React and React Native. Automated checks run before a person reviews it, and the release arrives as a pull request.

Working today for three components: contract, tokens, writing for React and React Native, and automated accessibility, keyboard and parity checks. Visual checks and the release step (pull request, version and changelog) are concepts.

A needFrom a team, an agent or the unmet-needs radar
ContractPurpose, anatomy, states, accessibility and content
TokensPrimitive, semantic and component tiers
Loom writes itReact and React Native, from the same contract
Automated QAAxe on every state, keyboard and parity checks
Human reviewThe area owner approves or asks for changes
ReleasedPull request, version and changelog
Prepared and checked by LoomDecided by your team
A needFrom a team, an agent or the unmet-needs radar
Prepared and checked by Loom
ContractPurpose, anatomy, states, accessibility and content
TokensPrimitive, semantic and component tiers
Loom writes itReact and React Native, from the same contract
Automated QAAxe on every state, keyboard and parity checks
Decided by your team
Human reviewThe area owner approves or asks for changes
ReleasedPull request, version and changelog

03 · Govern it

Decide once, at the right level. See where reality differs.

Larger organisations run a system of systems: a global brand, regional needs, digital brands and products. Loom is designed to model each layer with its own owners and rules. Your repo and Figma stay the sources of truth; Loom checks them against your rules and flags what drifts.

Layers, each with an owner

A global brand at the top, regions below it, then digital brands and products. Each layer inherits everything above it and adds what it needs.

Concept: layers are in design. The product tour shows them with sample data.

Global brandOwner: brand and core system team
Region: EuropeOwner: regional design lead
Region: AsiaOwner: regional design lead
Digital brand: consumerOwner: digital brand team
Digital brand: professionalOwner: digital brand team
Product AOwner: product team
Product BOwner: product team
Product COwner: product team
Product DOwner: product team
Global brandOwner: brand and core system team
Region: EuropeOwner: regional design lead
Digital brand: consumerOwner: digital brand team
Product AOwner: product team
Product BOwner: product team
Region: AsiaOwner: regional design lead
Digital brand: professionalOwner: digital brand team
Product COwner: product team
Product DOwner: product team

Every rule says how far it can bend

Locked
No lower layer may change it. Accessibility minimums, logo use, consent.
Extendable
Lower layers may add to it, but not change what exists.
Overridable
Lower layers may replace it, with a recorded reason and a review date.
Default
A starting point that lower layers are expected to tune.

A team can break a rule it owns. The break is flagged, and the people involved are told.

System of systems

What may a product team change? Stand in a layer and see.

Concept · sample data

Each rule is set at one layer and says how far it bends below it. Pick the layer you stand in, hover a rule to see where it comes from, and try a change. The organisation and its rules are sample data; layers are in design.

Seen from Product A (sample data)
RuleSet byLevel
Text contrast of at least 4.5:1Global brandLocked
Logo clear spaceGlobal brandLocked
Consent and privacy noticesRegion: EuropeLocked
Colour paletteGlobal brandExtendable
Spacing scaleGlobal brandOverridable
Voice and toneDigital brand: consumerExtendable
Button corner radiusDigital brand: consumerDefault

Autonomy is set for each area, by its owner

The modes work like the permission modes of a coding agent such as Claude Code, with allow and deny rules on top.

Concept
  1. Observe

    Loom reports what it sees. Nothing changes.

  2. Suggest default

    Loom drafts changes. A person approves each one.

  3. Auto with guardrails

    Routine changes merge when every check passes. Anything else waits for a person.

  4. Full

    Changes merge when the required checks pass, with no review: the owner accepts that risk in writing. Any person can revert a change with one click afterwards.

How change happens

Your repo and Figma stay the sources of truth. Loom governs them and flags anything that drifts. Sensors compare what exists with your rules; a difference becomes a draft, the owner reviews it, it merges through a pull request and the timeline records it.

Working today: drift checks you run on demand (the audit, and the audit_code tool for agents) and change drafts. Continuous sensors, review by autonomy mode, merging by pull request and the timeline are concepts.

Governed by LoomRules, owners, layers and approvals
Sources of truth: your repo and FigmaCode, Figma and documentation as they really are
Sensors compare: PR checks, scheduled scans, a Figma watcher and agent telemetry
Compared continuously
RecordedThe timeline keeps who changed what, when and why
Merged by pull requestYour repository stays the source of what ships
Owner reviewsAs far as the area's autonomy mode allows
Drift foundA difference becomes a draft, never a silent edit
A differenceRules updated if accepted
Governed by LoomRules, owners, layers and approvals
Sensors compare: PR checks, scheduled scans, a Figma watcher and agent telemetry
Compared continuously
Sources of truth: your repo and FigmaCode, Figma and documentation as they really are
Drift foundA difference becomes a draft, never a silent edit
Owner reviewsAs far as the area's autonomy mode allows
Merged by pull requestYour repository stays the source of what ships
RecordedThe timeline keeps who changed what, when and why

The timeline

  1. Today Drift found in Checkout: a raw colour where color.action.primary was intended. Draft opened.
  2. Yesterday Region Europe overrode the spacing scale for dense tables. Reason recorded, review in 90 days.
  3. 2.4.0 Button size sm added. Approved by the core system team.

Working today: drift checks you run on demand, which find raw values and local rebuilds in your files, and change drafts. Continuous monitoring, layers, autonomy modes and the timeline are concepts in design; the entries above are illustrative.

04 · Run it

Agents do the routine work. People make the decisions.

Any agent that speaks MCP can use your system. It looks things up, checks its own output and proposes what is missing. Agents use your own model and your own keys, and Loom’s checks give the same answer whichever model produced the result. Making those checks a required step in your CI is planned. Every draft an agent writes is labelled as AI-generated, and agent pull requests will be too.

  • search_system find components, tokens and patterns
  • get_entity read a full component contract
  • get_tokens read token values and roles
  • get_guidelines read guidance, or learn that it is missing
  • check_composition check a draft before it is written
  • audit_code find drift in existing files
  • propose_change open a draft for review
  • list_unmet_needs see what agents asked for and could not find

Recording of real output

A recorded session: a scripted agent against the Seamline system, with real server output.

The replay types each call as the agent sent it and shows each result after its recorded latency, shortened for the page. Server output is in English.

Agent session · recorded session

  1. Agent

    I need a destructive "delete workspace" action with a confirmation. What does the system have?

  2. Loom · search_system · 196 ms→ search_system({"query":"delete confirm danger","kind":"component","limit":5})

    31 results for "delete confirm danger" (lexical ranking). Top: ConfirmDialog (component:confirm-dialog, 0.87), Toast (component:toast, 0.63), Button (component:button, 0.42), IconButton (component:icon-button, 0.42), Banner and ConflictNotice (component:banner, 0.34)

    • ConfirmDialog (component:confirm-dialog, strong, confidence 0.87) — import { ConfirmDialog } from "@seamline/story-atelier";• Toast (component:toast, partial, confidence 0.63) — import { ToastProvider } from "@seamline/story-atelier";• Button (component:button, partial, confidence 0.42) — import { Button } from "@seamline/story-atelier";
  3. Loom · get_entity · 15 ms→ get_entity({"id":"Button"})

    Button: The one button. A native button with four tones (primary, secondary, quiet and danger), a link form with the same look, and a busy state that keeps focus.

  4. Agent

    Here is my first draft. It reaches for an MUI Modal, guesses a variant prop, uses two primary buttons and hard-codes a colour and a margin.

  5. Loom · check_composition · 75 ms→ check_composition({"tsx":"import { Card, Button, Heading, Text } from \"@seamline/story-atelie…"})

    Off-system: 4 errors, 1 warning across 6 nodes.

    - [error] Button has no "variant" prop. → Did you mean "tone" ("primary" | "secondary" | "quiet" | "danger")? primary: the main action of a region; secondary: other actions; qui…- [error] <Modal> is not part of Story Atelier (imported from "@mui/material"). → Closest system components: Dialog (component:dialog), Popover (component:popover), ConfirmDialo…- [warning] 2 × Button tone="primary" in one region (Card). Rule: "The main action of a region. One per region." → Keep one; make the others a lower-emphasis variant.
  6. Loom · check_composition · 5 ms→ check_composition({"tsx":"import { Card, Button, Heading, Text, Stack, ConfirmDialog } from \"…"})

    On-system: 0 errors, 0 warnings across 7 nodes.

    components: Card, Stack, Heading, Text, Button, ConfirmDialog
  7. Loom · audit_code · 292 ms→ audit_code({"files":[{"path":"src/settings/SettingsPage.tsx","source":"import React from \"react\";\nimport { Button as MuiButton, Dialog…

    Drift found: 14 errors, 8 warnings — 6 colours, 9 dimensions, 1 non-system import, 1 re-implemented component.

    ✗ src/settings/settings.css:2 Hard-coded colour #fffdf8 (background). → Use var(--sa-surface) (Raised surfaces: cards, fields, panels and dialogs).✗ src/settings/settings.css:4 Hard-coded dimension 14px (border-radius). → Use var(--sa-radius-card) (14px).✗ src/settings/settings.css:5 Hard-coded dimension 16px (padding). → Use var(--sa-space-4) (16px).
  8. Loom · get_guidelines · 49 ms→ get_guidelines({"topic":"illustration"})

    Guidelines for illustration: missing. 0 sections. Missing: Story Atelier has no dedicated illustration guideline. Do not invent one: follow existing foundations, and use propose_change (kind "guideline") to draft it for review.

    missing: Story Atelier has no dedicated illustration guideline. Do not invent one: follow existing foundations, and use propose_change (kind "guideline") to draft it for review.
  9. Agent

    Research uploads need a drag-and-drop file area. Nothing in the system does that, so I will draft a proposal rather than ship a one-off.

  10. Loom · propose_change · 542 ms→ propose_change({"kind":"component","title":"FileDropzone","need":"Researchers attach interview recordings and notes to a journey. Set…","…

    Draft component-filedropzone-4476b485 written to ../../../../../../tmp/loom-mcp-demo-aLrX07/drafts/component-filedropzone-4476b485.json (status: proposed, labelled AI-generated, not yet human-reviewed). 6 existing alternatives listed; impact: 10 declared dependents.

    impact: 10 declared dependents (partial graph)status: proposed; system source modified: false
  11. Loom · check_composition · 70 ms→ check_composition({"tsx":"import { Modal } from \"@mui/material\";\nimport { Button } from \"@sea…"})

    Off-system: 4 errors, 6 warnings across 6 nodes.

    - [warning] Raw <h1> used where the system provides Heading. → import { Heading } from "@seamline/story-atelier";- [error] Button has no "variant" prop. → Did you mean "tone" ("primary" | "secondary" | "quiet" | "danger")? primary: the main action of a region; secondary: other actions; qui…- [error] Button has no "variant" prop. → Did you mean "tone" ("primary" | "secondary" | "quiet" | "danger")? primary: the main action of a region; secondary: other actions; qui…
  12. Agent

    The booking flow needs a date range picker. Does the system have one?

  13. Loom · search_system · 18 ms→ search_system({"query":"date range picker for booking","kind":"component","limit":5})

    No component matches "date range picker". Closest partial matches: Meter and ProgressBar (component:meter, partial match, confidence 0.33: covers "range" but not "date picker"); DateLabel and RelativeTime (component:date-label, partial match, confidence 0.32: covers "date" but not "range picker"); MoodScale, MoodPicker and EmotionCurve (component:mood, partial match, confidence 0.29: covers "picker" but not "date range"). Logged as an unmet need. If this is a real gap, draft it with propose_change instead of building it off-system.

    • Meter and ProgressBar — partial match: covers "range" but not "date picker"• DateLabel and RelativeTime — partial match: covers "date" but not "range picker"• MoodScale, MoodPicker and EmotionCurve — partial match: covers "picker" but not "date range"
  14. Loom · search_system · 14 ms→ search_system({"query":"show an error when payment fails","kind":"component","limit":3})

    34 results for "show an error when payment fails" (lexical ranking). Top: ErrorSummary (component:error-summary, 0.93), AreaBoundary (component:area-boundary, 0.74), Banner and ConflictNotice (component:banner, 0.74)

    • ErrorSummary (component:error-summary, strong, confidence 0.93) — import { ErrorSummary } from "@seamline/story-atelier";• AreaBoundary (component:area-boundary, strong, confidence 0.74) — import { AreaBoundary } from "@seamline/story-atelier";• Banner and ConflictNotice (component:banner, strong, confidence 0.74) — import { Banner } from "@seamline/story-atelier";
  15. Loom · list_unmet_needs · 7 ms→ list_unmet_needs({})

    1 unmet need from 1 request; 0 over the threshold (3 requests from 2+ requesters in 30 days). "date range picker" x1.

    • "date range picker": 1 request(s), 1 requester(s) — Below threshold: needs 2 more request(s) and 1 more client(s) or team(s) within 30 days.

  • Unmet-needs radar

    Concept

    When people and agents keep searching for something the system does not have, Loom turns the pattern into a draft with the evidence attached. Drafts from agents work today.

  • Ask the system

    In development

    Designers, writers and product managers ask in plain language and get answers from the system’s own rules, with the source of each answer. An early version in the product tour searches the reference system’s rules and quotes them; it does not write answers yet.

  • Slack and Microsoft Teams

    Planned

    Notifications where your teams already work: drift found, drafts waiting for review, releases shipped. Requests can start in Slack, Teams or Loom, and reach the right owner.

  • Storybook from contracts

    Working for the reference system

    Loom generates Storybook stories from component contracts: for the reference system, 733 stories render in a real browser, 538 of 663 visibly differ from the component’s default, and every one that does not says why.

  • Figma, Storybook and CI

    Partly working

    Working today: agents over MCP, and audits from the command line. Tested on the reference system: tokens pushed to Figma as variables (one mode) and a partial component library, through an agent and Figma’s connector. Next: a CI package, a GitHub App, Jira and Linear.

Figma, on paid plans

Loom works with Figma Professional and above. What it can do depends on your plan, so we explain it plan by plan and shape the setup around yours.

  • Professional

    Tested in one file
    • Tokens pushed as Figma variables (one mode so far)
    • A component library generated from contracts (partial)
    • Drift detection: the file is read back and compared with code, run by hand today

  • Organization

    Planned
    • Everything in Professional
    • Library analytics, to see adoption in design files
    • Branching, to review library changes before they are published

  • Enterprise

    Planned
    • Everything in Organization
    • The Variables REST API, to sync tokens from your CI without a plugin step

Plan features belong to Figma and change over time; see Figma pricing. The free Starter plan is not supported.

How teams work with it

The system lead, product designers and engineers propose, ask and approve. Agents and tools read the rules and report back. Loom sits between them and records every decision.

Working today: agents that read the rules and check their work over MCP, and the drafts they propose. One record of every decision, autonomy settings and checks on every pull request are concepts.

Loom, the system recordDecisions, rules, owners, layers and a timeline of every change
System leadSets rules and autonomy; approves what matters
Product designersDesign in Figma, ask the system, propose what is missing
EngineersBuild in code; checks run on every pull request
AgentsRun on your own model through MCP; draft and check work
Figma and StorybookVariables, libraries and stories kept in step
Code and CIPull requests, audits and releases
Propose, ask, approveRead rules, report backPeople decideAgents and tools do the work People decide
System leadSets rules and autonomy; approves what matters
Product designersDesign in Figma, ask the system, propose what is missing
EngineersBuild in code; checks run on every pull request
Propose, ask, approve
Loom, the system recordDecisions, rules, owners, layers and a timeline of every change
Read rules, report backAgents and tools do the work
AgentsRun on your own model through MCP; draft and check work
Figma and StorybookVariables, libraries and stories kept in step
Code and CIPull requests, audits and releases

Privacy and ownership

Your code, your keys, your model. Your system stays yours.

Your repo and Figma stay the sources of truth. Loom’s output is files your team reviews and commits, or opens as pull requests, so every change can be reviewed and reverted. Loom never keeps your system somewhere you cannot leave.

  • Agents run where you choose

    Your machines working · CI package and Loom cloud planned

    On your own machines, in your own CI, or in Loom cloud if you would rather we run them. Today the Loom command line and MCP server run on your machines from a copy of the Loom repository, and can be scripted into CI that way. A packaged command line with a ready-made CI step, and Loom cloud, are planned.

  • Bring your own model

    Any MCP agent working · Provider setup in development

    Agents use your model and your keys: Anthropic Claude, OpenAI, or any OpenAI-compatible gateway. Any agent that speaks MCP can already use your system with the model you choose.

  • Your code stays in your repository

    Working · automatic pull requests planned

    Loom reads your repository and writes its output as files: tokens, contracts, rules and reports that your team reviews and commits, or opens as pull requests. Nothing is kept anywhere you cannot leave. Opening pull requests automatically, with checks on every one, is planned.

  • No training on your data

    Our commitment

    We do not use your code, designs or prompts to train models, and we never sell them. Drafts written by agents are labelled as AI-generated.

How we handle your data (draft)

What comes next

Where we are taking Loom. All concepts, clearly labelled.

These are designed but not built. We share them because they show where a governed system can go once it holds the truth about itself.

  • Accessibility passport

    Concept

    A living test record for every component: which states were checked, how and when. Exportable as evidence for compliance work under the European Accessibility Act, which has applied since June 2025.

  • Contract tests for agents

    Concept

    Check whether a model, such as Claude, GPT or Qwen, builds correctly with your system, using the same tasks and the same checks. Choose the model that works best for your organisation on evidence.

  • Migration simulator

    Concept

    Before approving a change, see every screen it would affect, across products and layers.

Also on the list

  • A system diff on every pull request
  • A weekly design-system weather report
  • An onboarding coach for new designers and engineers
  • A brand guardian for marketing work
  • Conversion playbooks for common stacks
  • A design debt ledger
  • A release notes writer

Why “Loom”

Tokens are notes. Components are drafts woven from them.

On a loom, a draft tells every thread where to go. A design system works the same way: a few named decisions, combined by rule into parts people trust.

The Button draft

Continue

Four notes, one component.

Ways to work with us

Start with a free check. Go further when you are ready.

Every organisation is different, so every paid step is scoped with you. There is no off-the-shelf package and no price list. Loom does the routine work at every step.

  1. 1 · Free · about 3 minutes

    Self-assessment health check

    A short self-assessment that shows what your design system is missing and where to start. Your answers stay in your browser.

    • Answer a few plain questions
    • See your gaps, area by area
    • Get a first set of next steps
    Take the free health check
  2. 2 · Paid · 2–4 weeks

    Discovery

    We look at your real system with your team and agree what to fix first. Scoped per client and delivered hands-on with Loom.

    • A guided health check, with a survey that compares how design and engineering see the system
    • An audit of your code with Loom, and an expert review of your Figma library
    • A roadmap and a quote for conversion
    Book a conversation
  3. 3 · Project · scoped with you

    Conversion and adoption

    We convert your system with you, without changing how it looks, and help your teams adopt it. Your repo and Figma stay the sources of truth throughout.

    • Tokens, contracts and governance
    • Migration delivered as pull requests your team reviews (codemods and automatic screenshots are planned)
    • React and React Native parity for components built from Loom contracts
    Talk to us
  4. 4 · Ongoing

    Ongoing maintenance with the Loom platform

    We look after the system with your team. Loom’s audit and agents find drift and draft fixes, and we keep your tools in step; your people review and decide, and we are there for the judgement calls. Continuous monitoring by agents is planned.

    • Drift and usage checks
    • Changes drafted for review
    • Releases, migrations and a changelog
    Talk to us

Read more

Notes from the workshop.

All articles

Contact

If your system feels heavier than it should, talk to us.

Loom is working with a small group of design organisations as design partners. We would like to hear what your system needs, whatever state it is in.

Book a conversation Take the free health check

Or write to hello@loom.example