Is dropping UI elements really an architecture problem rather than a model problem?

Yes. Across the production surfaces we have audited, the rate at which the model silently drops a required UI element typically sits in the 10–25% range when the model is responsible for emitting that UI as part of its text output. Moving rendering responsibility off the model to typed UI directives makes the failure mode structurally impossible.

How is a typed UI contract different from just having the model return JSON?

Returning JSON is a tactic. A typed UI contract is an architecture: the model emits which interactive elements are appropriate (and their data), the application owns how those elements are rendered. The frontend can refresh its rendering without touching the model; the model can be retrained without forcing a frontend redesign. Only the contract has to remain stable.

When is this pattern overkill?

For a single chat surface maintained by a small team where the entire product is short-lived, the markdown-renders-everything approach ships faster and is fine. The pattern earns its keep when the surface is multi-team, multi-platform, multi-language, or load-bearing for the business — anywhere reliability and longevity matter.

Why Your AI Chat Product Keeps Forgetting Buttons (And What It Costs You at Scale)

body{background:#050510;color:#fff;font-family:system-ui,sans-serif;padding:2rem;max-width:720px;margin:0 auto;line-height:1.6}Why Your AI Chat Product Keeps Forgetting Buttons (And What It Costs You at Scale)A chat-style AI product that occasionally drops a required UI element, mis-formats a list, or quietly omits a confirmation step does not have a model problem. It has an architecture problem — and it is the same one we keep finding in enterprise AI deployments. What healthy looks like, and how to get there.Solutions