Agentic Operating Models: What Breaks When Tools Become Agents

Every enterprise operating model built in the last three decades assumes the same division of labor: humans decide, software executes, and the audit trail records who authorized what. Agentic systems, meaning software that plans, calls tools, negotiates with other systems, and closes loops without a human in the middle, quietly violate that assumption. The interesting question is not whether agents work. It is what breaks when they do.

The first thing to break is the RACI. In a workflow where an agent opens a ticket, drafts the response, executes a refund, and updates the ledger, the responsible party is not clearly the engineer who deployed the agent, the manager who set its budget, the vendor whose model it uses, or the customer-service leader whose SLA it now owns. Most companies address this by pretending nothing has changed and quietly signing the manager's name on outputs the manager did not see. That posture will not survive a serious incident.

The second thing to break is the audit trail. Traditional controls assume that each material action has an identifiable human authorizer and a durable log entry. Agents call other agents, retry, back off, and reason in ways that produce logs that are long and semantically thin. If an auditor asks why a specific customer was denied, or a specific vendor was paid, the honest answer is often a sequence of model traces that no one has read. The fix is not to log more. It is to design decision points where an agent must, by policy, produce a human-readable justification and pause for review above a defined threshold.

The third thing to break is the operating model's headcount logic. Agentic systems do not neatly replace one FTE. They compress the work of a team into a smaller supervisory function while creating new categories of work that did not exist before, principally around monitoring, evaluation, and prompt or policy maintenance. Leaders who try to book the headcount reduction without funding the supervisory layer discover, within about two quarters, that quality has drifted and no one owns the recovery.

What we recommend to COOs and CIOs looking at agentic deployments is a simple sequence. Define the failure the agent is allowed to cause. Define the human who owns each class of failure. Define the review cadence and the kill switch. Only then define the productivity target. Programs designed in that order tend to work. Programs designed in reverse tend to become case studies for the audit committee.

The honest question for your next executive session: if the agent you are about to deploy makes a wrong decision that costs a customer money, whose name is on the incident report? If nobody can answer that within thirty seconds, the design is not ready.