What if an AI agent could read our design system and build from it?
At Brim I design the system the rest of the product is built from, which means the visual language, the component library, and increasingly the documentation that tells both people and AI agents how to build new surfaces. Brim itself is an AI system that helps mid-sized businesses own their specific intelligence, by which I mean the way their company actually works and the patterns and decisions that make it good at what it does.
This was a close collaboration with Brim's founder. The visual design system in Figma was mostly mine to build, but the move toward a more compositional, dynamic system was something he initiated, and a lot of his direction shaped how I came to think about it. As AI evolved and new frameworks became available, rendering components dynamically went from an idea into something we could actually build, and that shift is what this case study is really about.
Outcome
I rebuilt the design system so an AI agent could compose from it, and implementation went from months to under two weeks.
I was the only product designer on the team, so every time we needed a new component it had to be designed by me first, which made me the bottleneck on how fast the product could move. At the same time Brim was heading toward a more dynamic kind of interface, where parts of the experience are composed on the fly rather than drawn ahead of time, and designing that manually, a screen at a time, was never going to keep up.
I had built the design system in Figma, and the engineers had moved it into Storybook with my contributions to docs and variants. My first attempt at unbottlenecking was connecting Figma MCP so our agents could read the system, but reading turned out to be different from being able to build from it. So I rewrote the system into a set of documents that both people and AI agents could read, covering how things look, how the experience should behave, and what each part is allowed to do.
New components stopped being something the team had to wait on me for, because the primitives and the rules for composing them were already written down in a form an agent could follow. Implementation cycles went from over three months to under two weeks, and the way we extend the system moved from drawing screens toward deciding what to specify and what to leave open.
As the only designer, I became a bottleneck for how fast Brim could be built.
And because Brim is an AI product a user can ask almost anything of, the set of components and flows the interface might need is effectively infinite. The more I sat with it, the clearer it became that this needed a different way of working rather than more of me.
I stopped designing screens and started designing the system underneath them.
This is where the way I think about design changed. Building a compositional design system means stepping away from individual screens and designing the system underneath them, the primitives, the relationships between them, and the principles that decide how they fit. The goal became a system clear enough that a person and an AI agent could both build new things from it without breaking how Brim feels.
None of this happened in one move. It came in steps across the second half of 2025 and into 2026, each one fixing part of the problem and showing me the next piece I had not accounted for.
The Figma system, mostly mine
I started in the second half of 2025 with a fairly standard design system in Figma, organised the way atomic design lays it out, from tokens to primitives to composites to layouts and templates. That part was mostly mine, and it gave Brim a consistent visual language to build from while the product was still moving quickly and changing shape.
Where reading fell short
My first attempt at getting out of the bottleneck was connecting Figma through Claude MCP, so our agents could read the design system directly instead of waiting on me. It made the system legible to an agent for the first time, but I kept hitting the same limit, the agent could read what already existed without being able to compose something new that still felt like Brim.
Rewriting it into documents
As Brim moved toward a much more dynamic experience, the real change was rewriting the system into documentation that both people and agents could read. A design MD on its own was never going to be enough, because composing a new part of the experience needs more than a description of how things look, so it grew into a set of documents that carry the thinking I would have brought myself.
Each step handed a little more of the design thinking to the system itself, until the question I was really answering stopped being how do I draw this faster and became what do I need to write down so that anything built from it still feels like Brim.
Moving the design thinking into the system itself.
The solution was less a document and more a way of organising the system so the thinking came first. Rather than fixing the product a page at a time, I started from the principles that govern how Brim's design and experience should work, and let the rest follow from there.
Leading with principles
Because we were moving toward a more dynamic system, I could not keep designing incrementally and fixing one page at a time. So I led with the principles that govern Brim's design and experience, then went back to the primitives I already had and set them out in the design MD. With the primitives, the styles, and the spacing already covered, creating new components was not the hard part. The real work was governing how an AI could build those components in a way that stayed true to the system already in place.
What the documents actually say
Read together, the design, experience, and product MDs give an agent enough to compose something new that feels like Brim, rather than something assembled from the right parts that does not quite hold together. Here is one primitive as the documents describe it.
# Card · primitive tokens: surface · border · radius-md · space-16 type: title 14·500 body 14·400 states: rest · hover (lift 1px) · focus ring rules: - compose only from primitives that already exist - one primary action per card, never two - a display-only card cannot perform an action use when: - a single object, one figure, one owner - never a full roster, that is a list
From guidelines to guardrails
The part I am most proud of is that these documents are not guidelines that get read once and then forgotten. They are written so the rules hold while a surface is being built, so an agent composing a new component works within the same primitives, the same spacing, and the same sense of what each part is allowed to do. That is the heart of the systems thinking here. My job became less about deciding what every screen looks like and more about deciding what to specify and what to leave open, and trusting the system to keep the rest coherent.
existing primitives only
one primary action
display-only cannot act
compose:
card + pill + action
Knowing where not to hand it over
Not everything should be composed by an agent, and a big part of the work was being clear about what stays a human decision. The primitives themselves stay human-designed, so the agent only ever composes from the parts that already exist and never invents a new one. The overall layout sits with the human too, including where a component belongs on the page and how the page is divided. The agent composes within that structure, it does not get to rearrange the page.
For the customer, all of this shows up as components composed for their own data and the tools they actually use, rather than generic or overcrowded screens where they have to hunt for the one field or card that matters. The work of finding what is relevant is handled for them, so the right thing is simply handed over.
What I'd carry into the next system I design.
Writing the design MD was not as straightforward as I expected. It is not a straight path, and you cannot just take all of your Figma tokens and pour them into a markdown file, especially when the product is moving toward something dynamic rather than a regular SaaS layout. Every principle has to be tested, you write one, you put it on a prototype, you watch what the agent does with it, and you iterate. The system holds up after several rounds of that, rather than on the first pass.
What worked
Designing in systems is where I think product design is heading, and the work depends more and more on my judgment about what the agent should reproduce, and on remembering that I still have control over that. The biggest thing I learned is that an AI is only ever as good as what you give it, and that it follows principles far better than a set of patched-up features, so when you are clear about what it should review and check against, it becomes better and better.
What I'd do differently
I would speak to the engineers earlier about how all of this gets technically implemented. We did have an architecture framework in place, but there was a lot of technical language in it that I would have understood faster, and used better, if I had worked more closely with engineering while it was being written.