Company C runs a three-agent AI system meant to support the design process: a Design Reviewer that audits frames against the design system, a Design System Manager that maintains the component library, and a PM Ticket Writer that generates tickets from design decisions.

The idea was sound and the implementation worked, but only barely, and not at any meaningful scale. A single frame scan consumed up to 180,000 tokens and took several minutes to complete. A few scans could exhaust a team member's weekly token budget entirely.

At the root of the scalability issue was a structural one: the system was asking AI to do everything. Every scan sent the full Figma frame context to the LLM, every node, property, and nested element, regardless of whether the model needed it. Color checks, spacing rules, and component validation were all handled through inference, when most of it could have been determined deterministically before the model was ever involved.

The system was expensive by design, not because AI was the wrong tool, but because the boundaries of where AI should begin and end had never been defined. That was the design problem. Everything else was a symptom.

The fix wasn't more AI. It was less, applied more precisely. The re-architecture was built around a single guiding principle: separate what needs judgment from what needs rules.

Color checks, spacing validation, and component compliance aren't ambiguous. They have correct answers. Running them through an LLM wasn't adding intelligence; it was adding cost. By shifting rule-based logic into a deterministic pre-analysis layer before any LLM call, the system could focus inference where it actually mattered: identifying violations that required contextual reasoning, not mechanical checking.

Less AI, doing more. This wasn't skepticism about AI. It was respect for it, using it where it's genuinely powerful rather than treating it as a default.

The first wave was about what the LLM was seeing. The system had been sending everything, every node and property, whether the model needed it or not. Stripping Figma data to only essential fields before it reached the model, replacing a high-level abstraction with direct REST API calls, and collapsing identical violations into single counted rows each removed something the model was reading without needing to. The surprising part wasn't how much it helped. It was how obvious it seemed in hindsight.

The second wave was about when the system read anything at all. Previously every refresh triggered a full library read regardless of what had changed. A diff-based caching system replaced that with an explicit decision tree: full refresh, diff refresh, targeted lookup, or skip. Most days only the modified pages get fetched. On stable days, nothing does.

Large frame reviews dropped from approximately 45,000 tokens to between 6,000 and 8,000, an 82 to 87% reduction. Small component reviews fell from around 8,000 tokens to between 400 and 800, a reduction of 90 to 95%. On days where nothing in the design system had changed, the Figma read cost dropped to effectively zero.

The more important outcome wasn't only the token savings. Reviews that previously took several minutes returned results in a fraction of the time, output was consistent across runs, and the Design System Manager knew exactly when to read and when to skip. A tool that worked in isolation became infrastructure for daily use.

Efficiency was solved. The system was fast, reliable, and cheap to run. But three agents were about to become more: design-to-code handoff, Storybook maintenance, Git workflows, and whatever came next. With each capability, there was another decision about which agent to use and when. I wanted to get ahead of that complexity before the system became something people needed a manual to operate.

I added an orchestration layer above the agents to handle routing based on intent. If someone knows exactly what they want, they can still invoke an agent directly. When the request is less clear, the system handles the ambiguity explicitly. A shared frame with no clear request defaults to the Design Reviewer and tells the user how to override it. For an ambiguous quality question, it asks one question—compliance or craft? If there's no frame and no clear intent, it shows a short menu instead of making a guess.

That same approach carried into the review system. The compliance layer catches things the system can check objectively: incorrect tokens, unlinked components, invalid variant combinations. But those checks don't tell you whether a design is actually good.

For example, a calculate button styled as a text link next to a solid primary contact CTA might follow every design-system rule and still steer someone away from the answer they're looking for.

So I added a fourth agent: the Design Quality Reviewer. It evaluates the things the compliance layer can't, using Nielsen's heuristics, Laws of UX, and Company C's design principles. I also gave it a dark-pattern taxonomy covering things like withheld answers, false hierarchy, friction asymmetry, and confirmshaming.

That distinction mattered for Company C because a misleading interface isn't just a craft problem in a regulated industry. It can create real liability in a regulated industry.

The aim was to make design judgment easier to apply consistently—not to automate it. The reviewer gives teams a way to surface those decisions, discuss them using the same vocabulary, and leave a record of why a design passed or failed.

One of the clearest mistakes I made was letting the scope creep into a system that was supposed to prevent it. Early on, I added token suggestions to the Design Reviewer, which pushed it beyond reviewing designs and into producing them. That started to overlap with the Design System Manager and made the overall system harder to reason about. As an agent takes on more responsibility, there are also more opportunities for the model to lose focus or contradict its own instructions. I came to see that clear boundaries are important not just for the architecture, but for keeping the behavior predictable.

The bigger realization was how little the LLM actually needed to do. Most design compliance checks have a known, correct answer. Running those checks through inference introduced cost and variability where deterministic logic could have been faster, cheaper, and more consistent. I underestimated that early on, and I’m still working through what that means for how these systems should be designed.

What started as a promising idea that couldn’t scale eventually became infrastructure the team uses every day. From there, it evolved into a system that could exercise judgment, and eventually one that could account for intent. That progression is the part of this work I find most interesting: figuring out where the system should be deterministic, where it needs judgment, and how those pieces can work together.