A component library is not a system of decisions
It gives a team buttons, inputs, modals, tables, and a shared visual language. That is valuable work. On Strata — Avanto, via Agentic Dream, an enterprise operations platform whose accounts include CBRE and Bank of America — it was also not enough. Consistency of parts did not make the Action Center coherent when a workflow changed, a new role appeared, or an automated suggestion needed a human decision.
The difference is simple: a library gives a team parts. A design system gives the parts a set of decisions they are expected to preserve.
Reuse is not the same as agreement
On Strata, roles named the work: Action Item, Task Row, Workflow Step, Timeline Event. Each carried variants for type, priority, and state. The same modal and surface patterns showed up across the Action Center — and until the state model was documented, the same chrome could mean three different things.
One use interrupted an operator before a destructive action. Another asked for confirmation after work had already been queued. A third framed a human review of an agent proposal. The surface was reused; the meaning was not. If neither decision is documented, the next screen chooses based on what is in front of it, not the workflow the product is trying to protect.
That is the familiar drift: the library grows, but product decisions keep being made locally. Each feature looks related while carrying slightly different rules for permissions, errors, defaults, ownership, and recovery.
The system starts where those rules become explicit.
State is the missing layer
Most component documentation explains appearance and interaction: variants, sizes, spacing, and props. For a multi-role enterprise Action Center, the sharper question is what a state means.
What makes an item pending versus exception? Who can resolve it? What evidence establishes that an automated recommendation is reliable enough to act on? When does an operator need to see provenance, change the decision, or hand it to someone else?
Those are not edge cases. They are the product.
As sole designer on the system, I worked daily with the CEO, PMs, and engineers. The rule I used: add a system rule when a real workflow needs one — not when a catalogue looks incomplete. Record why it exists, what state it represents, who owns it, and what would break if it changed. Eight custom components (not restyled library atoms) carried that logic into the places engineering actually builds from.
Get Sebastian Balderas Espinosa’s stories in your inbox
Join Medium for free to get updates from this writer.
When states sit alongside components, the library becomes a vehicle for product logic. A banner can support a known exception with a required explanation and a clear recovery path. A row can carry ownership and provenance, not just columns. A confirmation pattern can distinguish review, approval, and irreversible action.
Automation cannot infer the contract
Agents and generative tools can assemble a plausible interface from a prompt. They can reuse a visual language and produce a first pass faster than a team can schedule a design review.
What they cannot infer safely is ownership and evidence.
They do not know which exceptions need a human owner, what a reviewer must see, or whether a suggested Action Item is allowed to execute without review. Those rules need to exist before a human or an agent can apply them consistently.
That is why the useful deliverable is not “a design that AI can reproduce.” It is a system that makes allowed decisions, states, and boundaries explicit enough for humans and tools to work from the same contract.
In practice that contract crossed surfaces. Figma supported collaborative exploration with Product and engineering. Storybook was the versioned implementation contract engineering built from. Semantic tokens and documented workflow states kept both sides from inventing a parallel meaning for the same badge.
No one surface did all of the work. The contract is what kept them from contradicting one another.
Governance beats volume
The answer is not to create every variant before the product needs it. On Strata, governance meant adding the rule when the workflow forced the question — then making the decision available where future work would need it: tokens, component docs, and Storybook.
This is slower than copying a component once. It is faster than revisiting the same unresolved question in every feature.
A component library is a useful beginning. A system of decisions is what lets it stay useful as the product, the team, and the automation around them change.
I write about workflow-heavy product systems on my site: https://sebastianbalderas.com.
If this is the decision your team is stuck on, I work on it as a fixed-scope engagement: Design system as code — tokens, Storybook, engineering handoff: https://contra.com/s/XrcOYFZl-design-system-as-code-tokens-storybook-engineering-handoff.
