The question usually arrives as a logistics question. Where do the agents go first. Which processes are the best candidates. How do we sequence the rollout across the regions.

That is almost never the real question being asked.

The question underneath it, the one that is often unspoken is: what does my organization actually look like when people and agents deliver work together, and how do I get there?

It’s a very different question, and almost nothing in the current playbook answers it.

The tactical answer — pick a high-volume process, put an agent on it, measure the lift — is not wrong. It works. I have watched it work. It is also the entire reason so many programs stall at the same place when the easy processes are done and the next candidates all cross a boundary.

Because the tactical approach treats the agent as a better instrument handed to an unchanged organization. And the moment the work crosses a function, the organization is the thing in the way.

Every OCM framework in circulation is built for a specific and reasonable assumption: the work stays roughly the same, the person gets a new way of doing it. Communicate the why. Train the user. Support the transition. Measure adoption.

That assumption has held for every enterprise technology I have implemented, including most of my seven years selling ServiceNow. It is a good model. It is built for life as it is.

What I'd argue is that human-agent co-delivery needs the same discipline pointed at something larger. Not a replacement for OCM — an expansion of it. The existing concepts still apply. Sponsorship, readiness, resistance, reinforcement. They just have to operate on a bigger object than the user.

Here is the bigger object.

A role is not a list of tasks. A role is a bundle of three things: the work, the accountability for that work, and the standing to decide inside it.

Agents absorb work. Today they cannot hold accountability, and they do not have standing. So every role you touch gets hollowed out in exactly one of those three dimensions and left untouched in the other two.

Nobody has redrawn the bundle. That is the whole problem, and it explains a lot of what looks like resistance.

When a person tells you the agent "isn't reliable enough," listen for whether they mean the output is wrong or I'm still the one who gets asked about it. Those are different complaints. The first is a model problem. The second is a job architecture problem, and no amount of model improvement solves it.

We talk about this as a one-directional problem. Teach the humans to work with agents. Train the users. Build the prompt library.

I think it runs both ways, and the second direction is the one that gets skipped.

An agent joining your company has to learn the same things a new hire does. Not the task — the task is the easy part. It has to learn what "done" looks like here specifically, which is never what the documentation says. Which exceptions are routine and which ones mean stop. Who actually needs to be told, as opposed to who is on the distribution list. What your organization's tolerance for being wrong is in this particular process, which is different from the tolerance three processes over.

That is onboarding. We do it for people over about ninety days, mostly informally, mostly through proximity to someone who already knows. For agents we do it by writing a prompt and moving on.

The tooling to do this is available but it’s new. The adoption, deployment, and maturity of these tools will take time. Memory, context, feedback that actually changes future behavior, some durable record of what this agent has learned about how we operate.

Which is an argument for doing the organizational work now rather than later. The technology will arrive. The question is whether it arrives at a company that has defined what it means to work here, or one that hasn't.

I hear some flavor of each of these questions frequently:

Who is accountable when an agent is wrong? Not who fixes it. Who answers for it. If the answer is "the person who deployed it," you have quietly made your most capable people afraid to deploy anything.

What does a manager manage? If a meaningful share of throughput isn't people, the job shifts from allocating work to specifying outcomes and verifying them. That is a genuinely different skill, and almost nobody has been trained in it or promoted for it.

How do you plan capacity when one contributor scales elastically and the rest don't? Every planning model you own assumes capacity comes in units of headcount. That assumption is now wrong in a small number of places and will be wrong in more of them quickly.

Where do your seniors come from in ten years? The work agents absorb first is disproportionately the work that was previously used for new employees, to train people. That is a real cost and it is not on anyone's business case. I'll come back to it in its own piece.

In my own business, as a practitioner, a product person, and now a consultant, here’s what I do and it work.

Pick a workflow that crosses at least three functions and that you can name a business number (really hard dollars) for. Before deploying anything into it, redraw the roles inside it — who does what work, who is accountable for what outcome, who can decide without asking. On paper. It takes an afternoon and it is uncomfortable if done properly, which is how you know it's the right afternoon.

Then design the escalation path before you design the automation. What does the agent do when it isn't sure. Who receives that, and what is their service level for responding. Most programs build this last, after the first bad outcome, which is the most expensive possible time to build it.

Then write down what this organization means by "done" in that workflow, in enough detail that a competent stranger could apply it. You will discover that nobody agrees. That disagreement was always there. The agent just made it legible.

And name the owner. One person accountable for the redesign, not for the tool. It isn't HR, it isn't IT, and it definitely isn't the vendor. This is the same “seam” owner problem the board is sitting on, one layer down and considerably more concrete.

The organizations that get real leverage from agents in the next three years will not be the ones with the best models or the most deployments. They will be the ones that redefined a role before they deployed anything into it. Everyone else will run a long series of successful pilots that never assemble into an operating model.

What remains to be seen? How quickly agents get good at learning a specific company rather than a general task. If you have seen an agent genuinely absorb an organization's norms over months, not a prompt that encoded them upfront, I want to hear about it. That is the piece that decides whether this is a five-year transition or a fifteen-year one.

— Isaac