Concept

The design context layer.

Aestheria is a design context layer for enterprise SaaS: it gives AI agents the design context they need to generate product UI that stays consistent on the system, without feeling lost or boxed in.

Why context, not rules

When generation goes wrong, it fails in one of two directions. Too little freedom and every app collapses into the same header, metric row, chart, and table. Too much freedom and the agent invents its own buttons, filters, and type, and the brand quietly erodes.

Both failures share a root: rules only say what is allowed. They never help decide what is right. Deciding what is right takes context: knowledge of the product, the task, and the system, available to the agent at the moment it builds.

That is what Aestheria supplies. Not a longer rulebook. The context a designer would bring to the same brief.

The three layers

The context layer is built as three layers working together. Everything Aestheria does, from what the MCP serves to how a generation is reviewed, maps back to one of the three.

The floor is enforced, the ceiling is earned, and the judgment is what makes the result feel designed rather than assembled. The sections below take each layer in turn.

The foundations

The floor that never moves. A small set of foundations is reinforced in every generation, in a routine settings table and in the most ambitious custom visualization alike, because they are what make a hundred generated surfaces read as one product.

The foundations, reinforced no matter what:

If the system has the control, the system provides the control. A filter is never a hand-rolled input, a heading is never a hand-picked font size, and an icon is never an improvised glyph. This is the layer that quietly protects a brand: no single violation looks serious on its own, and a dozen of them dissolve the product.

The floor is enforced rather than suggested. Generated work is checked against it, so a raw control, a hex value, or off-scale spacing is caught and corrected before delivery, and the foundations hold even when everything above them is custom.

The craft

The ceiling that rises to meet the product. The library is not infinite, and a design partner does not pretend it is: some designs genuinely exceed the inventory. A security posture explorer that maps datastores to data types to identities is a relationship map. No chart in any library builds that, and forcing it into a bar chart is not consistency; it is a worse product.

So the partner crafts. A bespoke piece is built for exactly the part no component expresses, and it is assembled from the system's own materials: tokens carry the color, spacing, and type; the data marks use the series palette; and every control, label, and input inside it is still a library component.

Custom is the marks and the arrangement, never the furniture. A bespoke visualization can invent its own geometry, but the search box beside it, the filters above it, and the type inside it never leave the system.

And reuse still wins by default. Bespoke is a deliberate act of craft for out-of-inventory work, not a habit; if a component fits, the component is used. That discipline is what keeps a hundred custom moments from dissolving the system they stand on.

The judgment

The product design layer that decides. Good product design starts before the first component is placed: what is the user here to do? What decision does this screen serve? What data matters most, and what is noise? What happens in the empty, loading, and failure moments?

This is intent before inventory. A design partner asks these questions first, because the right solution follows from them. A security posture explorer is not a KPI row; it is a map of relationships. A billing page is not a chart collection; it is a statement of trust. The task shapes the surface.

Judgment also runs after the build. Every generation ends with a critique through two lenses: did any foundation drift off the system, and is this good design for the task, or a generic dashboard with the values swapped? Findings become fixes before delivery, not review comments after it.

It is what separates a generated screen that fits the moment from a template with the values swapped.

Why it matters

The promise of AI-generated product UI is not speed alone. It is surfaces that fit the moment of need without a team hand-building each one. That only works when the generator behaves like a designer you trust: fluent in the system, curious about the task, and incapable of shipping off-brand work.

That is the standard for a design context layer. Not a rulebook the agent obeys. A partner the product team relies on.