Designing how an AI behaves.

The situation

Underneath Conviva sits a deterministic data engine: every insight, alert, and KPI is computed from more than five trillion events a day, not guessed. On top of that engine sits an AI assistant whose interpretive layer is probabilistic and still evolving.

I was designing an assistant I could not fully trust yet. That is the honest version of the problem, and leadership named it directly. If users came to associate the assistant with the broad skepticism people carry about AI, that association could bleed into the whole product and undermine trust in the reliable engine underneath. The design could not paper over that tension. It had to be honest about it.

There was also no shared definition of correct behavior. Engineering could tell whether the assistant returned the right number. Nobody could tell whether it behaved the right way, because behaving the right way had never been written down.

The reframe

Most teams treat agent behavior as a tuning problem. You adjust the prompt, sample some outputs, decide it feels about right, and ship. Behavior becomes a matter of taste, owned by whoever last touched the system prompt.

I saw it as a design problem with a testable specification. How an agent expresses confidence, when it escalates, how it recovers: these are decisions, and decisions can be written as clauses that both engineering and the user can hold the system to. Not AI-engineer territory. Not vibes. I had argued exactly this in How to Lead Design in the AI Era, where the behavioral contract is one of the core frameworks. This was the chance to prove the thesis in a shipped product, with real analysts on the other end.

The work

The resolution was a stance I could name: constructive realism. The assistant is a persistent sidebar collaborator, always available and aware of the page context, but never the front line. I explicitly rejected the chat-first paradigm many AI analytics tools adopted, because a blank prompt creates a cold-start problem for users who do not know what to ask. Instead the assistant reads the page context, anticipates the likely questions, and offers suggested prompts. The framing held throughout: the data engine is the load-bearing system, the assistant is the acceleration layer. Remove the assistant and the product still works.

On top of that stance I wrote the behavioral contract. It is organized into seven named sections: Capabilities and Boundaries, Confidence Expression, Escalation Triggers, Memory Boundaries, Response Patterns, Failure State Handling, and Trust Recovery. The discipline behind every clause came straight from the book: if you cannot measure compliance, the clause is too vague. So each one had to be both testable by engineering and meaningful to a user. A clause engineering can verify but no user would feel is bureaucracy. A clause a user would feel but engineering cannot check is a wish. The contract holds only what passes both.

The contract opens with four seed sentences, a structure from the book. One defines what the feature does. One defines when to trust the output: the deterministic values, which can be relied on. One defines when to verify or seek help: the interpretive, probabilistic reasoning, which cannot be relied on the same way. One defines what happens when the system is wrong: it acknowledges the error directly, preserves the user's investigation state so their work is not lost, and offers an alternative path forward.

Underneath, the whole contract is grounded in five trust vectors from the book: Clarity, Control, Consistency, Disclosure, and Repair. Confidence Expression is the section where the central tension gets resolved in the interface. It is graduated. Deterministic data is presented as fact. Interpretive analysis carries hedging language. Speculative connections carry explicit uncertainty markers. A user can calibrate how far to trust any given output without needing to understand the technology producing it.

The outcome

Before the contract, engineering, product, and design each held different assumptions about how the assistant should handle uncertainty. The contract eliminated that ambiguity. It became the single most-referenced design artifact in cross-functional discussions: when a disagreement arose about how the AI should behave, the answer was check the contract.

That is the proof. A behavioral contract is not documentation of decisions already made elsewhere. It is the tool that makes the decisions, and it holds because every clause is verifiable by engineering and felt by the person on the other side. The book named the behavioral contract as a framework. This is that framework, running in production, governing a live assistant. The thesis is no longer a claim in a book. It is a shipped artifact.