State 2 · Agentic

State 2 begins when we stop treating the agent as a problem to be fixed with better prompts and start treating it as a reader who needs structured context. The leap is not technical; it is editorial. The agent reads what we give it. If we give it little, it invents. If we give it too much, it gets lost. If we give it the structured, it composes.

What changes

Six concrete changes separate State 1 from State 2.

One. Tokens with policy metadata

State 1 tokens are values with names. State 2 tokens are values with names and policies. The $extensions.policy field of DTCG 2025.10 allows the declaration of:

{
  "color.action.primary": {
    "$value": { "colorSpace": "oklch", "components": [0.53, 0.18, 26] },
    "$type": "color",
    "$extensions": {
      "policy": {
        "mutableBy": "agent:tier-2",
        "rollback": "auto",
        "requires": ["visual-regression-pass", "contrast-aa"]
      }
    }
  }
}

The agent reads that declaration and knows what it can and cannot touch. So does the human. Governance, which previously lived in implicit conventions, now lives inside the token itself.

Two. Contract testing with strict schemas

A Button in State 1 has props documented in Storybook. A Button in State 2 also has a JSON schema describing which props are valid, which combinations are forbidden, which tokens it consumes. When an agent tries to compose <Button variant="destructive-outline-ghost">, the schema rejects. The agent receives an understandable error. It retries within the permitted space.

Tools of 2026: Storybook Interactions with play functions, Chromatic TurboSnap, custom validators with Zod or JSON Schema. The principle: nothing the agent can propose should reach production without passing through the contract. See the full fiche of the Button primary with its fourteen states, the four techniques active in CI, and the five variants discarded along the way (fiche in Spanish in Phase 1).

Three. Policies as code

Open Policy Agent (OPA) has been in the infrastructure world for years. Translating it to design systems is direct: rules written in Rego that evaluate compositions before they render. Typical rules:

• A Button component with variant="destructive" requires a confirmation modal adjacent in the tree.
• Low-tier agents cannot mutate primitive tokens; only semantic or higher.
• A DataTable with more than ten columns requires an explicit density token; the default is not allowed.

These policies run in CI and, optionally, at runtime via WASM. They publish why they reject, which turns failures into didactic material.

Four. Consumption telemetry

In State 1 we usually do not know whether <Toast> is used a thousand times a day or none. In State 2, with OTLP flowing to Grafana or PostHog, we know which components render, on which routes, with which props, by humans or by agents. That telemetry is the feedback the system needs to evolve without guessing.

A typical discovery when activating it: 30% of the components of a system are used fewer than ten times a month. Material for pruning.

⁂ Lámina pendiente /images/arquitectura/kahn-servido-servidor-estado-2.jpg

Five. Exposure via MCP

The Model Context Protocol, published in late 2024 and mature by 2026, allows a server to publish tools that an LLM client consumes in a structured way. An mcp.system.company.com can expose:

list_tokens(filter?)              → available tokens
get_component_contract(name)      → props schema
validate_composition(tree)        → OPA + tests + a11y
render_preview(tree, context)     → screenshot + report

The agent stops imitating our design system. It starts using it as an API.

Six. Restrictive governance by default

The editorial rule of State 2, and this point is deontological, is:

The agent can only do what an explicit policy permits. The space of what is permitted is widened by documented human decision, not by omission.

This is the opposite of the Wild West of 2023–2025, where agents had open access and we trusted post-hoc review. In State 2, restriction comes by default and widens by merit.

What State 2 adds to the decomposition

The six layers of State 1 remain the same (atom, compound, rule, piece, family, state). What changes is that each layer is now machine-auditable and can be mutated under policy instead of by human convention. Four operational moves mark the leap:

• The rule becomes executable. What in State 1 was convention (pull request, code review) is written in Rego and runs in CI with auditable output. The policy rejects and explains why. The rejection is didactic material.
• Genealogy is documented. Each token carries its history (2019 as hex, 2022 as semantic alias, 2024 as OKLCH, 2025 with $extensions.policy). Genealogy allows the agent to understand the intent of a historical change and not only the current value.
• Dismantling is atomic. A compound component (<Card>) is explicitly decomposed into its recombinable units (<Surface> + <Stack> + <Heading> + <Action>). The agent can recombine inside the declared space without inventing primitives.
• Discards are catalogued. Proposed and rejected variants are documented with year and reason. A State 2 compendium is not just the list of what exists: it is also the list of what was rejected and why. Negative memory protects against reinvention.

The risk not worth hiding

There is an editorial danger. Turning the design system into something so structured that it stops being usable by humans without the help of an agent. That would be the failure. State 2 is not a state only for machines; it is a state legible by machines and humans. Every decision (every policy, every schema, every metadatum) must make the human experience equal or better. If a schema forces you to read JSON to understand a component, the schema is the problem.

The test: if a new junior designer joins the system and cannot contribute without mastering OPA, we have failed. State 2 has to be humanly readable and additionally machine-governable. The order matters.

What to do if you want to arrive at State 2

1. Check your State 1 is mature (the five questions at the end of State 1).
2. Migrate tokens to DTCG 2025.10 with OKLCH. Add $extensions.policy where it matters, leaving it open where it does not.
3. Contract test first, visual after. Chromatic is useful but it is not a substitute for a schema.
4. Pilot with a low-risk component (not the Button; the Badge or the Spacer). Learn the rhythm.
5. Publish OPA policies with clear messages. A rejection without explanation is opacity.
6. Do not expose MCP until steps 1 to 5 are solid. MCP on top of a brittle State 1 is a faster way to hallucinate.

State 2 is the state that can reasonably arrive at large organisations between 2026 and 2028. It is not the future; it is the next present.