Our starting point is many years of experience with token-based design systems at Emerson, Electrolux, and other industrial clients, reframed for a world where the code is no longer necessarily written by a human. Tokens are still the source of truth. Components still exist. The difference is in how the design system is packaged so an agent can read and act on it without plugin, export, or handoff.

> Read the article that grounds this work: .md – a new standard for design systems?

When does your team need an AI-ready design system?

For teams where most of the code was written by humans who held the system in Figma, a classic setup is enough. But once agents start writing the code, the playing field changes. Three situations where this becomes urgent:

When a substantial part of the interface code is written by Claude Code, Cursor, or Codex. Agents have no memory between sessions. Without a design system that lives as a file in the repo, the agent reinvents solutions every time — the same colour appears in three shades, the same dropdown gets implemented three times with different ARIA attributes, typography drifts.

When you're building a new product with agent-driven development from the start. An early MVP built with Lovable or Cursor typically lacks design structure. Putting an AI-ready design system in place early is cheap; cleaning up afterwards is expensive.

When your existing design system isn't agent-readable. Tokens sit in Figma variables behind a plugin, documentation in Supernova, components in an npm package. Everything works for humans but nothing is directly readable by the agent. Result: the agent ignores the system and builds its own.

In all three cases the problem is the same: a design system that an agent can't read will feel as limited as a design system a developer can't read.

What we do

• `design.md` spec: tokens (colour, typography, radius, spacing, motion) as YAML, plus component specifications (a primary button has this background colour, this radius, this padding) and prose with rationale

• `AGENTS.md` / `CLAUDE.md` instructions: the file that tells the agent "read design.md first, import existing components, don't create new ones if they already exist, follow naming conventions"

• First shadcn-based components committed: we set up the foundation (buttons, form fields, dropdown, modal, navigation) in your stack with the right tokens, the right accessibility, the right prop model, so the agent has real references to import from

• Token pipeline from Figma to `design.md`: when the designer changes a colour in Figma, we can export to YAML automatically, so the foundation stays in sync

• Consistency model across sessions: three layers — tokens as source of truth, the file in the repo (not in the agent's memory), and an instruction file that points the agent to existing components

• Iteration as the format evolves: Google Labs design.md is early, competing formats will appear. We track the shift and migrate your spec when needed

Common audiences are startups, AI-heavy product teams, and teams migrating from a Lovable/Cursor-built MVP into a more structured development phase.

Not just a new format — a different way of thinking about consistency

At Intunio we see `design.md` as a natural extension of token work we have done for years. It's not a break from how design systems are built; it's the same principles packaged so that an agent can act directly.

What really changes is how consistency is maintained. A `design.md` alone gives colour and token consistency, but not implementation consistency. Without the right structure around it, you get the same tertiary colour on buttons throughout the product but ten different dropdown implementations. That's why we always deliver three layers together: spec, AGENTS file, and a first set of committed components. Without the second layer the design system drifts, even when the colours are right.

Is this the right service for us?

This service fits when agents write a substantial part of the code, when pace is high, and when you want a lightweight model without heavy governance processes.

For industrial product families, multiple products and teams, long lifecycles, or heavy compliance requirements, our classic design system service is better suited. It gives a mature platform with Figma + codebase + Supernova documentation, governance and versioning, built to survive a change of design team or an organisational restructure.

The two services are not mutually exclusive. Many clients start AI-ready and grow into a classic model when the organisation and product portfolio require it.

How we work in an AI-ready engagement

Three phases, often delivered in two to four weeks:

Inventory. We look at your stack (Next.js, Vue, native, embedded), your current design (Figma file or product screenshots), and which agents you use. The result is a scope for what the spec and first components should cover.

Spec and first components. We write `design.md` with tokens and component specifications, set up shadcn-style components committed in your stack, and create `AGENTS.md` that points the agent in the right direction. We pair this with your Figma file if you have one, so designers can keep working visually while the agent works against the spec.

Validation with the agent. We run real prompts against your stack and tune the spec, instruction file, and components where the agent misunderstands. The result is a design system that actually works in your flow, not just on paper.

For clients who want to continue after the first delivery, we move into a rolling monthly engagement to maintain the spec, add components as new needs come up, and migrate to new formats when Google Labs or others publish updates.

What we offer

AI-ready design systems are a much lighter service than classic design systems. Four common engagements:

• AI-ready for a single product (40–80 hours, delivered in 1–2 weeks): `design.md` spec, `AGENTS.md`, and 8–12 foundational components committed in your stack. Suitable for a startup with one product that wants structure from the start.

• AI-ready for a startup stack (80–160 hours, delivered in 2–4 weeks): full `design.md` with more component specifications, integration with your Figma file if you have one, expanded `AGENTS.md` with per-folder rules, and 15–25 components. Suitable for teams with multiple products or a more complex stack.

• Conversion: classic → AI-ready (80–160 hours, delivered in 2–4 weeks): you have a classic design system that isn't agent-readable. We extract tokens to YAML, translate the component library into spec form, and add `AGENTS.md`. Suitable when you want agents to work against an existing system.

• Long-term maintenance (rolling monthly, from 40 hours/month): new components, adjustments to the spec, migration to new formats as they mature, support for teams using the system. Lighter maintenance than classic design systems because most of the work is done by the agent — we set and adjust the foundation.

For teams building or rebuilding a product alongside the system, we build it directly into the app development or product validation engagement. This is often a natural step two after validating a Lovable/Cursor-built MVP.

Pricing

995 SEK/hour (discounted rate with a monthly agreement).

We apply a discounted hourly rate for monthly agreements: you pay the month's estimated cost in advance, and get a price you can plan around. No commitment beyond the current month. For AI-ready design systems the hour ranges are lower than for classic design systems, so the monthly cost typically lands under 50,000 SEK even for the larger packages.

AI tools are included in the rate. We use Claude, Cursor, and Codex to write and iterate on the spec, generate component code, and test AGENTS instructions. It's our expertise working faster.

Common starting points

Three typical situations where a conversation with Intunio becomes relevant:

When a Lovable- or Cursor-built MVP needs structure. The product exists but the code is sprawling, the same components get implemented differently in different places, and new features just add inconsistency. An AI-ready design system gives the agent a shared foundation to build against going forward.

When your team starts using Claude Code or Cursor in earnest. You notice that without structure the agent keeps reinventing the same things. We set up a first `design.md` and `AGENTS.md` so the next session starts from the right state.

When your existing design system isn't agent-readable. Tokens in Figma variables, documentation in Supernova, components in an npm package. Everything works for humans but nothing for the agent. We convert to AI-ready format without throwing away what you've built.

In all three cases the result is the same: a design system the agent actually reads and follows, so consistency holds even when pace is high and humans don't see every commit.