The scenario has become commonplace. You ask an artificial intelligence to put together a table of the twenty companies in your industry in your département. You get a flawlessly written reply explaining how to go about it: check this directory, cross-reference that source, structure this column. The advice is sound. The work, though, is still all there.
People often blame this gap on poor phrasing. It almost never is. A conversational AI produces text. That's its job, and it does it very well. Acting is a different job, and it requires three things the AI doesn't have.
First condition: access to more than words
To build your list of companies, you have to fetch pages, read them, reconcile contradictory information, then write a file in the right format. Each of these steps is an action on the outside world, not a sentence to compose.
A system that has only language at its disposal can't do anything but describe the path. It isn't lying to you: it's doing what it knows how to do. The difference begins the day it genuinely has a search function, a document reader, a spreadsheet generator, access to your calendar.
An AI that has only words can only hand you back words.
Second condition: being allowed to act
Having a tool isn't enough yet. Sending a message to a client, booking an appointment, editing a record: these actions commit your business. They require explicit permission that can be revoked and that differs depending on what is being authorized.
This is where many automation projects fall apart. Either you grant every right at once, and nobody sleeps easy anymore. Or you grant none, and the system stays a chatty advisor. The right granularity resembles the one you'd apply to a new colleague: they can read the calendar from day one, but they don't sign a contract in their first month.
- Reading external data: no consequences, a one-time permission is enough.
- Writing something reversible, such as a note, a draft or an event: a team-level policy is enough.
- Communicating externally: explicit approval, every time, for that specific message.
- Deleting, cancelling, paying: a strong confirmation, plus safeguards on top of the approval.
Third condition: proving what was done
This is the most neglected point, and the most important. A generative system can write “it's been sent” with the same confidence it would have writing “it hasn't been sent.” The sentence is produced, not observed.
An agent worthy of the name builds its answer from the machine result of each action: the identifier returned by the messaging service, the event read back from the calendar, the file checked after writing. If a step fails, it says so and keeps the rest of the work, instead of turning a partial success into a total failure.
The question to ask of any tool that claims to act: what is the sentence “it's done” based on?
How to tell the difference in practice
A simple test is enough. Ask for a deliverable, not an explanation: a spreadsheet, a document, a prepared mailing. Then look at what comes back.
- You get a method: you have a writing assistant, which is useful, but the work stays with you.
- You get the file, with its sources and a note of what's missing: you have an agent.
- You get a claim of action without proof: be wary, it's the worst of the three.
The third case deserves a closer look, because it's more dangerous than plain advice. A tool that claims to have acted without having done so costs you twice: the work isn't done, and you believe it is.
What this changes in how you choose
Demos all look alike, because they cover the easy part: understanding the request. The hard part comes afterward. When you evaluate a solution, ask three questions and see whether the answers are precise: which tools does it really have access to, how are permissions granted and withdrawn, and what is the claim that an action actually took place based on.
A solution that answers these three questions clearly will save you time. A solution that stays vague on the third will cost you time, without you noticing right away.
