A design system can tell an agent what exists. The next layer is helping it determine what the organization should do and why.
Maya Benari Aug 20, 2026
Imagine a product team asks for a purple Tag to represent Processing.
A component-aware agent can inspect the library and find the Tag.
A spec-aware agent can tell the team that purple is not a supported tone.
Neither answer reaches the actual design problem.
Processing is a product status. Before changing the component, the team needs to determine whether it maps to an existing status, exposes a gap in the shared taxonomy, or means something different only within this product. Adding purple locally would not merely extend an API. It would create new semantic meaning at the component level.
An experienced systems designer recognizes that distinction because she is reasoning across more than the component. She is drawing on the component's purpose, the status model it inherits, earlier decisions, related precedents, accessibility requirements, and the boundaries of local authority.
Most design systems do not represent those relationships in a form a person or agent can reliably traverse.
That is the layer I want to design.
Nathan Curtis recently described a spec-driven architecture for UI component development. In it, structured specifications normalize design intent expressed across Figma, prototypes, code, and authored requirements. Those specifications can be versioned, analyzed, transformed into other artifacts, and reconciled across platforms.
This is a significant move beyond treating Figma, a code library, or a documentation site as a singular source of truth. Different tools remain legitimate places to express intent. The specification layer makes that intent structured and portable.
It also creates an important boundary between inference and transformation. When a component can be rendered deterministically from a specification, an agent should not have to recreate it approximately. AI can operate where judgment is required while scripts handle the work that should be lossless, testable, and repeatable.
The result is much richer than machine-readable documentation. A specification can describe: