Working Thesis · June to July 2026

Design That Keeps Pace With AI Is an Architecture Problem

I design the systems around the screens: agentic experiences, the identity systems that give them trust, and the owned, federated MCP architecture that lets AI generate real, compliant product, with humans directing. Below, one request through that system, told for whichever room the reader is in.

This is my thinking from June and July 2026, a snapshot and not a finished position. The facts in it were re-checked in October 2026, and where a claim is a proposal and not a standard, the page says so.

The whole argument in one read.

The Short Version

Production Is Abundant. Direction Is the Job.

AI can now generate screens, components and code faster than a design process can review them. That moves the hard problem from production to architecture: who owns which part of the system, what a model is allowed to touch, and what must be checked by code instead of trusted to judgment.

My answer is an owned, federated architecture. A person sets the goal in plain language. A Claude orchestrator plans, and a small set of agents with narrow roles gathers context, builds the flow and runs the checks. Every call to a tool or a data source crosses one MCP gateway that the company runs, so the permissions, the monitoring and the audit trail are the company’s own. Nothing ships until a person approves it.

The part that makes this design work, and not only engineering work, is the split between the Skin and the Skeleton.

  • The Request, Recorded

    Trace Flow →

    One request as a sequence diagram, with the log that records it as it runs.

  • The Request, Told Three Ways

    Dynamic Workflow →

    The same system walked step by step for the business, for engineering and for design.

  • The Reference Diagram

    Static Architecture →

    Who owns what, where the gateway sits, and the path from intent to approval.

The Durable Layer

Skin and Skeleton: What Design Actually Owns

Nearly a decade ago, Alla Kholmatova split design systems into two kinds of pattern: functional patterns, the concrete parts like buttons and forms, and perceptual patterns, the expressive styles that carry personality, like color, type and motion (Design Systems, 2017). In an AI-generated world, that distinction becomes an ownership decision. Skeleton and Skin are my names for the two owners.

Functional Patterns

The Skeleton

Engineering-Owned

The component substrate: the library, its prop contracts and what actually ships. Any capable agent can read it and assemble it. It is plumbing: necessary, valuable and increasingly commoditized, because AI can generate a button.

  • Lives in code, versioned in Git
  • Prop contracts generated from code, not re-authored
  • Swappable: MUI, Radix, in-house, whatever is next

Perceptual Patterns

The Skin

Design-Owned

The brand and identity system, meaning tokens plus brand rules. It is the layer that signals trust and makes a product recognizably itself. This is the invariant, and it is where design’s irreplaceable value concentrates.

  • Portable across any substrate
  • Tokens (DTCG format) plus structured brand logic
  • The part a person has to stand behind

One Skin dresses many Skeletons, which is why it survives when the front-end library churns.

Front-end libraries churn: MUI, Radix, in-house, whatever is next. Bind a system’s identity to a specific substrate and it is fragile; the day engineering re-platforms, the design system re-platforms with it. A portable brand and identity layer survives that. It is the same principle I would apply anywhere a system has to outlast its parts: loose coupling, or architecting for failure, applied to the design system itself.

This is also where I stop trusting the marketing. Vendors say their tool is “the source of truth.” The useful question is never which tool. It is which field, owned by whom, enforced how. A tool that owns visual intent does not therefore own behavior, policy or shipped pixels. Read the architecture, not the announcement.

And one honest limit, because a credible model names them: this does not mean designers live inside a chat window. Working through Claude is right for generation and decision, the high-leverage judgment. But visual craft and exploration still want a canvas. The canvas does not disappear; its job narrows to exactly where human visual judgment actually lives.

How the Thinking Moved

From “Code Is the Truth” to Federated Ownership

The earlier version of this thinking said code is the truth and Figma is the canvas: tokens as version-controlled JSON, components with machine-readable prop contracts, and parity as a pipeline instead of a person.

The later version keeps the pipeline and drops the slogan. There is no single source of truth. There is federated ownership: each field has exactly one system of record, token values live in the repo and sync to Figma, prop contracts are generated from code, and a drift checker flags mismatches instead of silently deciding which side wins. The reason is simple: a tool that owns visual intent does not therefore own behavior, policy or shipped pixels.

Point of View

Four Positions This Architecture Takes

Each is a deliberate decision, and each is defensible against current practice.

  • Federated Truth

    No Single Source of Truth. Federated Ownership.

    Visual intent belongs to Figma; component identity, behavior and policy to the registry; token values to the repo, synced to Figma; shipped appearance to code. Different fields, different systems of record. Drift is flagged, never silently resolved: the system surfaces the mismatch and a human decides.

  • Human in the Loop

    Judgment Is the Thing Under Test

    A legal disclosure, an accessibility rule or an approval gate cannot be verified by trusting a model’s inference, so a deterministic validator checks the work. The agent’s judgment is exactly what is being tested. That makes human-in-the-loop structural, not sentimental, and it makes the designer meta: I design the system that designs.

  • Own the Doorway

    The Gateway Is Ours. Vendors Connect Under Our Policy.

    Every agent reaches every system through an MCP gateway the company runs: its permissions, its monitoring, its audit trail. Vendor servers, including Figma’s write-to-canvas server, plug in under those policies instead of defining them. The MCP specification covers how a client connects and authorizes; the gateway, and the audit log it keeps, are what this architecture adds. Owning the doorway turns “AI in the workflow” from a risk conversation into a governance capability.

  • Lean by Design

    Bind Only What Must Never Go Wrong

    Schemas are not for the agent to comprehend; they are for a validator to check its work. So the must-not-fail set is bound rigidly and a capable agent reasons over the rest. The test is one question: if this were violated once, would that be acceptable? If not, it is a guardrail, enforced in the pipeline. Over-specify everything and the result is the brittle, rigid system AI was supposed to dissolve.

Intellectual Honesty

What’s Honestly Unsolved

A credible architecture names its open problems.

Evaluation is young: measuring generation quality and retrieval accuracy takes real eval suites, and most teams, including this proof of concept, are still building that muscle. Model behavior shifts between versions, which is exactly why the deterministic guardrail layer exists. And the hardest part is not technical at all: it is organizational adoption.

That is why the operating stance is adaptation. No one has the proven playbook yet. The advantage belongs to teams whose systems are built to absorb change: tokens that propagate, contracts that version, agents whose rules are edited in one place, a Skin that outlives its Skeleton. This page, the design system it links to and the process that built both are that stance, practiced.

Checked in October 2026

What to Know Before Relying on This

Four facts that shape how far the architecture can be taken today.

  • MCP

    The Model Context Protocol is an open standard for connecting AI applications to outside systems. Its specification includes an optional, OAuth-based authorization step for remote servers. It does not define a gateway or an audit log. Those are the layer this architecture proposes.

  • Tokens

    Design tokens are written in the Design Tokens Community Group (DTCG) format, which reached its first stable version in October 2025. It is a Community Group specification, not a W3C standard.

  • Figma

    Figma’s write-to-canvas tool lets an agent build in a Figma file with the team’s own library, and it needs a Full seat. Writing tokens into Figma variables through the REST API is limited to Enterprise organizations; a plugin is the alternative on other plans.

  • Illustrative

    The timings, counts and audit-log totals in the diagrams are example values chosen to show the shape of a run. They are not measurements.

The Architecture, as a Request Trace

One Request, Traced End to End

A sequence diagram is how systems are actually read: actors across the top, time flowing down, every call explicit. Run the trace to watch one request move through the system. The log beneath it appends as it runs, because in this architecture, the audit trail is not a feature. It is the medium. Select any actor for depth.

trace: one-request.e2e · owned-mcp architecture
idlePress run, or select any actor.
personjudgmentorchestratorclaude · manageragentsclaude ×3 · rolesmcp-gatewayowned · auditedtruth (git)tokens.json · contractsknowledgerag · memory · datapipeline (ci)deterministicfigmacanvas · mirrorintent("outcome, in plain language")plan(): steps · owners · checkpointsloop [ until goal met ]delegate(task, role, constitution)request(scope), least privilegegateway: check scopes → write audit-logread: tokens.json · prop-contractscomponents · tokensretrieve: personas · research · decisions · evidence (rag)top-k context, citedcontextresults → synthesize · re-delegatesubmit(draft)enforce: disclosures · a11y · brand · perf-budgets✓ pass, or it stops herecheckpoint: request approvalapprove() · name + time recordedship: write canvasmerge: pr → gitBACKGROUND · CONTINUOUSsync (ci): tokens.json → style-dictionary → theme · → figma variableslog: outcomes · decisions → memoryaudit-log: gateway calls + pipeline events

Trace Log: Appends as the Request Runs · This Is the Audit Trail

// idle. run the trace, or select an actor above.

An illustrative run: the timings and entry counts are example values, not measurements.

The Architecture

One Request, Through the Whole System

The same eight-step system, told three ways. Choose the lens that matches how the reader would evaluate it: the story on the right rewrites itself while the map holds constant. Scroll or step through, and select any part of the map to jump to it.

Read as a product leader. One request becomes a shipped, compliant flow, and the speed, with control kept, is a business advantage.

System MapBusiness View
PEOPLETHE AI TEAM · CLAUDESOURCES · ONE OWNER EACHMCP GATEWAY · OWNEDPersonsets the goalsigns offOrchestratorplans & assigns, with sign-offsResearch agentfinds what is already knownDesign agentbuilds the draftValidatorchecks the rules, every timeGuardrail spinethe must-pass rulesBrand & identityBRAND · OWNED BY DESIGNComponent substrateCOMPONENTS · OWNED BY ENGINEERINGProduct contextCUSTOMER RESEARCH · PERSONASLive evidenceLIVE USAGE DATAFigma canvasWHERE DESIGNERS CRAFTThe workshipped · reviewed
audit log: every call recorded (illustrative count)00 events
01 / 08

Step 01 / 08

It Starts With a Person

Weeks of spec-writing collapse into a sentence.

A product lead might say: we need a field-inspection assistant for our technicians, live this quarter. That is the brief. The point of this architecture is that intent like that is the starting point: no requirements relay race, no fidelity lost between the person who knows the goal and the system that executes it.

Step 02 / 08

One Plan, Made by Claude

A plan in seconds, with approvals built in.

The system turns that one line into a plan: which screens, which compliance rules, which data it needs, and the exact moments a person signs off. Nothing runs unsupervised. For a business, that is speed and control, not a trade between them.

Step 03 / 08

A Small Team of Specialists

A team’s accountability at automation’s speed, with a validator that cannot be overruled.

Three focused roles: one gathers context on the technician and their job, one builds the flow, and one checks it against brand and law. The validator’s verdict comes from deterministic checks, so the other agents cannot argue it out of a failure. Quality stops being a hope and becomes a gate.

Step 04 / 08

Everything Crosses One Doorway We Own

The audit trail a legal team will ask for, recorded as the work happens.

Every request for data or a tool passes through one gateway the company controls. When a customer audits how the AI made a decision, the record already exists. In regulated, client-facing work, exactly the frontline context I design for, that is the difference between shipping and not.

Step 05 / 08

It Works From Federated Sources

Built from the real brand and the real product, not a mockup.

The flow is assembled from design’s real brand system and engineering’s real components, grounded in research and usage. It is not a throwaway picture to rebuild later. It is the real thing, which is why weeks of rework disappear and why the result already looks and behaves like us.

Step 06 / 08

Nothing Ships on the Model’s Word

Compliance and quality are enforced, not trusted.

Before anything moves, the must-not-fail checks run: the AI disclosures the law requires, accessibility, brand and performance. It passes or it stops. Risk moves from hope the team caught it to the system will not let it through.

Step 07 / 08

A Person Approves. Always.

Faster to value, without giving up the wheel.

The finished flow returns to a person, real, reviewable and versioned, and ships only when they say so. The business reaches product value in days instead of quarters, and a person is still accountable for what goes out. Speed and control, together.

Step 08 / 08

The System Remembers and Flags Drift

Every project makes the next one cheaper and faster.

What worked, and the decisions behind it, flow back into the system. The second flow is faster than the first; the tenth faster still. The asset is not any one screen. It is a process that compounds, which is how this pays for itself many times over.

Under the Hood

The Federated Model, in Full

The accurate version. There is no single source of truth. There is federated ownership: each field has exactly one system of record, tokens live in the repo and sync to Figma, prop contracts are generated from code instead of re-authored, and a drift checker flags mismatches instead of silently deciding which side wins. Deliberately lean: a spine to extend, not a cage.

Reference Architecture: Federated · Owned · Leansolid = request path · dashed = automatic or background
DIRECTIONPersonintent(), plain languageApprovehard human gate:judgment under testINTELLIGENCE · CLAUDEOrchestratorplan() then validate() then draw()Research agentretrieve(), least privilegeDesign agentcompose(components, tokens)Validatorverify(policy): deterministic, blocking, separate dutyeach: one role · a constitution · minimal scopesthe agent’s judgment is what the validator testsFIELD OWNERSHIP · NO SINGLE SOURCE OF TRUTHvisual intent → Figma (the canvas)token values → repo (DTCG format) → synced to Figmacomponent identity + behavior → registrypolicy / guardrails → registry (the lean spine)shipped appearance → code, not Figmaprop contracts → generated from code, never re-authoredDRIFT IS FLAGGED, NEVER AUTO-RESOLVEDcompare_figma_to_registry → { status: "failed", differences: [...] }the system surfaces the mismatch; a person decides which side winsOWNED MCP GATEWAYauthz · scopes · monitoring · append-only auditvendor servers connect under our policy, not the reversedesign-systemproduct-contextanalyticsfigma · vendorTHE SKIN · BRAND & IDENTITYdesign-tokens.jsonDESIGN-OWNED · REPO (DTCG) → SYNCED TO FIGMAbrand rulesDESIGN-OWNED · STRUCTURED, MACHINE-READABLEone Skin, many Skeletonsthe portable, durable layer: it survives when thefront-end library churns. Loose coupling, appliedto the design system itself.THE SKELETON · COMPONENT SUBSTRATEcomponent libraryENGINEERING-OWNED · WHAT SHIPSprop contractsGENERATED FROM CODE · NO PARALLEL YAML TO DRIFTthe lean guardrail spinemust-not-fail policy only: legal disclosures · a11y ·brand · perf. Enforced by the validator and CI.as lean as the guardrails require, no leaner.CONTEXT · EVIDENCE · CANVASproduct contextpersonas · JTBD · journeys · research (RAG + memory)live evidenceproduct analytics: aggregate, read-onlyFigma canvasdesign-intent surface, where people do visual craft.Kept in sync and drift-checked. Not production truth:shipped pixels are rendered by code.all access crosses the gatewayship on yestokens sync → Figmaoutcomes → memory, via the gateway