Components, tokens and code
We can help with a component library, token architecture, documentation or a system that has drifted between design and implementation.
Your journey
Review your route and travel details before booking.
Review journeyDesign and implementation
We align Figma variables, token definitions and components with their implementation. Working examples give designers and developers a reference they can inspect together.
Ownership and maintenance
We help define who maintains the system, how teams contribute and how changes are reviewed.
A shared foundation can support different brands, audiences and moments. We decide with the team which choices hold the experience together and where expression should vary. The theme comparison above illustrates that space within one system.
Documenting product decisions
Choreography connects shared structure with individual expression. The layer records the intent, requirements and boundaries behind a product, including where judgement and variation belong. People and agents can use those decisions to respond to a context while keeping the product recognisable.
Mission, product principles, research and the reasons behind past choices.
Requirements, conditions, states and references to components, tokens and content.
Explicit boundaries and checks, with a review path for exceptions.
Access for people and agents
Agents can help teams explore and build from an existing system. To do that reliably, they need access to its decisions as well as its components, and a clear response when information is missing.
Which pattern fits this moment?
Research, intent and product principles
Propose a journey and discuss the trade-offs.
When an agent uses a product, character can travel through very small details: a default, the meaning of a field, a refusal or the moment approval is required. We make those decisions explicit where possible and identify what still needs human judgement. Agent access, available tools and enforcement points are designed for the client’s environment.
What the harness checks
The harness applies testable decisions at agreed points in the workflow. It returns the source of an answer, stops work that breaks a rule and records catches for the team to review.
agentbuild guest checkout, step 3 of 4 agentpropose Button label="Complete purchase" color=#2F6BFF radius=10 harnessREFUSE breaks decision checkout/primary-action the primary action uses token action.primary and the label "Pay now" source: specs/checkout.md, line 42 agentrevise Button variant=primary label="Pay now" harnessANSWER matches spec. source: specs/checkout.md harnessREMEMBER catch logged to harness/catches.log personSIGN OFF lead designer approves step 3
Illustrative checkout session, not a live client implementation. It demonstrates a label and token check, not automatic judgement of brand quality.
Automated checks
An agreed token, a required action label or another explicit, testable condition.
Human review
Whether a journey makes sense, a tone fits the moment or an exception is justified.
Implementation boundaries
The harness core works from open files and a schema. Its checks do not require an AI model or a network connection. Surrounding agent tools and integrations may use their own services. Where the checks run and what can be enforced are decisions for the environment.
Reviewing feedback and changing the system
Product research, usage findings and failed checks can lead to changes in the system. The team reviews the evidence and a named person approves the change before the rules are updated.
Practical work connects code, tokens and checks. Management connects intent, specs and demos. Results and agreed KPIs give leadership evidence for the next decision.
Ownership and delivery
We build the choreography layer in your working environment. You own it.
The Studio assesses the foundation, specifies the decisions and helps build the harness. The Company can implement, roll out and operate the work alongside your team, with monitoring, tickets and a recovery loop for misses.
An assessment maps what exists, what connects and where decisions are missing. Scope, timing and fee are agreed before proceeding.
Discuss an assessmentQuestions
Do we need to replace our design system?
We start with what you have. An assessment identifies useful foundations, missing decisions and connections that need work.
Is the harness a subscription?
No. We build it as part of your choreography layer, in your working environment. You own the layer. Ongoing implementation and operation are services we can agree separately.
What can be checked automatically?
An explicit, testable condition, such as an agreed token or a required action label. Whether a flow makes sense or an exception is justified still needs human review.
Can the system change its own rules?
Results and catches can lead to a proposed change. A named person reviews and approves it before the decisions are updated.
Who approves the work?
People and agents can propose work. A named person signs it off, including any exceptions. Passing an automated check does not replace that approval.
How do we start?
Tell us about your product, system and what you want people or agents to do with it. We agree the scope, timing and fee of an assessment before you proceed.