One product, many AI touchpoints
Lansweeper’s AI experience is expanding beyond a chatbot: search, contextual suggestions, an AI workspace, MCP integrations and actions across the platform all give users new ways to work with their technology data.
The opportunity is significant, but so is the experience risk. If every AI surface uses different language, interaction patterns or trust signals, customers do not experience one intelligent product. They experience a collection of tools whose behaviour has to be relearned each time.
Three ways in.
Any action initiated through the Platform, AI or MCP should produce the same visible state across every layer.
Platform
Search, navigate and act in the product UI.
experience
Ask, create, automate and review.
clients
Use Lansweeper through external AI tools.
I wrote the Lansweeper AI Experience Manifesto to define what should remain consistent across those entry points. I then translated it into a playbook, a heuristic evaluation and a behavioural skill that can govern how the AI itself responds.
Five principles define the experience and trust model across Platform, AI and MCP.
Seven HCI heuristics turn those principles into observable product criteria.
Concrete runtime rules shape grounding, confirmations, language and next steps.
Start with trust, not magic
The manifesto begins from the user’s need to understand, act and remain in control. AI is treated as an experience layer over the same platform and data — not as a self-contained feature with its own reality.
Serenity
Prevent avoidable errors, communicate outcomes clearly and provide recovery paths. Confidence comes before trust.
Persistent consistency
An action taken through AI must remain consistent with the platform and MCP layers. No hidden or conversational-only state.
Grounded answers
Responses connect back to authoritative Lansweeper data. Facts are verifiable; uncertainty is visible.
Context → Action
AI explains what matters, why it matters and what a user can do next — rather than returning isolated data.
Useful AI presence
AI appears where its value is greater than the effort required to engage it. It is never added as decoration.
These principles create one mental model and interaction grammar across different technical implementations. A search suggestion and an autonomous action may have different interfaces, but they should share the same standards for grounding, predictability and control.
Make principles testable
A manifesto only changes a product when teams can use it to make decisions. I mapped the five AI principles to established human-computer interaction criteria and created a four-point heuristic evaluation: not applicable, fails, partial and meets.
The evaluation covers consistency, discoverability, learnability, mental-model alignment, mapping, feedback and error recovery, and visual hierarchy. Each criterion includes an instruction describing the experience expected from the product, so the score produces a design backlog rather than an abstract judgment.
| Heuristic | 2025 review | What the review exposed |
|---|---|---|
| Consistency | Partial | Terminology matched the platform, but the chatbot remained self-contained and could not carry users into product actions. |
| Discoverability | Fails | The entry point was difficult to find and its icon did not clearly communicate an AI capability. |
| Learnability | Partial | Conversation was familiar, but controls for closing, minimising and starting a new chat were ambiguous. |
| Mental-model alignment | Fails | Answers did not link back to the assets, views or platform objects that grounded them. |
| Mapping | Partial | Basic question-and-answer behaviour was clear, but controls and data visualisations did not always explain their outcomes. |
| Feedback & recovery | Partial | Error states said what could not be done without explaining why or offering a useful recovery path. |
| Visual hierarchy | Fails | Flat text and under-labelled charts made priorities, evidence and possible next steps difficult to scan. |
Evaluation as a bridge
The review connected high-level principles to specific interface decisions: make AI visible at the moment of need, deep-link answers to real objects, label charts, distinguish actions from information, clarify errors and reveal detail progressively.
That bridge matters because “make AI trustworthy” is not directly actionable. “Explain what happened, why it happened and how to recover” is.
From guidance to runtime behaviour
The next question was whether these principles could govern the AI response itself. I translated the manifesto and playbook into a Lansweeper AI Experience behavioural skill for the Lansweeper plugin.
The skill does not add another AI capability. It governs how existing capabilities behave: tone, information architecture, confirmation patterns, source grounding, cross-layer acknowledgement and the relationship between a finding and its next action.
Match control to consequence
A five-tier confirmation ladder distinguishes reading data from informative findings, low-impact writes, high-impact writes and irreversible actions. The greater the consequence, the clearer the preview, confirmation and recovery expectation becomes.
Ground every answer
Facts must be traceable to Lansweeper data, an external API or documentation. Missing information is stated explicitly, facts are separated from recommendations and replies deep-link to product objects whenever possible.
Turn information into decisions
Substantive responses follow a What → Why → Do structure: the finding, why it matters and the next useful action. Progressive disclosure keeps the first answer concise while making evidence and detail available when users need it.
Behaviour belongs in the experience layer
Embedding the rules in the MCP server would mix interaction behaviour with the data and action layer. It would reach every client, but make experience rules harder to evolve independently.
A cross-cutting plugin skill
The skill sits alongside task-specific capabilities and is loaded whenever they produce user-facing output. The trade-off is explicit: it governs the plugin experience, not every possible MCP consumer.
What this makes possible
| Without a shared AI experience system | With one |
|---|---|
| Each AI touchpoint can develop its own interaction language. | Manifesto and playbook provide one trust model across entry points. |
| Principles remain open to interpretation. | Heuristics make quality observable and create a concrete improvement backlog. |
| AI responses depend on individual prompt design. | Runtime rules make grounding, hierarchy and confirmation behaviour repeatable. |
| Data may be correct but difficult to act on. | What → Why → Do connects evidence to context and a relevant next step. |
The outcome is a traceable chain from intent to behaviour. The manifesto defines the experience; the playbook tells teams how to assess it; the heuristic evaluation exposes gaps in a real product; and the behavioural skill demonstrates how the same principles can operate at runtime.
This is ongoing work rather than a finished AI design system. Its value is that new surfaces no longer need to begin with an empty page: teams have a shared language for judging whether an AI interaction is coherent, grounded, useful and worthy of trust.
What I’m learning
Trust is not a layer of reassuring copy added after an AI capability works. It is the product behaviour: what the system reveals, what it confirms, where its facts come from, how it recovers and whether an action remains consistent everywhere else.
The strongest principles are the ones that survive translation — from strategy, to a product review, to the rules that shape an actual interaction.