Skip to content
Marcus Gonzalez

Employee Pattern Library

When AI agents write the UI, design owns the system that shapes it.

Generated UI now begins with the Home Lending Employee Pattern Library, shaped by the mistakes agents actually make. Replacing the layout API agents got wrong most often cut misuse from ~95% to near zero1, and the replacement held across three model generations2. Design ships the code every first-party employee platform imports.

Fig. 00 · Illustrative model · Request → API → UI

The component API shapes generated UI before review begins.

Cobalt marks the layer design owns: the component APIRequest → component API → generated UI
A product team asks an agent to build an employee workflow. The request passes through the Home Lending component API, which re-themes, composes, and extends MDS, and leaves as generated UI already shaped before design or engineering reviews it.
Context01

Unity would bring every Home Lending employee product into one architecture. A shared design-system foundation had not made employee applications feel like one system, because each team decided for itself how the pieces fit together.

Fig. 01 · Context · Three forces

Three forces made a Home Lending layer necessary.

  1. 01The quality gap

    Consumer products felt coherent. Employee tools looked like separate teams had designed them in isolation.

  2. 02Project Unity

    Products that once lived apart enter one architecture. Cohesion becomes structural.

  3. 03A composable core

    MDS supplies the foundation while product teams own more component-level decisions.

The necessityHome Lending needed one opinionated layer, decided once for every product entering Unity.

The mandate, Unity's architecture, and the composable coreQuality gap · Unity · composable core
Three forces converge: a quality gap between consumer and employee products, Project Unity making cohesion structural, and a composable MDS core that leaves component decisions to product teams. Together they make a Home Lending layer necessary.

Product leadership wanted employee tools to match the quality of consumer products while retaining the denser workflows enterprise software requires. The inconsistency lived above individual components: teams used Chase Manhattan Design System (MDS), but each composed its parts differently. Home Lending needed an opinionated layer that made those decisions once for every product entering Unity.

I brought the employee design teams together to define that shared language. The library had no engineering team, so design also had to own the production package.

Problem02

MDS gave product teams room to decide. Its APIs gave agents room to guess, and the guesses still compiled.

MDS intentionally leaves composition decisions to product teams. Its API names, event contracts, composition patterns, and defaults also differ from conventions common across other systems. Engineers learn those differences; agents default to the conventions in their training, producing code that looks finished while nesting parts incorrectly, doubling spacing, or applying the wrong default.

Fig. 02 · Problem · API divergence

Four places MDS differed from common conventions.

API namingMDSMDS uses different prop names for similar ideas across components.Instead1The agent reused the vocabulary it had seen most often.
SemanticsMDSMDS gives related events different contracts.InsteadThe agent guessed at the boundary and produced plausible code.
CompositionMDSA simple card required several components and a spacing wrapper.InsteadThe agent nested parts incorrectly and added spacing twice.
DefaultsMDSLayout centered content where common systems default to stretch.InsteadThe agent generated the common behavior, not the MDS default.
1

Review fixes one result. It does not change the API, so the same mistake returns on the next run.

Representative differences, not the full API surfaceThe code still compiled
A table of four differences between MDS and common conventions: API naming, semantics, composition, and defaults. In each, the agent produced plausible code from its training priors that did not match MDS. The code still compiled.
Research03

Validation corrected each run, but the same failure kept returning. The fix that finally held was removing the cause from the API.

The evaluation loop separated tooling problems from component problems. The Agent UI SDK handles isolated mistakes through guidance or automated checks. When the same rule fires in nearly every run, the component is creating the failure and the library changes.

Fig. 03 · Research · Repeated evaluation

Layout across three interventions.

  1. ~95%
    No validationLayout misused in nearly every generation.
  2. ~95%1
    Validation addedThe same rules corrected every run.
  3. Near zero
    Component replacedNear-zero misuse without special guidance.
1

The correction kept returning until the component changed. Validation exposed the cause; it could not remove it.

Measured in repeated evaluation runs1Validation held the rate; replacement dropped it
Layout misuse across three interventions, drawn to scale: about 95 percent with no validation, about 95 percent again once validation was added, and near zero once the component was replaced. The first two columns stand equally tall; the third collapses to a hairline.
Decisions04

I set a narrow boundary for the library: build on MDS, add what Home Lending needs, and replace an inherited API only when repeated evidence shows that the API causes the failure.

Set the boundary with MDS

Fig. 04 · Decision · Re-theme · compose · custom

The library extends MDS in three layers.

1

Custom code is the narrowest layer. It is reserved for a missing product capability or a failure traced to the inherited API.

Width shows scope; cobalt marks the narrowest, reserved layerRe-theme · compose · custom
The three layers drawn as a narrowing stack: re-theme is the broadest layer, compose sits inside it, and custom is the narrowest, reserved for a missing capability or a structural failure.

Ship the standard, not another specification

No engineering team staffed the library, so I used agents to build the package, reviewed the components in Storybook, and published them to the internal registry. Engineering imports the same code that design approved. The standard no longer depends on a handoff or a team interpreting a specification.

Fig. 05 · Illustrative reconstruction · Storybook

The library in Storybook: 13 components extending the firm's core system.3

Home Lending libraryStorybook
  1. AppShell
  2. ▸ Surface
  3. VStack
  4. DataGrid
  5. HStack
  6. Spacer
variantpadding
Illustrative reconstructionSanitized capture pending
1
1

Storybook is where design and engineering meet the same artifact. Design reviews the rendered component; engineering imports that exact component from the package.

Illustrative reconstruction · production UI and values differRendered component · published package
A reconstruction of the library in Storybook: a component list on the left with one component selected, and the rendered component with its controls on the right.

Fill the gaps MDS leaves open

MDS did not include the data grid or application structure Home Lending needed, so the library adds both. AppShell separates shared navigation from page layout: standalone products use the full shell, while products inside Unity inherit its navigation. Named regions and strong defaults support complex side rails and responsive layouts without asking each team to design the structure again.

Fig. 06 · Illustrative reconstruction · Custom components

Custom components fill genuine gaps in the core.

Missing capability · Data grid
Data gridmissing capability
Illustrative reconstructionSanitized capture pending
AppShell · standalone or embedded
AppShellshell + content layout
Illustrative reconstructionSanitized capture pending
1
1

These are additions, not replacements. Standalone products use the full AppShell; products inside Unity inherit its navigation and use only the content layout.

Illustrative reconstruction · production UI and values differData Grid · full shell or inherited navigation
Two reconstructed surfaces: a robust data grid for complex employee workflows, and an AppShell that separates shared navigation from page layout so the same system serves standalone apps and products embedded in Unity.

Replace the API only when the API is the problem

I replace a component only when using it correctly requires guidance so specific that the agent loses flexibility. Layout reached that point first: validation caught the same misuse on nearly every run. Tile followed; agents latched onto prescribed examples and branching paths instead of composing freely. I replaced Layout with HStack, VStack, and Spacer, and Tile with Surface. The simpler APIs held across three model generations without changes to their code or guidance2.

Fig. 07 · Illustrative reconstruction · API replacement

The same card generated with Tile and Surface.

Before — Tile · the agent's attempt
// agent output — 3 parts + wrapper<Tile padding="md"> <Spacing inset="md"> ← double pad <Tile.Title>Rate lock</> <Tile.Body>…</> </Spacing></Tile>
Illustrative reconstructionSanitized capture pending
After — Surface · fewer parts
// one component, one spacing rule<Surface padding="md"> <VStack gap="sm"> <Heading>Rate lock</> <Text>…</> </VStack></Surface> 
Illustrative reconstructionSanitized capture pending
1
1

Surface removes the need for prescriptive guidance. Its simpler structure lets agents adapt the component without relying on narrow examples and branching paths.

Illustrative reconstruction · production UI and values differSurface removes the extra wrapper and second padding layer
Before and after: the verbose Tile composition an agent reaches for, three parts and a spacing wrapper that doubles the padding, becomes a single Surface with one spacing rule. The rendered card loses its doubled inset.

Feed the evidence back to MDS

Replacing an MDS component locally does not end the relationship with the core system. When evaluations trace a repeated failure to an MDS API, I bring the evidence to the central team during our monthly working sessions. Together, we improve MDS components and the tooling that helps agents use them.

Status05

The library is mandated across Home Lending and now turns production evidence into improvements for the central design system.

Scope
The 13-component library extends MDS through Home Lending themes, reusable employee patterns, missing capabilities, and targeted replacements.
In motion
I review Home Lending API findings with the MDS team each month and work with them to improve its components and AI tooling.
Trajectory
The library shows that a product team can operate its own MDS layer without a dedicated engineering team and feed its findings back into the core system.
Measuring
The team tracks adoption on new employee work, component misuse in generated code, and whether the APIs continue to hold through model changes without retuning.
Evidence and sources

1~95% to near zero — Comes from repeated evaluation runs of the flagship Layout component across three states: no validation, validation rules firing, and replacement with Stacks.

2Three model generations — The replacement APIs held across Opus 4.6, 4.7, and 4.8 without changes to their code or guidance.

313 components — The current library extends the firm's core design system with 13 components, hosted in Storybook and distributed through the internal package registry.

Contact

When agents write the UI, does the design system become the strongest place to put a design decision? If you're rebuilding one for that, let's talk.

marcus@marcusjg.comLinkedIn

Next case →

Agent UI SDK + Eval Framework

The threadThe design system changes when repeated failures point back to the API. The next case is the instrument that separates a component failure from a tooling one.