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 zero, and the replacement held across three model generations. Design ships the code every first-party employee platform imports.

Fig. 00

The component API shapes generated UI before review begins.

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

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.

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

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.

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

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.

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

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.

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

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

Home Lending libraryStorybook
  1. AppShell
  2. ▸ Surface
  3. VStack
  4. DataGrid
  5. HStack
  6. Spacer
variantpadding
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.

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

Custom components fill genuine gaps in the core.

Missing capability: Data grid
Data gridmissing capability
AppShell: standalone or embedded
AppShellshell + content layout
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.

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 guidance.

Fig. 07

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>
After — Surface: fewer parts
// one component, one spacing rule<Surface padding="md"> <VStack gap="sm"> <Heading>Rate lock</> <Text>…</> </VStack></Surface> 
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.

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.

Looking back05

The library is mandated across Home Lending and its thirteen components now feed production findings back into the central design system: I review the Home Lending API findings with the MDS team each month, and misuse in generated code has stayed near zero across three model generations without retuning.

What I would do differently: treat the replacement APIs as the product from the start. The first months went into components that looked right; the durable value turned out to be the small set of APIs a model cannot misuse, and I would have measured misuse from week one instead of after the flagship component failed.

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 caseAgent UI SDK + Eval FrameworkThe 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.
Eval runvalidation contracts
▸ contract fired: overflow