Fewer, better tools
An assistant that can do four things well is more useful than one that can do nine hundred things unpredictably, and far easier to be responsible for.
Every way of connecting an agent to your company's systems is a race to expose more actions to it. We think the number was never the problem.
Connect an assistant to the five systems your company runs on and it receives something like a thousand separate actions. Each one is documented. None of them says which four, in which order, mean take on a client the way this company takes on clients.
So the assistant guesses. Usually well. Occasionally it bills them twice, or sends the welcome email before the account exists, or picks the endpoint that deletes a record instead of the one that archives it. And because it guessed differently last Tuesday, nobody can say what it will do next Tuesday.
Every company already has processes. They live in somebody's head, in a wiki page nobody reads, in the way the person who has been here longest does it. They are made of steps across several systems, in an order that matters, with a point where a human has to look.
That is the thing worth giving an assistant — not a bigger catalogue of actions, but the one right move, named for the job, with the order already decided and the dangerous neighbours simply absent. Teach it once and the variance goes away, because there is nothing left to vary.
It also makes the thing portable. An endpoint is only useful to somebody who already has your systems and your conventions. A packaged process is a shape — and a shape can be handed to another team, or another company, and run there on their accounts without anybody sharing a key.
An assistant that can do four things well is more useful than one that can do nine hundred things unpredictably, and far easier to be responsible for.
If the unit is a process, then approvals, limits and the audit trail attach to something a person can actually reason about — not to an HTTP call nobody chose.
If you make software, your customers are already pointing agents at it. Describing your product as a set of processes beats hoping each of them wires up your API correctly on their own.
A process that needs a file, a date or a signature cannot live in prose. It needs an interface — and it should open where the conversation already is.
Inline gives it the one right thing to do — and lets you hand that to anyone.