Enterprise users had to act on model outputs carrying uncertainty a traditional dashboard would hide. A bare number creates false precision that erodes trust when the model is wrong; the full distribution overwhelms, and constant hedging makes the output useless.

I worked with the ML team to separate what the model knew from what it estimated, then designed a tiered disclosure system: high-confidence outputs surface cleanly, lower-confidence ones carry a visible signal built into the component, with a path to understand why. Mapping the thresholds together kept the UI's confidence language true to what the scores actually meant, so users can tell a solid number from an estimate at a glance.

The goal was calibrated trust: users believe the model when it's right and can push back when it's wrong.

A one-off AI widget is easy; an agent that follows a user through a whole session, aware of where they came from, what they're trying to do, and what they've already tried, is a different problem entirely. Most enterprise AI surfaces are stateless, so this agent had to hold context across the journey and use it to beat asking from scratch.

I mapped the journey through the platform to find where an aware agent would cut real friction: transitions between tools, points of failure or confusion, and decisions that sent users elsewhere to look something up. Ambient by default and interruptible on demand, the agent stays quiet until needed and immediately present when it is, so help shows up at the moment of friction instead of becoming one more thing to manage.

Working sessions with product and ML settled what the agent should know versus ask: what the system could infer reliably, what it should confirm, and where assuming too much would feel intrusive. The agent's personality follows those limits, confident where it has signal, honest where it doesn't, which is what makes it worth trusting across a whole session.

AI surfaces bring a constraint most product work never sees: the system's behavior isn't fully predictable, and the reasons for its decisions can't always be surfaced. Users want to know why, the model doesn't always have a clean answer, and the product has to hold that gap without making either look bad.

I ran working sessions with ML engineers to pin down exactly what the model could and couldn't explain about its own outputs, then built a design vocabulary for explainability: what level of explanation each output type allowed, how to communicate it honestly, and how to handle cases where no explanation could be offered.

Graceful degradation covered the rest: the unavailable, underconfident, and out-of-distribution states each got their own copy and recovery paths. A silent model failure is a trust problem; a well-handled one is a product moment.