Where does intelligence belong?
The brief usually says “add the assistant”. The useful question is where intelligence belongs: which surfaces, which objects, how much, and when a person takes over. Five rules for designing AI into a complex product.
Every AI brief I have seen in the last two years arrives in the same shape: add the assistant. A chat window, a sparkle icon, a place to type. It is a reasonable request from a product team that has watched the demos. It is also the wrong first question.
Treat AI as a feature and it behaves like one: it gets added to each part of the product by whichever team gets there first. An AI summary here, an “Ask AI” button there, a recommendation module somewhere else, and a chatbot floating over everything, each with slightly different behaviour. That is not intelligence. It is fragmentation with a gradient.
The brief says chatbot. The job is to decide where intelligence belongs.
Deciding where intelligence belongs is an architecture question with a small number of parts. The worked example below is the AI-assisted data onboarding I designed for KNIME's Analytics Platform, where the brief was exactly this: help novices get data in without taking control away from experts. The rules apply to any complex product.
1. Objects before agents
Users think in the objects of their domain. In KNIME that is a workflow, a node, a connection, a dataset, a column. They do not think in models or capabilities, and they should never have to. So the first question was not what the assistant says but what the AI produces that is not already an object. Four things: the Input File the user brings in, the Suggestion the AI makes, the Node Draft it pre-fills, and the Explanation behind each decision.
Because every AI output is a first-class object, it has state: suggested, applied, modified, rejected. That is exactly what trust, undo, history and analytics need. A new data source is a new Input File variant, not a new feature, and “explain this setting” is a better prompt than “ask the assistant” because the object already carries the context.
2. The smallest intelligence that solves the need
A conversation is the most expensive interaction a product can ask for. Most needs are smaller. In KNIME, a novice who drags in a CSV needs three things: the first rows of their own data, a suggested reader node with its settings, and an Apply button. No prose. An expert who pastes a database connection string needs even less: a pre-filled draft to skim, host and schema to edit, apply. The same four objects serve both; nobody learns two systems.
The general rule: home prioritises, search finds and routes, the object page explains, documents ground, and chat resolves what nothing else could. Chat is the last surface, not the first, and when it opens it should already know which object the user came from.
3. One grammar for what the AI proposes
Once a system can propose things on its own, the hard problem is not generating proposals but keeping them legible. If every capability invents its own card, the interface becomes a feed of whatever the loudest model said last. In KNIME every proposal is a Suggestion with the same anatomy: what the AI saw, what it proposes, Apply next to Info, always. Suggested settings are checkboxes the user can untick, not magic. The same grammar covers a delimiter, an encoding and a whole node draft.
The same rule scales up. On a large platform where many capabilities can raise signals on their own, put one composition layer between those signals and the user: it checks whether a signal is relevant now, maps it to a small set of user needs, deduplicates, ranks and renders one shared pattern. Four need types have been enough everywhere I have used this: something needs action, something needs awareness, something changed, something could help. New capabilities plug into that grammar instead of inventing a new card.
4. Evidence is part of the answer
Confident output without a visible basis is a liability in any domain where being wrong costs time or money. The fix is structural, not a disclaimer. In KNIME the trust anchor is the user's own data: the Input File card shows the first rows of the actual file before any suggestion. Each setting carries its reasoning in a side panel, not a tooltip: why, what happens if you skip it, when to use something else. Users inspect the basis of a suggestion rather than being asked to trust it. In testing that is where the trust comes from, more than from the quality of the prose.
5. The user applies; the AI only proposes
There will always be cases the system should not decide: an ambiguous schema, a connection it cannot verify, a setting with consequences downstream. The rule that made KNIME's design work is that only the user applies. Nothing appears on the canvas until Apply, every decision is written to a memory log, and anything applied can be modified or dismissed later. In products with human support the same rule becomes hand-off: the person enters the same thread with the object and the history attached, rather than starting again.
At platform scale this rule has a second half. When a person takes over, continuity is the design problem: the human enters the same thread with the object, the history and the evidence attached. Hand-off is part of the object model, not an exit, and it is where most of the trust in an assisted experience is won or lost.
What this does to the design system
None of the above required an AI UI kit. KNIME already had an assistant panel; onboarding lives inside it, with four components that share one anatomy: a glanceable zone, supporting details, and actions. Zero new navigation, zero new paradigms. The product looks like itself. The intelligence is in the behaviour, not the chrome.
AI does not need to look like AI to create value.
If you take one thing from this: before anyone draws a chat window, write down the objects, the surfaces, the one grammar for proposals, the evidence rule and the apply rule. That page is the product. The chat window is a detail of it.