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.
When an AI chat product silently drops UI elements, breaks formatting, or skips confirmations, the cause is almost always architecture, not the model. The fix: stop asking the model to emit the visible interface, and let it emit only typed UI directives that the application renders. Failure modes that were probabilistic become structurally impossible.
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.
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.
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.