Atelier
Our color and font tools, packaged so the AI assistants we work with can use them too, making designs that follow the rules from the start instead of checking them afterward.
Our generation engines, as tools an agent can work with.
8
Tools exposed
40
Candidates sampled per constrained generation
1
Source of truth, shared with the apps
4
Bugs found in real use, then fixed
Why we built it.
Design-token integrations on the market extract what a designer already made. They can tell you whether a palette is structurally valid, and they stop there. What we wanted was generation inside constraints, and a way to ask whether a palette answers the brief.
Meanwhile our own color and type engines lived inside two web apps, reachable only by a person with a browser.
The decisions we made, and why.
This part gets into the technical detail. If that isn't your thing, the short version is at the top of the page.
We bundle the real engines, rather than a copy
The palette and pairing engines are built from the apps' own sources at build time, so there's one source of truth. Change an engine in the app, rebuild, and Atelier picks it up. A second implementation would drift within a week and then quietly disagree with the original.
Brief words map to axes, never to hex codes
Mood words resolve to positions on warmth, lightness, and chroma axes, and generation is sampled against those targets. Words never map to specific colors, because that would be a lookup table dressed up as a generator.
We report fit separately from structure
Structural validity, meaning distinct colors and a usable lightness spread, says nothing about whether a palette answers the brief. We return the two as separate fields, because merging them would let a sound palette that ignores the brief report as a success.
What we only learned by testing.
Every item below is a real problem we found by measuring, and each one has a fix behind it. We share them because they tell you more about how we work than the features do.
The warmth metric was inverted
Warm briefs were selecting cool palettes. The tool was confidently wrong in a way structural checks couldn't catch, because every palette it returned was valid. They were simply answering the opposite question. A session using the tool on real client work found it, ahead of its own tests.
Chroma was scaled against an unreachable ceiling
The scale topped out at a saturation the generator couldn't produce, so a maximum-chroma request was impossible to satisfy and the fit score stayed permanently pessimistic.
Unmatched brief words were silently ignored
A brief with words outside the vocabulary produced an unconstrained palette and reported success. Now it stops and names the words it didn't understand. Quietly dropping half an instruction and returning a confident result is the worst thing a tool can do.
Knowing its limits is part of the tool
When we asked it for a neon accent for this site, it returned muted palettes and reported 'electric', 'loud', and 'confident' as out of vocabulary. That was the right answer. It deals balanced palettes, and a neutral system with one saturated structural color is a different problem, so we derived the accent by measurement instead. A tool that reports its own boundary is more useful than one that always produces something.
Built with, and still open
- Node
- Model Context Protocol
- Umber engine
- Kern engine
- The font moods filter by broad category only. The catalog carries usage tags rather than typographic classifications, and we'd rather promise only what the data supports.