For twenty years, enterprise software has been a very patient employee. It sat perfectly still until someone clicked a button, filled a form, or scheduled a job. Every system I have ever automated shared this one deep assumption: nothing happens until a human decides it should. The whole apparatus of process design — approvals, handoffs, queues, SLAs — is built on software that waits.
That assumption is now quietly dissolving. An agent, in the practical sense I care about, is software that holds a goal rather than a script. It decides what to do next, tries something, reads the result, and tries again. Which means that for the first time, the systems inside our companies have initiative. They come to the door and ask: what needs doing?
The difference initiative makes
When I built classic RPA, the robot was an extension of a process map. If the map said “open invoice, check amount, post to ERP,” the robot did exactly that, ten thousand times, with zero curiosity. The failure modes were boring and legible: a selector broke, a field moved, a queue filled up. You could point at the step that failed.
An agent’s failure modes are different in kind, not just in degree. It can succeed at the task and still surprise you in the method. It can invent a workaround you never sanctioned — email a supplier for a missing document, say — and whether that is delightful or terrifying depends entirely on context the agent may not have. Initiative without institutional context is how well-meaning new hires cause incidents. We already have a word for the fix: onboarding.
There is also an accounting problem hiding in here. A scripted robot’s errors cost roughly the same every time, so you can price the risk of deploying one with a spreadsheet. An agent’s errors follow a power law: mostly harmless improvisations, occasionally a workaround that crosses a line nobody thought to draw. Averages mislead you about power laws. The right question is not “how often is it wrong?” but “what is the worst thing it can do while technically succeeding?” — and the honest answer decides how much authority it should hold.
I have started treating agent deployment as an onboarding problem rather than an integration problem. What is this worker allowed to decide alone? What must it escalate? Who reviews its work while trust is being established, and what does “established” mean, measurably? These are HR questions, and it turns out HR questions are excellent engineering requirements.
The org chart meets the agent
Here is the uncomfortable part. Organisations are shaped like their coordination costs. We bundle work into jobs, jobs into teams, teams into departments, because human attention is expensive and handoffs are lossy. Agents change both constants at once: attention becomes cheap, and handoffs between agents are nearly free. The shape that was optimal for humans-only is not optimal for a mixed workforce.
I do not think the answer is the fully autonomous company, and I am suspicious of anyone selling one. The answer I keep arriving at is smaller and stranger: processes stop being pipelines and become conversations. Instead of a document crawling through six inboxes, a case gets assembled by a small crowd of agents in seconds, and the humans in the loop shift from doing the steps to setting the terms — deciding what good looks like, catching the cases that smell wrong, owning the outcome.
The humans move from doing the steps to setting the terms.
That shift sounds like a demotion and is actually a promotion, but only if we redesign roles deliberately. A case handler whose job silently became “approve whatever the agent did” has been set up to fail an audit. A case handler whose job explicitly became “define policy, sample outcomes, handle escalations” has a better job than before. Same technology, opposite outcomes, and the difference is nothing but design.
Middle management feels this first, because so much of middle management is coordination made flesh: collecting statuses, translating between teams, moving information to where decisions happen. Agents are frighteningly good at exactly that layer. The managers who thrive will be the ones who discover that coordination was never the valuable part of their job — it was the cover under which they exercised judgment, developed people, and absorbed ambiguity. Those three do not automate. They do, however, need to move from the margins of the calendar to its centre.
What I would do this quarter
If you run a process organisation, three moves are available right now. First, write job descriptions for your agents before you deploy them — scope, authority, escalation paths, and the review cadence you would give a trainee. The act of writing it exposes every fuzzy boundary in the process, and fuzzy boundaries are where agents get creative in ways you will not enjoy.
Second, instrument for narrative, not just metrics. When a human makes a strange decision, you can ask them why. Demand the same from the agent: every consequential action should carry a readable account of what it believed and why it acted. Logs tell you what happened; accounts tell you what it thought. Auditors, regulators, and your own future self will need the second kind.
Third, pick one process where the agent fails safely and let it run. Not a pilot in a sandbox — a real process with real volume and a cheap undo. Nothing builds organisational judgment about agents except contact with agents. The companies that learn this in production, small stakes first, will be the ones whose org charts bend instead of break.
The knock at the door is not going to stop. We can answer it with a plan, or we can answer it surprised. I have spent enough years watching surprised organisations to know which one I am choosing.