Monogram: Live Parameters

Monogram’s model is optimized to craft intuitive interfaces on the fly bespoke to the prompt and the content being shown. Ask for a cookie recipe and it builds a recipe screen. Ask it to compare two cars and it builds a comparison. These visual UIs allow us, as humans, to process information thousands of times faster than reading a chat window.

It’s why I can’t stop using it.

Monogram knows how to answer a question visually. But a lot of the questions we ask rarely arrive fully thought out. When you go looking for something, you usually can’t name exactly what you need. If you could, you wouldn’t have the gap in the first place.

For example, I ask “What are the best sushi restaurants around me?”…followed by “a little more upscale”…followed by “for a party of five”. That first answer is a starting position, the real job is steering it toward the version that fits my constraints. Sometimes, I don’t even know what my constraints are until I see them in front of me. That’s how people discover. We look at our choices, talk through them, and narrow. It's kinda serendipitous.

But for Monogram, this means generating a whole new interface for each question I ask. The visual interface I was reasoning against disappears, and my train of thought goes with it. Every turn becomes fragile. This begged the question:

Monogram doesn’t generate pixels, it assembles a fixed catalog of native components, styled by a design system and described in a protobuf contract. Bounded composition, not generative rendering.

The model owns which components and what content while the app owns how they look. So my solution had to live inside that grammar and add no new primitives. The design needed to be sensitive to the model behind it.

I ran hundreds of prompts and watched how it reasoned. A pattern surfaced. In every request, the model reasons quietly with a set of adjacent values. Assuming through the ambiguity.