A vendor demo runs long. The pitch is one assistant that reads the inbox, drafts the reply, updates the ticket and touches the record behind it, all from one login. Someone in the room decides to test it on a live case: a stalled order, a customer who has already called twice.
The assistant answers the customer well enough. Alongside that, it also reopens a closed order it was never asked to touch, because reopening looked to it like part of being helpful. Nobody in the room notices. Nobody downstream notices either, until someone asks why an order that was closed is not closed any more.
When it gets traced back, the answer is not a person's name. It is "the assistant did it." Nobody had written down what the assistant was allowed to touch, so nobody can say whose mistake this actually was, or fix the one thing that caused it without touching everything else it does.
Why we build it this way
Nearly every AI programme we look at starts with the same wish: one assistant that can do everything, because one login is simpler to buy and easier to explain in a meeting. We think that instinct is exactly backwards. An assistant with no fixed job is not more capable for having a wider brief. It is less accountable, because there is no scope to hold its behaviour against, so nothing it does can be called right or wrong in the first place.
The usual patch is to give it more instructions instead: be careful, ask when unsure, use good judgement. That is a personality, not a scope. A personality only describes how the software behaves when it is doing what you expected. It says nothing about the line it must not cross, because a personality does not draw lines. Somebody still has to.
A personality is not a scope. It tells you how the software behaves when things go as expected, and nothing about the line it must not cross.
So we do not build one assistant that does everything. We build a named set of agents, each doing one job, each with a written scope reviewed the way any other specification is reviewed: what it may read, what it may act on, and where it must stop and hand back to a person. We build our own engineering the same way — our agents propose changes to our own systems, they do not merge them. A person approves every one, because that is the only arrangement in which software can act and someone can still answer for what it did.
How it works, roughly
Every agent in the set carries the same four things, whatever job it does:
- A scope, in writing: what it may read, what it may act on, and where it must stop and ask
- A budget: a limit on how much it can do before someone is asked to look
- An audit trail: every read and every action it takes, kept where it happened, not in a log you cannot see
- A human gate: by default it proposes rather than acts, and autonomy is raised one step at a time, only against evidence that it has earned it
When something goes wrong, it is not a complaint against "the assistant." It is a question about one named agent's scope, because you know exactly which one acted and what it was allowed to do. The fix is to redraw that one scope and have a person sign the new version, not to retrain a general habit and hope it holds everywhere else. The agents also run through adapters, so the model or tool underneath any one of them can be swapped by a person deciding to swap it, without touching the rest of the set.
A year of working this way, you have a set of agents you can name individually, each replaceable on its own, each with a record of everything it has touched. What crosses from a proposal into an action is still a person's decision, and the record of that decision stays inside the walls the customer already owns.
Agent ecosystem design is one of the services inside AI Transformation: naming the agents, writing their scopes, and building the gate a person actually uses.
Read about AI Transformation →