Drafts, and waits
The useful shape for an assistant inside a working business is not an agent that acts on your behalf. It is something that prepares the work and then stops.
Almost every demo you will be shown ends with the system doing something. It books the meeting, sends the email, places the order. The pitch is autonomy, and the implicit promise is that the human has been removed from the loop.
Inside a real operation that promise is the problem. The cost of a wrong action and the benefit of a right one are not the same size. A system that drafts forty purchase orders and waits has saved somebody an afternoon. A system that sends forty purchase orders has started a conversation with your auditor, your suppliers, and whoever signs off on working capital. The upside is a few minutes. The downside has no natural ceiling.
So we build assistants that stop. They gather what is needed, do the tedious part, lay the result in front of the person who is accountable for it, and go no further. Approval is not a safety rail bolted on because the technology is immature. It is the feature.
Our own delivery runs this way, through Echelon. Six roles, each defined by what it does, what it may touch, and the line it does not cross. The research role reads and never builds. The drafting role writes documents and never sends them. The build role writes and tests code and never deploys. The verification role checks the others and never fixes what it finds, so nothing is called finished by whoever made it. Every action is logged, and nothing leaves without me.
That last constraint sounds like a bottleneck and is actually the reason the thing gets used. The person who was doing the job keeps their judgement and loses the typing. Nobody is being asked to trust a system with a decision they will be held responsible for. The first time it proposes something wrong — and it will — they catch it, the trust survives, and the system gets fixed.
Compare that with the alternative. An assistant with authority to act gets one visible error, and the business response is not a fix, it is a ban. I have watched a six-month programme end in an afternoon that way.
There is a compliance argument here too, and for South African businesses it is not optional. If a system can act, somebody has to be able to answer what it did, on whose authority, and with whose data. A drafting system answers that question by design: there is a human approval on every outbound action and a log behind it. An autonomous one answers it with an investigation.
None of this means the work has to be slow. The tedious ninety percent still happens without anybody present. What changes is that the last step belongs to a person, and the system is built to make that step quick rather than to remove it.
