Rishi Katdare, Senior Leader in Networking and Edge for Global Financial Services at Amazon Web Services.gettyI have seen teams celebrate automation that cleared a queue, only to discover the work had not disappeared. It had moved into exceptions, reviews and control questions that were harder for leadership to see. Nobody decided to create a backlog. The system just kept working.AI agents raise that risk because they can act inside the workflow. When leaders discuss agents, capability dominates. Can the agent resolve the ticket, contact the customer or update the record? Before action, the enterprise has to define the work.An agent is not hired to be generally useful. It is authorized to perform work. A model can answer, a chatbot can draft and a dashboard can inform. An agent can update a system of record, route an exception, send a message, modify access or trigger a workflow. And once a system can act, the enterprise has delegated authority.No executive would tell a new employee to read across the business, act where useful and escalate when unsure. Before that person touches customer records, financial workflows or access rights, the work is defined and the manager is named. Yet many organizations are preparing to give AI agents access before defining clear scope, workflow authority before assigning managerial ownership and permission to act before anyone can clearly explain the job.​An AI agent without a job description is not autonomy. It is unmanaged authority.Authority begins with the workflow.A job description for an AI agent is not an HR metaphor. It is a workflow authorization model. ​When I run agents, I do not start by giving them a mandate to help. I approve a workflow. I define the steps it may execute, the sources it may use, the cadence on which it runs, the conditions requiring human review and the point at which its work stops. That discipline precedes production authority.That workflow often begins as a narrowly scoped pilot. An agent clears a queue, prepares exception summaries, drafts customer updates or moves work between systems faster than a team could do manually. As confidence grows, the authority granted for the pilot often expands into part of the operating model. What began as assistance becomes a production workflow, making the original governance decisions increasingly consequential.​​Execution cadence can make the risk compound. An agent running every hour can turn one weak assumption into dozens of customer, financial or access events before anyone sees the pattern. A workflow that repeatedly advances the same exception, contacts customers on incomplete context or modifies records from stale data can create cleanup work that hides under the language of productivity.If an agent removes 10 minutes from a task but creates exceptions, audit cleanup or review queues elsewhere, the business has not gained efficiency. It has moved work into a layer where leadership has less visibility. Productivity that returns as hidden supervision is managerial debt.The buyer cannot outsource consequence.​While agent-as-a-service offerings can simplify deployment, I've found they often increase the cost of weak governance. The easier it becomes to deploy an agent, the more important it is to define ownership, authority and accountability before it begins acting.The same ambiguity shows up in managed service handoffs, when nobody can say which party owns an incident once it crosses the boundary. An agent provided by a third party accelerates the same problem. The vendor may provide the agent, but the enterprise still owns the consequence when that agent touches data, workflows, customer communication or systems in its name.A familiar failure pattern is access that traces back through more than one system, with no owner able to say why the permission still exists. Agents can compound that ambiguity because they can act, invoke and coordinate rather than respond. A company may approve one agent, then discover downstream tasks or connected workflows inherited access, cadence or decision rights no one reviewed closely enough.A CEO put it bluntly in conversation: “AI does not get fired or go to jail.” That is the accountability problem many autonomy conversations avoid. The agent may execute the action, but management owns the consequence. A leader still has to defend the decision, the control model and the failure path.Revocation is part of the job.I have watched automation keep running after the business context changed because stopping it required a ticket, a release window or an owner no one could name. With agents, that weakness is intolerable. Enterprises talk easily about granting more autonomy, but revocation is part of the management model.If an agent can touch money, identity, customer commitments, regulated information, privileged access or systems of record, leaders need more than launch approval. They need a narrowing path, a suspension path and a way to withdraw authority when context changes. Authority that cannot be withdrawn is more exposure than it is autonomy. ​Autonomy should vary by consequence. An agent drafting internal summaries may need light review. An agent writing to a system of record, communicating externally, changing access, touching money or influencing regulated processes needs narrow authority, clear escalation, evidence of action and an owner who can defend the mandate.A business case built only on speed or task automation is incomplete. It must include ownership, approved steps, execution frequency, exception load, review capacity, escalation design, evidence trails and revocation. Leaders need to know whether the organization has reduced work or pushed accountability into a less visible part of the operating model.AI will not reduce accountability. It will expose weak accountability faster. Agents force companies to define work with a precision many organizations have avoided. Leaders must decide which decisions require human judgment, which processes are safe to automate and which outcomes management is prepared to own.Before AI agents get more autonomy, they need jobs: defined workflows, governed discretion and accountable supervision. If you cannot name the workflow, the owner, the cadence and the revocation path, you have not deployed autonomy. You have automated ambiguity.​​Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?