The case for A.I. Orchestration in Design Systems
A common narrative I hear among design system teams is that each practitioner is wearing "too many hats", and if you look at the data, they're not wrong.
The average number of people on a design system team is between four to seven (Sparkbox Design Systems Survey 2022–2023), while the average number of people a design system supports is 310 (Knapsack 2023 State of Design Systems Report), across an average of 20 products (Zeroheight Survey 2021).
This means that, on average, a design system team of four support 20 different 8 person product teams. It's common that beyond component libraries, tokens, and documentation, design system teams are additionally responsible for:
- Measuring system health
- Full-scale support
- Change management
- Governance
- Auditing
- Education
- Marketing their offerings
- Writing content
- Building design community
Their work quietly underpins the velocity and cohesion of dozens of teams, yet the scale is brutally out of balance. These teams are typically collections of high-energy, multi-talented professionals who are already high-performers. The value they create is immense. Therein lies a bit of a weak point. When a system's "truth" rests on a few over-stretched practitioners, even the most capable team can be overwhelmed.
The reality is, a large portion of enterprise design system teams are hanging by a thread, full of superstars experiencing burnout, overcome by calendar invites, and the shifting tides of fortune.
As close to the truth as possible
A design system is an attempt by practitioners to bring an organization's intent and delivery as close to the truth as possible. Proximity to that truth is not a one-time act or a static artifact. It is why we like to say design systems are living. A good design system can be watched, tested, interrogated, and measured against the evolving reality of the people the system is supposed to support. The problem is that most teams don't have the capacity or instrumentation in place to deliver on the full value of this promise.
What is A.I. Orchestration?
By "A.I. orchestration," I mean a meta-organization of A.I. agents that autonomously perform ongoing system work. For a helpful primer, see IBM's definition of A.I. Orchestration. The point is not that any single agent is impressive, it's what can be unlocked if you can successfully get multiple A.I. agents to collaborate on outcomes autonomously while you sleep.
The strongest use of A.I. in design systems is not "generate me a button component." That is fine. It is also already mundane. I'm talking about the kind of instrumentation that runs in the background while you sleep so you can do more of what you want, and faster.
A.I. Orchestration is not taking your design systems job
There is a bleak way to tell this story. A.I. Orchestration allows leadership to cut headcount, and therefore demand more output of an already stretched thin team. "A design system teams of one is a valid business choice!", they might say.
That future is possible. Corporations don't traditionally show much restraint when it comes to trying to automate away humans entirely. However, used well, orchestration raises the level at which humans operate. It pulls people upward toward judgment, synthesis, stewardship, and truth-testing, ultimately keeping the system closer to reality.
A better future is that Design System Practitioner becomes a heavier role. Truthfully, I do suspect many larger design systems teams will become smaller. I also suspect there will be many more design systems teams! More than ever, it seems obvious that design systems are an important market differentiator.
Practitioners will still specialize, e.g. Foundations, Components, Research, but will no longer be constrained by the mundane. 'Practitioner' roles will become 'Operator' or 'Owner' roles, with more stewardship over complete domains, and less production of isolated artifacts. Each Design System Operator will own agentic capabilities, and share them with their teammates.
Design systems thinking is unusually compatible with A.I. Orchestration.
The implements of a design system; tokens, docs, naming conventions, etc... are your A.I. context. You've been building a perfect cog for A.I. to help you, and you didn't even know it. For those one person teams who have some freedom to wire your own tooling, now is the time to experiment with orchestration.
Mature teams, perhaps your team is finding that one-off agents or GPT chats is an inefficient implementation of A.I., and you're ready to scale and normalize your teams usage of A.I. capabilities.
Some good cases for A.I. Orchestration:
Measuring System Health
Design system teams need instrumentation that can measure health as frequently as possible.
This is where I think A.I. orchestration can become useful for delivering on the promise of design systems.
Ask a design system practitioner when they last measured the health of their system and you will usually get a grimace. Not because they don't care — they care more than anyone — but because "measuring" today tends to mean two weeks of one person living inside a spreadsheet to produce a single slide a stakeholder will look at for thirty seconds.
The work itself is a swarm of small, unglamorous tasks: pulling component usage across twenty repos, hand-counting detached instances in Figma files, running accessibility checks across shipped products, scanning Teams/Slack, emails, and myriad other sources for signals.
Most teams end up measuring what is easy to measure:
- Figma metrics
- Satisfaction surveys (conducted once a year, and usually stale by the time they're reported)
- Repo usage
Orchestration could run all of this nightly. One Auditor agent looks at every consuming repo nightly, inventorying which components, variants, and tokens are actually in production and reports. Another agent compares production UI for divergence, considers context around that divergence and reports. An accessibility agent running automated checks across known product routes, and reports. Finally, a System Health agent synthesizes all of these reports into a weighted health score.
Health Scores can finally be tracked daily, allowing a design system operator to see what changes have significant influence on overall system health.
The human practitioner can now focus on what health means, which signals are most important, which aren't, and what aspects of the system need "medical attention".
Anticipating needs
In larger organizations, coordinating between product teams and portfolio feature backlogs becomes a huge challenge.
Imagine over morning coffee, you open your computer to see a report from a "Roadmap Radar" agent who is responsible for predicting where your design system may be trailing the needs of your portfolio. In this scenario, the Roadmap Radar agent employs a Researcher agent to evaluate a portfolio feature backlog and anticipate weak spots in your design system's offering. The Researcher agent coordinates with a Business Analyst agent to produce business cases for new design system artifacts. How much headache could something like this save a design system team?
Office Hours
Design system teams often leverage Office Hours as a live, synchronous channel. People bring questions, confusions, or are just curious what the team is up to.
At Edward Jones, our team was often responsible for the entire agenda, as to not "waste designers time". Deciding that agenda, and who should attend, is a coordinated team effort. The team must simultaniously keep a bead on emerging needs, analyze the backlog, form an agenda that's exciting, teach the community something new, run the meeting, and coordinate people to present during the open hours. That is a lot to ask a team that is already underwater. Orchestration is a natural fit here.
How about an Office Hours orchestration?
One Support agent responsible for reading comms channels (Teams, Slack, whatever you use) and clustering related questions. Another agent evaluates the backlog for themes appearing there. A Support Manager agent derives insights from that data about what's important to cover. The Support Manager works with your design system's Marketing team (that is a marketing team of agents) to form an agenda with exciting and engaging topics, create assets, recommend presenters, and prep for comms. All of this is being prepared for the design system practitioner to utilize and adjust as they see fit.
Change Management
At least at Edward Jones, our design system began as a light-mode only context. Understanding what it would take to ship and support dark mode across the system took us months of meetings, audits, screenshots, research, token planning, spreadsheeting, politicking, and resistance.
With orchestration, one operator could dispatch parallel research into risks, costs, codebase challenges, doc change requirements, token changes needed, support demands, usage analytics for priority rollout, and accessibility concerns. Agents can collaborate and coordinate with one another to make decisions, solve problems, address concerns, with as much or as little liberty as you want them to have.
Release Strategies
Anything you publish when the system moves (Figma changes, code changes, new docs, articles migration strategies) that has to stay aligned across audiences is a good case for A.I. Orchestration. A big release is often fifty-percent technical documentation and 100% comms strategy. Yes, that's 150%, as any design system practitioner will attest.
What if we offload the essentially clerical duties to a team of A.I. agents to aggregate and inventory the boring facts of the release (pr's, merges, etc)? Using A.I. Orchestration here would allow the design system operator to focus on what machines don't do well; giving meaning to the work. The design system operator gets to spend their attention instead on understanding what this release means (for the org and design system team), why its important now, what this release unlocks, challenges you might face, and why anyone should care.
Maybe you could even run your release strategy through the same Marketing team you leveraged in Office Hours.
Auditing consistency across products
Whether you have two apps or twenty, comparing what's shipped to what the system says is an inevitable (and extraordinarily taxing) responsibility of a design system practitioner who only has two eyes, and a limit to how much divergence they can see in one day.
How about a team of agents instead? A team that can run repeatable checks against repos, take screenshots, and then work together to determine which drift situations the design system operator may want to focus on addressing that day? In this case, the design system operator gets to focus on deciding policy, and when to enforce the policy, rather than policing everything. You get to be Design Ops, not Design Cops!
A good design system is a moral project in miniature.
Are you noticing how in each of these scenarios, the human design system practitioner is being lifted up, and is owning more of the valuable work? A.I. Orchestration is a way of reducing waste, removing needless inconsistency, and giving people a more coherent environment to work inside. Those values align exactly with design system teams. A.I. orchestration is simply the instrumentation we needed to finally deliver on the promise of design systems.
What's next
I anticipate having more to say on this topic as I begin to validate these concepts against my design system for my personal productivity apps.
Not every scenario above applies to my case one-to-one, for example, I am both the internal support person, customer, and maintainer. But it's a perfect position to experiment. My question becomes which mundane loops still exist (parity, releases, consistency, and even confusion) still exist regardless of design system scale, and which routines actually earn time back.
There are several tools aimed at the meta-org space, but I've been working with Paperclip. Paperclip works particularly well with OpenClaw, but I am using Cursor CLI.
If you are doing similar work in a larger org, I would like to hear from you! Where could you see value in using orchestration in your work? If you're already using it, what value are you seeing?
Email me at hello@stevendeeds.com.