The New Operating Model for Human–Agent Teams

When AI agents stop merely assisting people and begin executing work, organizations need to redesign delegation, authority, review, escalation, and accountability—not just adopt better tools.

Most organizations still think about workplace AI through the language of assistance. AI helps someone write an email, summarize a meeting, analyze a spreadsheet, generate code, or prepare a first draft. The employee remains at the center of the workflow: they initiate the task, watch the work happen, decide whether the output is useful, and remain clearly responsible for the final action.

Agents change that operating model.

A capable agent can receive a goal, gather context from several systems, make intermediate decisions, use tools, perform work in the background, and return only when the task is complete or an exception requires attention. OpenAI's Workspace Agents, for example, can run on schedules or API triggers and perform repeatable workflows across connected tools, while Anthropic's Claude Tag is explicitly designed so teams can delegate work through Slack and allow Claude to continue working while people focus elsewhere.

At that point, the important organizational question is no longer simply, “How should employees use AI?”

It becomes: How should work be divided between people and agents?

That is a different management problem. Delegating work to software that can reason and act requires clarity about context, authority, execution boundaries, review, escalation, and accountability. Without those things, organizations can easily end up with the worst of both worlds: agents autonomous enough to create risk, but humans still involved enough to absorb most of the operational cost.

The next phase of enterprise AI therefore needs an operating model for human–agent teams, not merely an AI adoption strategy.

The shift from assistance to execution changes the organization

Microsoft's current agentic transformation guidance draws an important line between agents that assist and agents that execute. In an assistive workflow, AI supports a human who continues to make decisions and perform consequential actions. In an executing workflow, the agent performs work across systems and the human increasingly supervises outcomes rather than carrying out each step personally. Microsoft argues that this transition creates new requirements around ownership, risk response, lifecycle management, and explicit authority.

That distinction is more important than the label attached to the technology.

An AI system that drafts a customer reply is still operating inside a familiar human workflow. The employee reads the draft, decides whether it is appropriate, edits it if necessary, and sends it. Existing management structures can accommodate that change fairly easily because AI has improved the employee's productivity without fundamentally changing who performs the job.

Now imagine an agent that receives incoming support cases, investigates account history, consults company policy, executes routine fixes, communicates with customers, and escalates only exceptional cases. The human employee is no longer performing every step faster. Their role has changed from doing the workflow to governing the workflow.

Microsoft describes this explicitly in its guidance for core business-process transformation: people shift from executing work toward defining autonomy limits, handling exceptions, monitoring outcomes, continuously improving the process, and remaining accountable for business results.

That is not ordinary productivity enhancement.

It is job redesign.

Delegation starts with context, not prompts

The first requirement of a human–agent operating model is context.

Humans rarely receive serious work through a single perfectly written instruction. A senior engineer knows the architecture, recent incidents, team conventions, customer constraints, technical debt, and stakeholder expectations that surround a task. A support specialist knows which customers require extra attention and which policies have subtle exceptions. A manager understands which tradeoffs are acceptable even when those tradeoffs have never been written down explicitly.

This accumulated context is one reason delegation between people works despite imperfect instructions.

Agents need an equivalent operating environment.

OpenAI's guidance for workflow design now encourages teams to map the current workflow, desired outcome, human judgment, boundaries, escalation conditions, and unresolved questions before building an agent. Its Agent Activator framework similarly emphasizes that workflow ownership includes requirements, human decisions, access, reliability, rollout, measurement, and maintenance rather than merely writing the agent's prompt.

This is an important managerial lesson. If an agent repeatedly requires enormous prompts explaining what to do, the organization may not have a prompting problem. It may have an undocumented-work problem.

Human–agent teams will force companies to make implicit operating knowledge more explicit. What information does this role need? Which policies govern the work? What does a good result look like? Which historical decisions should influence similar cases? What information is authoritative when different sources disagree?

The process of answering those questions can improve the human workflow as much as the agent itself.

The first step of delegation is therefore not writing a clever instruction.

It is constructing enough shared context that the delegate can make sensible decisions.

Context → Authority

Context alone does not justify action.

A junior employee may understand how the payroll system works without being authorized to change executive compensation. A support specialist may know how refunds operate but still require managerial approval above a threshold. A database administrator may technically know how to delete production data while organizational controls prevent them from doing so casually.

Agents need the same separation between knowledge and authority.

I define authority as the explicit boundary around what the agent may decide and what it may actually do.

An agent could be allowed to investigate a case but only recommend an action. Another might be authorized to execute actions below a certain financial threshold. A more mature workflow might allow autonomous handling of routine cases while requiring human approval whenever policy ambiguity, financial exposure, customer risk, or confidence falls outside a defined range.

OpenAI Presence is built around exactly this pattern. Deployments encode policies, permissions, approved actions, and escalation paths, allowing agents to resolve cases autonomously within defined boundaries while involving people when human judgment is required.

The managerial analogy is delegation of decision rights.

Strong managers do not merely assign tasks. They communicate how much authority accompanies the task. “Investigate this problem,” “recommend a solution,” “make the decision within these limits,” and “own this result end-to-end” are very different forms of delegation.

Human–agent teams need that same vocabulary.

Without it, organizations tend to fall into one of two extremes. They either require approval for almost everything, turning agents into elaborate assistants, or give agents broad authority because constant human involvement defeats the purpose of automation.

Neither scales particularly well.

Authority → Execution

Once context and authority are established, the agent can execute.

This is the part of agentic AI that receives the most attention because it is the most visible. Agents can browse, write code, query databases, operate business software, interact with APIs, coordinate sub-agents, and run for increasingly long periods without intervention.

Anthropic's research on real-world agent usage provides a useful signal about how quickly this pattern is evolving. In Claude Code, the longest-running autonomous sessions almost doubled over a three-month period, from under 25 minutes to more than 45 minutes before the agent stopped. More experienced users also tended to approve individual actions less frequently and instead monitor progress and intervene when necessary.

That shift resembles the difference between micromanaging a junior employee and managing through outcomes.

If an agent must ask permission before every file read, shell command, API call, or intermediate decision, humans remain deeply embedded in execution. The theoretical agent may be autonomous, but the operating model is not.

Anthropic has observed this problem directly. Its telemetry showed users approving roughly 93% of Claude Code permission prompts, creating approval fatigue and reducing the usefulness of human confirmation as a meaningful safety mechanism. Anthropic has responded by automating safer approvals while relying more heavily on containment and enforceable boundaries for dangerous capabilities.

This suggests an important principle for human–agent management: humans should not supervise every action; they should supervise the boundaries and outcomes that matter.

The objective is not maximum autonomy. It is the appropriate level of autonomy for the risk and maturity of the workflow.

Execution → Review

Delegating execution does not eliminate review. It changes what review means.

When humans perform a task manually, review often happens at the artifact level: inspect the document, read the code, validate the analysis, or approve the customer response. That approach can work when AI is producing drafts, but it becomes difficult when agents perform hundreds or thousands of workflow steps.

Review therefore needs to move upward from individual actions toward outcomes, exceptions, and system performance.

A manager of a human operations team does not normally watch every keystroke made by every employee. Management relies on process controls, quality sampling, performance indicators, escalation mechanisms, audits, and investigation when something deviates from expectations.

Human–agent teams need similar mechanisms.

OpenAI Presence includes simulations and evaluations before release, session and action histories after deployment, production quality signals, structured escalation, controlled rollout, and rollback mechanisms. Microsoft likewise recommends recurring operating rhythms in which organizations review agent health, governance, performance, and value rather than waiting for something to fail.

This points toward an important evolution in the role of the manager.

Managers will increasingly need to ask not only, “Did this person do good work?” but also, “Is the system of people and agents producing good outcomes?”

That requires different instrumentation. Acceptance rates, exception rates, escalation quality, cycle time, cost per accepted outcome, policy violations, retries, and customer impact may become more useful than counting how many agent tasks completed.

Review becomes an operating discipline rather than a final approval click.

Review → Accountability

The most difficult part of the framework is accountability.

An agent can execute a workflow. It cannot own the organizational consequences of that workflow in the same sense that a business leader does.

If a payroll agent incorrectly underpays hundreds of employees, saying “the agent made a mistake” does not resolve the accountability question. Someone decided where the agent could operate, what authority it received, which controls surrounded it, and when its performance was good enough to deploy.

Microsoft's current guidance is unusually explicit here. For agents operating core business processes, accountability remains with the business rather than shifting to IT. A named business owner needs to own outcomes even when agents execute much of the process autonomously. Microsoft's broader agentic Center of Excellence guidance similarly recommends explicit owners, sponsors, roles, and decision rights for every agent.

I think this principle will become foundational:

Execution can move to the agent. Accountability cannot disappear.

This is analogous to management in human organizations. A manager delegates implementation without delegating away responsibility for the team's outcomes. Executives delegate decisions while remaining accountable for whether the organization operates correctly.

Agentic systems should preserve that chain.

For every production agent, an organization should be able to name the person or business function responsible for its outcomes, not merely the engineering team that deployed it.

The operating loop: Context → Authority → Execution → Review → Accountability

These five elements form a useful operating model:

Context → Authority → Execution → Review → Accountability

Context determines what the agent knows and how it understands the job. Authority establishes what decisions and actions fall inside its remit. Execution allows the agent to perform work without unnecessary human intervention. Review ensures the organization can evaluate outcomes, inspect exceptions, and improve the system. Accountability ensures that responsibility remains attached to a human organizational structure even when execution becomes increasingly automated.

The model is intentionally similar to good human delegation because many of the underlying management problems are the same.

We would not give a new employee broad access to sensitive systems without defining their role. We would not delegate an important business process without describing what success means. We would not create a team with no manager responsible for its performance.

Agents should not receive weaker operating discipline simply because they are software.

The difference is that technical controls can make authority more explicit. Permissions, approval thresholds, sandbox boundaries, network controls, policy engines, budgets, and audit logs can enforce limits that human organizations often communicate only through policy and training.

Human–agent organizations may therefore become more formal about delegation than human-only organizations ever were.

Escalation should be designed as a success path

One of the biggest mistakes in agent design is treating escalation as failure.

If the objective is maximum automation, every case handed to a person looks like evidence that the agent was not capable enough. Teams then try to eliminate escalations until the agent handles nearly everything itself.

That is the wrong optimization for many business workflows.

A strong operating model recognizes that some cases genuinely require human judgment. The challenge is not to eliminate escalation but to ensure that the agent recognizes those cases early and hands them over with enough context for a person to act efficiently.

OpenAI Presence explicitly treats human escalation as part of the expected production workflow rather than as an exception to agent deployment. Microsoft's core business-process model similarly expects humans to manage exceptions that fall outside the agent's defined autonomy boundary.

For example, a support agent might autonomously resolve common billing questions but escalate cases involving legal threats, unusually large refunds, contradictory account records, or highly emotional customers. The quality of the system depends partly on whether those boundaries are well designed.

A correct escalation can therefore be one of the best possible agent outcomes.

It means the system understood the limit of its authority.

Managers may become designers of work systems

This shift has significant consequences for management roles.

Much management today involves allocating work, clarifying expectations, removing blockers, reviewing output, coaching employees, coordinating dependencies, and monitoring performance. As agents perform more execution, managers will increasingly spend less time assigning individual tasks and more time designing the system through which work is performed.

That can include deciding which work should remain human, which can be delegated to agents, what context agents need, what level of autonomy is appropriate, how exceptions are routed, which metrics indicate success, and how feedback becomes improvements to the workflow.

Microsoft describes a progression in human–agent collaboration from Author to Editor, Director, and eventually Orchestrator. At the orchestrator stage, humans design systems in which multiple agents perform work in parallel while people focus primarily on exceptions and escalations.

The terminology may evolve, but the direction seems plausible.

Good managers may increasingly resemble system designers.

This does not mean management becomes purely technical. In fact, domain judgment becomes more important because someone must decide what work should be delegated and what should remain fundamentally human.

Understanding the process becomes a management advantage.

Domain experts may become more important than prompt experts

The early generative-AI era created substantial interest in prompt engineering because effective use often depended on knowing how to communicate with the model.

As agent platforms mature, I expect a different skill to become more valuable: workflow engineering based on domain expertise.

The person best positioned to design a payroll agent may not be the engineer who knows the model API most deeply. It may be the payroll expert who knows where exceptions occur, which decisions carry legal consequences, what managers normally approve, how cases escalate, and what signals indicate that something is unusual.

OpenAI's Agent Activator framework reflects this idea by defining workflow ownership—not coding ability or job title—as the defining characteristic of the role. The Activator is accountable for how an AI-enabled workflow works for other people and coordinates requirements, human decisions, access, rollout, reliability, measurement, and maintenance.

Engineering still matters enormously. Someone has to build the integrations, observability, permissions, evaluations, and runtime architecture that make the workflow reliable.

But domain experts provide the operating logic.

Human–agent teams therefore may become another reason for engineering and business functions to work more closely rather than a reason for technology teams to automate business functions independently.

Agents need managers too, but not in the human sense

It is tempting to say that agents will become digital employees and therefore need managers.

The analogy is useful, but only to a point.

Agents do not need motivation, career development, psychological safety, compensation conversations, or many of the other things that make human management deeply human. Treating them literally like people risks confusing what the technology actually is.

What agents do need is operational management.

They need owners. They need clearly bounded roles. They need performance expectations. They need access appropriate to those roles. They need monitoring. They need version management. Their failures need investigation. Their behavior needs improvement when the business changes.

Microsoft's newly published Center of Excellence model essentially formalizes this operational requirement. It recommends treating agents as products rather than one-off projects, assigning roles and decision rights, governing according to risk, maintaining lifecycle processes, and establishing recurring reviews.

That is less like traditional people management and more like a combination of product management, platform operations, risk management, and process ownership.

Calling it management is still useful because the core idea remains: autonomy without ownership does not scale.

Not every workflow should become agent-first

There is a risk that enthusiasm around agents pushes organizations toward autonomy even where it adds little value.

Some workflows are deterministic enough that conventional software is better. Others depend heavily on empathy, negotiation, ethics, or complex human relationships. Some occur too rarely to justify the engineering and governance required to automate them safely. Others may technically be automatable but have such high consequences that maintaining human execution is economically rational.

A human–agent operating model should therefore begin with work design, not automation targets.

What parts of the workflow benefit from AI reasoning? Where does judgment matter? Which repetitive tasks consume disproportionate human attention? Where is latency costly? Where are exceptions frequent? Which decisions require accountability that should remain close to the human executing them?

Microsoft's risk-based guidance makes a similar point: a meeting summarizer and an agent that moves money should not receive the same governance model. Applying heavy controls to every assistant suppresses adoption, while giving executing agents assistant-level governance creates hidden risk.

There is no universal autonomy level that organizations should pursue.

The correct level is the one that creates useful leverage without obscuring responsibility.

Human work moves toward exceptions, judgment, and system improvement

If agents become effective at routine execution, the remaining human workload naturally changes.

People spend less time assembling information and following repetitive procedures. They spend more time on ambiguous cases, relationships, policy decisions, exceptions, system design, and improvement.

Anthropic's Claude Cowork positioning reflects this division directly: the agent handles assembly and synthesis while users retain consequential decisions and refinement. Its broader autonomy research also suggests that experienced users move away from constant approvals and toward monitoring plus intervention.

That transition sounds attractive, but organizations should not assume it happens automatically.

If an agent resolves routine cases but sends poorly prepared exceptions to humans, the remaining job may become more frustrating rather than more valuable. Employees receive only the hardest cases without enough context, while losing exposure to routine work that previously helped them build expertise.

Escalation architecture therefore becomes part of job design.

A good handoff should explain what the agent observed, what it attempted, why it stopped, which policies or evidence are relevant, and exactly which decision requires human judgment.

The objective should not simply be to remove work from people.

It should be to create a better division of work.

Accountability is the constraint that keeps the system coherent

As organizations move deeper into agentic work, it will become increasingly tempting to talk about processes that “run themselves.”

Technically, many workflows may eventually approach that level of automation.

Organizationally, they should never become ownerless.

Someone must decide the acceptable error rate. Someone must approve the authority boundary. Someone must decide whether escalations are handled correctly. Someone must decide whether the economics justify the system. Someone must decide when an agent has degraded enough to be disabled.

That person may not perform the workflow anymore.

But they still own the outcome.

This is why the final element of the framework matters so much. Without accountability, context becomes documentation, authority becomes permissions, execution becomes automation, and review becomes dashboards—but nobody is responsible for whether the entire system actually works.

A human–agent team is still a team operating inside a human organization.

The business remains accountable for what that team does.

The manager's new question

The first era of enterprise AI asked managers to encourage employees to use AI.

The next era will require something more sophisticated.

Managers and engineering leaders will need to decide how work should be decomposed between humans and agents, how authority should be delegated, how agent performance should be evaluated, and how people should intervene without becoming permanent bottlenecks.

The core management question changes from:

How can AI help this person work faster?

to:

What should the human–agent system be responsible for, and how should responsibility be divided inside it?

That requires understanding the entire operating loop:

Context → Authority → Execution → Review → Accountability

The agent needs enough context to understand the job. It needs explicit authority to know its boundaries. It needs room to execute without constant micromanagement. Humans need mechanisms to review outcomes and handle exceptions. And a named human organization must remain accountable for the results.

The technical capability to deploy agents is arriving quickly.

The harder challenge will be redesigning organizations so that humans and agents can work together without creating confusion about who knows what, who decides what, who does what, and who is ultimately responsible.

The companies that solve that problem will not simply have more AI.

They will have a new operating model for work.