Loom for developers: agents that build with your real components

The rules live in people's heads, and agents cannot read heads

Agents guess. Your assistant writes a settings page before lunch. It hard-codes #2563eb, adds padding: 13px, builds a local modal and uses a property that was renamed last year. Every pull request needs the same review comments.

The rules live in people's heads. Which token for a danger border? Is a className override allowed on Card? Is variant="danger" deprecated? The answers exist, but not in a form a linter or an agent can read.

Drift is found too late. Raw values and local rebuilds pile up across products. Nobody can say how many, or which ones matter.

Changes to the system break consumers. A renamed property or a changed default ships as a minor version, and someone finds out in production.

Two platforms, two behaviours. The web and native versions of a component drift apart, because nothing checks them against the same rules.

Loom gives agents the real system and checks what they write

Your system, over MCP

Any agent that speaks MCP gets 17 tools: search the system with a confidence level, read a contract with the exact import, read tokens and rules, get the whole system as one DESIGN.md file, check a composition, audit code, propose a change, classify a need as reuse, extend or new, and list unmet needs. On our reference system, calls take between 2 and 72 milliseconds. Working

Search reports "no strong match" instead of a weak guess, so the agent proposes what is missing instead of inventing it. Search can also use your own embeddings model. Partial What does not work yet: embeddings have been tested against a local test model only.

Checks that name the exact fix

check_composition runs on a draft before it is written. It flags raw colours and spacing, components rebuilt by hand, unlabelled form controls, two primary actions in one region, className or style overrides on system components and pattern rule breaks, and says what to use instead. audit_code runs on existing files and reports uses of deprecated items with their replacement and removal date. Working

check_composition → error  loom.accessibility  <input> has no label. Use TextField with a label.
                  → warn   loom.raw-colour     #2563eb. Use color.action.primary.
                  → warn   loom.reimplementation  Local Modal. Use Dialog from @your/system.

Illustrative output. The rule names are Loom's built-in rules.

Rules as files, severity per area

Governance lives in a loom/ folder in your repository: rules with an owner, rationale, severity and scope; exceptions with an expiry date; proposals; patterns; deprecations. Raw values and rebuilds are warnings by default; the owner of an area promotes them to errors for that area. Accessibility rules are always errors. Your ESLint config can be imported as rule records; ESLint still enforces those rules. Working

The rules command checks the same rules from the command line and exits with an error code when an error remains, so it can run in any CI from a copy of the repository. Partial What does not work yet: a packaged command line with a ready-made CI step. Concept

Typed tokens and one contract per component

Conversion writes your design decisions as DTCG 2025.10 tokens with the evidence for each value, and keeps your token names. Partial What does not work yet: the component tier and modes are in development; build outputs for CSS variables, Tailwind and CSS-in-JS are planned.

Each component gets a contract: purpose, anatomy, API, states, behaviour, accessibility and content, with every gap marked as a question. Working

React and React Native from one contract

Loom writes a component for React (on React Aria Components) and React Native from one contract, with generated tests for both: axe on every web state, the accessibility tree on every native state, keyboard scripts and parity scenarios. Partial What does not work yet: today this covers Button, Switch and Dialog; native tests run in Jest, not on devices; generating your own components this way is next. Partial

Version bumps decided by the contract

Loom compares two contract versions and decides the bump. Removed or renamed properties, a property becoming required, narrowed values, changed defaults and removed states or keyboard behaviour are major. Additions are minor. A visual change above 0.5% of a key screen is breaking too. Working

Deprecations name a replacement and a date, and the audit reports every remaining use. Partial What does not work yet: migration pull requests and codemods. Concept

Pull requests, not direct writes

Loom opens labelled draft pull requests through one interface for GitHub, GitLab and Azure DevOps, with the provenance of each change. Loom never merges. Partial What does not work yet: tested against simulated hosts only.

The look-diff command compares before and after screenshots against the 0.5% rule and marks each change in colour. Partial What does not work yet: capturing screenshots for every route automatically.

The check names the fix

This is real output from the recorded session on Loom Base, our own design system: the check names each problem in the first draft with its fix, and the second draft passes.

Watch an agent build on the system

We show our own numbers

• 50 of 50 parity scenarios pass, 28 on web and 22 on native, for Button, Switch and Dialog generated from one contract each, with a mutation check that confirms the tests fail when behaviour breaks. Partial Native tests do not yet run on devices.
• The audit runs on code it was never tuned for. It scored a package it had never seen in 2.4 seconds, across all eight areas, with no configuration. Working
• Two pilots made the engine better. On 25 October 2026, two pilots on real, private apps found gaps in how the audit reads non-standard apps: generated files counted twice, token modules missed, utility-class values not counted. Each fix is merged with tests.

The fastest code is the code an agent does not have to rewrite. Give it the real system.

Questions

Which stacks do you support? The audit reads React, TypeScript, CSS and plain HTML, CSS and JavaScript apps. Loom writes React and React Native. Styling output is CSS variables today; Tailwind and CSS-in-JS adapters are planned.

Does the MCP server need network access? No. It runs locally over standard input and output or local HTTP. Over a network it requires a token of at least 32 characters and refuses to start without one. Working

Can repository text hijack the agent? Tool results fence and neutralise content from your repository and mark it as data, not instructions. This lowers prompt-injection risk; it does not remove it. Working

How do I stop an agent run from costing too much? Cap it by calls, tokens or estimated cost. Every call is logged. Working

Will Loom merge into main? No. Loom opens draft pull requests. Your branch protection stays in force.