Main idea

A chatbot in the support tool, an assistant in the CRM, automatic generation in the back office, a summary in the ticketing tool: each of these additions saves time, and none of them changes what the tool keeps. The form is filled in faster, but it is still the same form; search becomes conversational, but it still bears on the same databases.

The information therefore stays where it was, in the form it was in, cut up by the application boundaries that already cut it up. What is improved is the speed of entry and reading, not the nature of what is written.

That is a real gain, and it is also an intermediate step: an augmented tool remains a tool, and the assistant living inside it knows only what that tool contains.

Why it matters

It separates two workstreams that companies confuse, and one of which serves as an alibi for the other. Plugging an assistant into the CRM is decided in a quarter and can be shown in a demo; reorganizing what the organization keeps cannot be shown and never ends. The first absorbs the budget and the rhetoric of the second.

It also gives a simple test when a vendor proposes an AI feature: ask what it leaves behind once the answer has been given. If the answer is "nothing", the tool has been sped up, not transformed.

Nuances and limits

The intermediate step is not useless: it is often what brings the use of AI into habits, and what reveals, through failure, how poor the available context is.

And an embedded assistant can become more than an accelerator if it writes outside its application — if it deposits what it has understood somewhere other tools can read.

Open questions

• Does a software vendor have any commercial interest in letting what its assistant has understood leave its tool?