Your AI Agent Has a Job. Have You Designed It?

Most companies would never hire an employee without deciding what the person is responsible for. They would define the role. Give the employee access to certain systems. Establish who they report to. Decide which actions require approval. Set expectations for performance. Create a process for exceptions. Change the role as responsibilities evolve.

Yet organizations are beginning to deploy AI agents without doing many of those things. The agent gets a goal, access to several systems, a collection of tools and perhaps some instructions about what it should not do. Then it goes to work. That may be enough for a demonstration. It is not an operating model.

As AI moves from generating content and answering questions to actually performing work, organizations need to design something more substantial around it. I call this the Human-Agent Operating Model. It is the organizational system for defining how humans and AI agents divide work, authority, permissions, supervision, handoffs, exceptions, accountability, and learning. I think it is going to become one of the most important pieces of enterprise AI architecture.

An agent is not just another AI tool

The distinction matters because an agent can participate in a workflow very differently from a traditional AI assistant.

Ask an AI system to summarize a contract and a person still decides what happens with the summary.

Give an agent responsibility for monitoring incoming contracts, extracting terms, comparing them against policy, updating a system, requesting missing information, routing exceptions, and notifying the appropriate employee, and you have created something different.

The AI is now performing a sequence of work. It may interact with multiple systems. It may make intermediate decisions. It may initiate actions. It may encounter exceptions while nobody is watching. The governance question therefore changes.

What is the AI allowed to do? is no longer enough.

We also need to ask: What job have we actually given it?

Start with the work, not the agent

 zOrganizations are understandably fascinated by what agents can do. That can lead to backwards implementation. A team gets access to agent technology and starts looking for places to deploy it. The better starting point is the work itself.

Map the workflow.

• What outcome are we trying to produce?
• What work is required to produce it?
• Which steps are routine?
• Which require judgment?
• Where does context matter?
• Where do exceptions occur?
• What happens when information is missing?
• What actions have meaningful consequences?
• Where are handoffs already failing?

Only then should we decide what belongs to a human, what belongs to an agent, and what should remain a collaboration between them.

This is important because the goal should be to design the best operating system for the work, not just to maximize the amount of work performed by agents.

Sometimes that will mean substantial automation. Sometimes it will mean augmentation. Often it will mean a mixture that changes from one part of the workflow to another.

Give the agent a role before you give it tools

One of the core concepts in the Human-Agent Operating Model is the Agent Role Unit. An Agent Role Unit is the smallest stable package of work that can be assigned to an agent with a defined purpose, scope, authority, permissions, supervision, escalation path, and accountable human owner. Think of it as something closer to a job design than a prompt.

For every meaningful agent role, an organization should be able to explain:

1. Purpose: What outcome is this agent responsible for helping produce?
2. Scope: What work belongs inside the role, and what explicitly does not?
3. Inputs: What information may it use?
4. Tools: Which systems and capabilities may it access?
5. Actions: What may it actually do?
6. Authority: Which actions can it take independently?
7. Approval: Which actions require a human before proceeding?
8. Exceptions: What conditions should cause the agent to stop or escalate?
9. Owner: Which human role remains accountable for the agent’s operation?

If those answers are unclear, the organization probably does not yet have an agent operating model, but an agent with access. Those are not the same thing.

Permissions should follow the job

This sounds obvious until you look at how software access tends to accumulate.

People receive permissions because they need them for a task. Roles change. Access remains. Integrations inherit credentials. Service accounts gain broad privileges because narrowly configuring them takes longer.

Agents can magnify that problem. An agent should not receive access based on everything it might be capable of doing, but rather the minimum access required to perform its assigned role.

That includes more than which applications it can reach. Permissions can include:

• what information it can retrieve,
• which records it can modify,
• what actions it can initiate,
• how much money it can commit,
• which external parties it can contact,
• whether it can publish,
• whether it can create or delegate work to another agent, and
• whether it can execute an irreversible action.

This creates an important operating principle: Agent capability and agent permission should be treated as separate things.

While a model may technically be capable of performing an action, that does not mean the organization has authorized it to do so.

Autonomy should have a boundary

The word autonomous is often used as though it were a single state. It isn’t particularly useful that way.

An agent might independently perform one portion of a workflow while requiring approval for another. It may operate freely below a financial threshold but escalate above it. It may communicate internally but require approval before contacting a customer. It may prepare a system change but not deploy it.

That boundary is what matters.

I think organizations need to explicitly define an Autonomy Envelope for consequential agent roles. The Autonomy Envelope describes the conditions under which the agent may operate without additional human authorization. Those conditions might include transaction size, data sensitivity, customer impact, confidence, reversibility, system affected, geographic region, exception type, or some combination of them.

Inside the envelope, the agent works.

At the boundary, something different happens.

• Perhaps a human reviews the action.
• Perhaps another control is invoked.
• Perhaps the agent is allowed to continue with additional evidence.
• Perhaps the work stops entirely.

The point is that autonomy becomes a deliberate operating condition rather than an accidental consequence of what the technology happens to be capable of doing.

Handoffs deserve as much attention as automation

Some of the hardest failures in agentic workflows will probably occur at the boundary between humans and agents. The agent encounters something unusual and sends it to an employee.

What happens next?

• Does the employee know why it was escalated?
• Can they see what the agent already did?
• Do they have the relevant source information?
• Can they understand the agent’s reasoning?
• Do they know what decision they are expected to make?
• Can they return the work to the agent afterward?
• Or does the employee receive an alert that essentially says, “Something went wrong. Good luck.”

A good handoff transfers enough context, state, evidence, history, and responsibility for the receiving party to continue the work intelligently. The same is true in the opposite direction.

If a human hands work back to an agent, the agent needs enough structured information to understand what changed and what it is now authorized to do.

This becomes even more important in multi-agent environments. If Agent A hands work to Agent B, and Agent B triggers Agent C, organizations need to understand where authority and context travel with the work. Otherwise, the workflow can become extremely sophisticated while accountability becomes increasingly difficult to locate.

Exceptions are part of the job

Automation projects have always had a temptation to design around the happy path. Agents make that especially dangerous because they can continue operating after encountering something unexpected.

• An unusual customer request appears.
• Required information is missing.
• Two systems disagree.
• The policy does not cover the situation.
• The agent receives an instruction that conflicts with its operating rules.
• A downstream system is unavailable.
• The customer asks the agent to do something outside its authority.

Those aren’t annoying edge cases to address after launch, but part of the operating model.

For each Agent Role Unit, organizations should identify common exception classes and define what the agent should do.

• Continue?
• Ask for information?
• Retry?
• Use another approved source?
• Transfer the work?
• Escalate?
• Stop?

The goal is to give the system safe ways to behave when the expected path breaks.

Human supervision needs capacity

There is another problem hiding inside the promise of agentic efficiency.

Agents can create work for humans. An agent performing hundreds of tasks may generate dozens of exceptions. A system operating around the clock can produce review requests faster than employees can resolve them. A team that previously completed 50 transactions manually might suddenly supervise 500 automated ones. The human work changes rather than disappearing. Employees may perform less production but more review, exception handling, investigation, escalation, quality control, and judgment. That can be an excellent trade, but only if the operating model accounts for it. If five agents each save 20 hours of production work but create 30 hours of additional human review and exception work, the organization needs to see the entire equation.

This is why supervision capacity belongs in agent design.

• Who is supervising the work?
• How many agent actions can that person realistically oversee?
• How quickly must exceptions be resolved?
• What happens when the reviewer is unavailable?
• What skills does the reviewer need?
• What volume would overwhelm the review process?

An organization can automate itself into a human bottleneck surprisingly quickly.

The human role should become more important, not less defined

There is a persistent assumption that increasing agent autonomy means decreasing human involvement, which it will sometimes. Though, the remaining human responsibilities often become more consequential.

Humans may move from performing every transaction to:

• setting objectives,
• defining boundaries,
• reviewing exceptions,
• interpreting ambiguity,
• handling sensitive situations,
• challenging recommendations,
• authorizing consequential actions,
• monitoring patterns,
• changing operating rules, and
• taking responsibility when the system fails.

Those are the control structure surrounding the automated work. That means organizations need to design the human role at the same time they design the agent role. Otherwise, they risk automating the visible work while leaving the invisible work unowned.

Agent performance needs more than an accuracy metric

If an agent is performing a job, its performance should be evaluated in the context of that job because accuracy matters. So do other questions.

• How often does the agent escalate?
• How often do humans override it?
• Which exceptions recur?
• How much human review does it require?
• How often does it operate outside the expected path?
• How much rework does it create?
• How long do handoffs take?
• Does it produce the intended business outcome?
• Has it reduced workload, or merely moved workload somewhere less visible?
• Has the workflow become more resilient or more dependent on a particular model, vendor, or integration?

These measurements tell us something much more useful than whether the agent completed a benchmark successfully. They tell us whether the human-agent system works.

Agent roles should be reauthorized

An agent’s job should not be designed once and forgotten.

• The model changes.
• The workflow changes.
• The organization learns.
• New exception patterns appear.
• Performance improves.
• Performance deteriorates.
• A new integration gives the agent access to capabilities it did not have before.
• The business impact of its actions grows.

At some point, the original authorization may no longer match the operating reality. That means organizations need a reauthorization process.

A meaningful change should trigger a review of the Agent Role Unit:

1. Is the purpose still correct?
2. Is the scope still appropriate?
3. Are the permissions still necessary?
4. Should autonomy expand or contract?
5. Have new exception classes appeared?
6. Is human supervision still adequate?
7. Are handoffs working?
8. Does the accountable owner still make sense?
9. Is the role still creating enough value to justify its operating burden?

This is how an agent moves from an experiment into managed organizational infrastructure.

Start with one agent role

Organizations do not need a massive agent-governance program before they can improve their operating model.

Pick one agent that performs real work, then document:

1. Purpose: What outcome is it responsible for?
2. Scope: What work belongs to it?
3. Boundaries: What is explicitly outside the role?
4. Inputs: What information can it use?
5. Permissions: What systems and data can it access?
6. Actions: What can it do?
7. Autonomy: What can it do without approval?
8. Handoffs: When does work move between agent and human?
9. Exceptions: What should cause it to stop, retry, ask, or escalate?
10. Supervision: Who monitors its work, and do they have enough capacity?
11. Accountability: Which human role owns the outcome?
12. Performance: How will you know the entire human-agent system is working?
13. Reauthorization: What changes require the role to be reviewed again?

That exercise will often reveal that the hardest part of deploying agents is deciding what kind of worker you are putting into the organization versus the assumptions that it’s building the agent.

We are designing a new division of labor

For most of the history of business automation, software executed rules that humans designed. Generative AI complicated that relationship because software could interpret, generate, analyze, and recommend. Agents push it further. Now software can increasingly perform sequences of work, use tools, interact with systems, respond to changing conditions, and take actions toward an objective.

That creates a new division of labor between humans and machines. Organizations can allow that division of labor to emerge accidentally as employees experiment with increasingly capable tools or they can design it.

• They can decide what belongs to humans.
• What belongs to agents.
• Where they collaborate.
• What authority travels with the work.
• Where autonomy stops.
• How context survives a handoff.
• What happens when reality does not match the expected workflow.
• Who supervises the system.
• And who remains accountable for the result.

The question is now: What job are we willing to give it, under what conditions, and what human operating system needs to exist around it?

That is the work of the Human-Agent Operating Model.