Every crew building with AI coding agents hits the same moment. The output looks right, the work moves faster, and then the bill shows up. More context in, better results out, and a cost that climbs alongside both.
Someone asked us about this during our design systems live Q&A. They'd done the work, gotten output that matched what they wanted, and spent a lot of credits getting there. Was there a way to optimize that?
There is, and it usually isn't a smaller design system. Most teams are paying for context their agent never asked for.
What you're actually paying for
Token cost on a design system comes down to three things: how much context loads, how often it loads, and how far it has to travel to get there.
Teams tend to focus on the first one and ignore the other two. That's backwards. A modest amount of context loaded on every single generation costs more over a week than a larger amount pulled once, on demand, when the agent actually needs it.
A file loads everything, every time
DESIGN.md is a good format. It gives an agent your tokens, your visual rules, and the reasoning behind them in one portable file, and we build with it on real systems.
It has one known trade-off: the agent reads the whole file on every generation. There's no partial read. If your file covers every component in the system, the agent loads every component whether it's building a button or a data table.
On one system we've worked on, we defined all the components inside a single DESIGN.md file, following the spec. It works, and we haven't hit problems with it. But it's a fair question to keep asking, because a large file means higher cost, slower responses, and context truncation that can start to hurt accuracy. We plan to benchmark the single-file approach against a more composable one before committing either way.
Size decides more than format
The obvious conclusion is that a file is cheap and a server is expensive. The numbers don't support that.
Atlassian tested this on their own design system. They trimmed their DESIGN.md to 80 KB, cutting usage guidance from more than 50 components to get it that small. Their MCP and skills hold about 2.5 MB of guidance. Then they built the same log-in screen with each one.
The smaller artifact cost more, because it loaded in full on every turn while the larger one got fetched in slices. Format isn't the variable. Volume and frequency are. A small file beats a bloated MCP server. A tight MCP that returns one answer beats a file carrying your entire component library into every request.
Their caveat is worth repeating: one task, one system, one set of models. Run it on yours and the numbers will move. The mechanism won't.
Why we don't point agents at Storybook
We use Storybook in most of our builds, so when people ask whether it helps with agentic tooling, the answer is yes for humans.
We don't use Storybook's MCP, and that surprises people. It burns through a lot of tokens, and we've found it inefficient for this job. Storybook is built for a person browsing components, reading docs, and clicking through states. Point an agent at a published Storybook instance and it will probably get the right context. The problem is that all of that context gets built up again every time.
You're paying to render a human experience so a machine can read it.
Run the MCP locally
The context an agent needs about a design system is not big. It's a set of components, their props, your tokens, and rules for when to use what. That's not the kind of payload that needs to live on a server somewhere.
When we build a custom MCP, it runs locally. Our approach is a simple npm package that installs on the machine and runs there. Nothing hosted, nothing to call out to.
Make it local and you keep cost down in both time and dollars, and the output quality holds. Tighter context tends to produce more accurate results, not less.
Answer the question the agent asked
The reason a local MCP stays small is that we tune it to the specific questions an agent needs answered. Which components exist. What props this one takes. Which token applies here.
That's a different design goal than "expose everything and let the model sort it out." Exposing everything is easier to build and more expensive to run, every single day, forever.
It also clarifies how DESIGN.md and an MCP server fit together instead of competing. DESIGN.md mostly serves designers and design tooling, carrying tokens and visual rules. A design system MCP mostly serves developers, handing a coding agent the real shape of the component library. The cleanest setup uses DESIGN.md as the source the MCP reads from, so you maintain one source of truth and pay for context once.
Deterministic first, AI where you need it
This goes past design systems.
A lot of what teams hand to an AI agent doesn't need an AI agent. Traditional algorithms and deterministic machine learning still handle deterministic work faster and cheaper than a model will. Reach for AI at the parts that genuinely need judgment, pattern matching, or generation.
In B2B software especially, where workflows are well defined and the rules are knowable, that combination has been the most effective thing we've seen. Deterministic code for the deterministic parts, AI for the rest.
Where to start this week
None of this requires a rebuild. It's a series of small architectural calls, and they compound in your favor instead of against you.
Go deeper on design system MCPs
We covered this live in Design System MCPs with Billy Sweetman and Tim Gremore, including audience questions on where the cost actually sits. The recording is on the event page.
If you're working out how to make your own system ready for AI agents, see how we help teams build and scale design systems.
