In this discussion, the speakers explore how to integrate a Figma‑based design system into agentic workflows. They compare using a Model‑Centric Prompt (MCP) that can dynamically expose design‑system‑specific APIs, tokens, and component details versus relying on a static agents markdown file that describes the system. While an agents file can keep an agent on‑rails for a single product, it quickly becomes outdated and insufficient for larger organizations with multiple product teams. To address scalability, they propose routing requests to more granular context files that describe specific component categories or layouts, allowing the agent to fetch relevant, up‑to‑date information. The conversation emphasizes that there is no one‑size‑fits‑all solution; organizations must assess the size, scope, future growth, and number of product teams when choosing between MCP, static agents files, or routing architectures.
Chapters
if you have a design system in Figma, but you want to use it inside of the context of your Agentic workflow at a deeper level, how do folks go about being able to do that?
We all see the speed with which I can get a reasonable level of fidelity straight from Claude Code. If I just simply hand it a screenshot of a design, or I leverage Figma's own MCP, I get an even higher level of fidelity. Of that design implemented in my code. But at some point, that model starts to fall apart because the language of your design system is specific to your organization or to your team. And it especially becomes an issue when you have multiple teams within the same organization. If you think about just a, a single team working on a singular product, you can sort of corral your agent to stay within the bounds of your brand standard or the language of your design system or some of the API of the components that you've created that represent the design system, you can keep it possibly on the rails, possibly within a single product. But if you start to— within the same org, again, if you have multiple products, it just becomes very, very difficult. And so what, what we've seen is when when we leverage anything from an MCP that is specific to the design system that can speak the language of the design system. And so then connecting Claude to that design system MCP does the work of keeping Claude, keeping the agent on the rails of the design system. It's not guessing because it can get specific API information of the components that you're using, or it can get specific tokens that make up your design system. So MCP being one that might be a good fit for your organization. We've seen something simpler, just a well-written agents file. Like if that agents file is detailed enough to describe your design system, that your agent is likely on the rails of your design system just from that markdown file. That's a more narrow case because typically a design system is bigger, like there's more context to a design system than would just fit in a single agent file. It is worth considering because it's, it's simple. One of the other challenges with an agents file is your design system's obviously it's living and breathing. It's going to continue to evolve and grow. And that agents file is static, whereas something like an MCP can be dynamic and can evolve along with your design system. So your agent's always getting relevant information. There's other solutions too. Like if you start to take, instead of a single agents file, you take a routing solution so that if your design system is robust enough, a request could come into your agent and then you can route that request to a more specific agent file, like a more specific context file. And then that context file might describe a specific type of component. Possibly it's like a layout category of, of your code base. That layout information that's specific to your design system, the agent could be routed to that, can add that context to the current session, and then should be able to get a well-informed result from, from the agent. The point being, like, if you don't have some context that's specific to your design system. The agent is only going to get you so far. There are some very good options. At this point, I wouldn't say you can prescribe one-size-fits-all options to your organization. You kind of have to evaluate the size and scope of your design system, where you're headed into the future as an organization, how many product teams you're looking to support. There's some pretty challenging questions to answer.
