Your AI Agent Needs a Delegation of Authority

By Steven Gabris

Executive Summary

AI agents are starting to perform work that PMOs have traditionally assigned to coordinators, analysts and assurance functions: checking evidence, monitoring portfolio data, escalating exceptions and updating workflow records.

That shift creates a delegation question. What is the agent responsible for doing? What is it authorised to decide, communicate or change? What system permissions enable those actions? And who remains accountable when it gets something wrong?

PMOs & Portfolio leaders should treat consequential agent authority as bounded and reviewable. The greater the effect an agent can have on an official record, workflow or governance outcome, the clearer its mandate, limits, controls and human accountability need to be.

When assistance becomes delegation

Many of the early uses of AI in delivery remain straightforward assistance.

A business analyst can use an agent to draft or split user stories. A project manager can use one to improve a risk description, identify potential dependencies or interrogate a plan. An agent might assess RAID information against agreed standards and point out that an escalation lacks a clear impact, owner or mitigation.

But the practitioner still owns the work and decides what happens next. Or at least they should...

The onus boundary changes when an agent can trigger an escalation, block or advance a workflow, alter an official record or communicate a governance outcome without case-by-case human approval. At that point, the organisation has moved beyond assistance and delegated some authority to act.

For a portfolio leader or a PMO, this could begin quite modestly. An agent reviewing a stage-gate submission might be authorised to return it when objective completeness requirements have not been met, such as missing mandatory artefacts or absent approvals. Whether the evidence is substantively adequate, whether an exception should be granted, or whether the gate should ultimately be approved can remain with the authorised governance body.

That distinction allows us to automate parts of assurance without quietly automating the decision rights that sit behind it.

Define what the agent is actually allowed to do

A useful starting point is to separate four concepts that can easily become blurred when discussing agentic AI.

• Responsibility is the work assigned to the agent.

• Authority is what it is allowed to decide, communicate, change or initiate.

• Permissions are the technical access rights that enable or constrain those actions.

• Accountability remains with the human or organisational role answerable for how the agent operates and the consequences of its actions.

An agent may therefore have technical permission to update a portfolio system while being authorised to make only specific, bounded changes. Its human owner remains accountable for the way that authority is exercised.

This leads to three questions that should be answered before an agent is allowed to act independently. Our second question is likely to become increasingly important as agents move from producing information to acting within delivery workflows.

Authority is not a single scale

I initially thought about agent authority as a straightforward progression:

Observe → Analyse → Recommend → Communicate → Update → Execute → Commit

It is a useful starting point, but it should not be mistaken for a simple maturity model.

Observing portfolio information is materially different from changing it. Recommending an escalation is different from sending one. Initiating an approved workflow is different again from making a commitment that binds the organisation.

Within each category consequences can vary. Communication could be an automated reminder to a project manager or an escalation to an executive governance forum. An update could add a machine-generated classification to a risk or change the project's official RAG status. Execution could route a stage-gate submission for review or trigger a financial transaction.

The level of control therefore needs to reflect more than the apparent sophistication of the agent. We should consider the consequence of the action, its reversibility, the decision rights involved and the evidence that the agent can perform the work reliably.

An agent might become very good at identifying milestones that appear likely to slip. That is evidence that it can perform analysis. It is not, by itself, a reason to allow the agent to move a committed milestone.

Technical capability answers: "Can the agent do this?"

Delegation of authority answers: "May the agent do this?"

The two should never be confused.

A PMO cannot delegate authority it does not possess

This is were the familiar governance disciplines we know and love become useful. Organisations already operate with delegations of financial authority, project and program decision rights, risk acceptance thresholds, segregation of duties and escalation paths. Agentic AI does not make those structures obsolete.

We may have authority to define the evidence required at a delivery gate. It may be able to delegate an objective completeness check to an agent and allow that agent to return a submission when mandatory material is missing.

In the same breath we likely do not have the authority to approve expenditure, accept a material operational risk, vary approved scope or commit capacity from another function.

An AI agent cannot cure that authority gap.

If you and your function does not possess a particular decision right, giving its agent technical access to systems that could execute the action does not create the missing authority. At most, the agent can prepare the decision, route it to the appropriate authority and retain evidence of what occurred.

The same principle applies to segregation of duties. An agent should not collapse controls simply because it can technically perform several steps in a process that humans were deliberately prevented from performing end to end. This is why system access and organisational delegation need to be designed together.

Permissions determine what an agent is technically capable of doing. Delegation determines what the organisation has authorised it to do. Effective controls require both: the agent should not be technically able to perform an unauthorised action, and authorised actions should have technical guardrails that keep them within their agreed boundaries.

Treat agents as operational roles, not just software

BNY provides an interesting example of where this thinking may be heading.

BNY reported 134 "digital employees" in production at the end of 2025, describing them as multi-agent systems operating autonomously alongside human colleagues. Microsoft's subsequent case study describes BNY's digital employees as having login credentials, employee numbers and supervisors who assign tasks and review outputs. It also describes a developing Digital Employee

Agency covering decisions about when digital employees are appropriate, along with onboarding, scorecards and structured offboarding. The value of the example is not the terminology. An AI agent is not an employee in the legal or human sense, and creating an artificial HR bureaucracy around every delivery assistant would add little value.

The transferable idea is operational ownership.

When an agent performs an ongoing role within a delivery process, somebody needs to own that role. Its mandate and access need to be defined, its performance needs to be observable, and there needs to be a way to change, restrict, suspend or retire it.

That becomes particularly important because the environment around an agent will change.

Consider a RAID advisor configured against an organisation's current risk framework. Six months later, escalation thresholds change, terminology is updated or the PMO changes the evidence expected for a mitigation plan.

The agent might continue behaving exactly as it was designed to behave and still produce the wrong organisational outcome.

The appropriate response may have nothing to do with retraining the underlying model. The PMO may need to update its policy content, revise instructions or decision rules, change access controls, introduce a human approval step, run regression testing or temporarily withdraw the agent from service. If the operating standard changes, the agent performing the role needs to change with it.

Authority needs a control loop

The decision to give an agent authority should not be permanent. A portfolio leader needs enough performance evidence to determine whether the delegation remains appropriate. That does not require another elaborate reporting regime. It requires a control loop connected to actual outcomes.

Measure the quality of the agent's outputs and the exceptions it creates. Review human overrides, incorrect escalations, incidents and known gaps. Compare its behaviour against the current policy, delivery framework and operating conditions. Where the evidence identifies a problem, change the instructions, controls or delegated authority and test the result before restoring broader autonomy.

The same evidence can support greater delegation. An agent that has consistently performed bounded work within agreed tolerances may eventually be trusted with additional actions. Another may remain valuable as an advisor because the consequences of independent action are too high.

The decision should depend on evidence, risk and the nature of the authority involved rather than enthusiasm for autonomy.

Build a Organisation delegation register

As the number of agents grows, we will need a practical way of knowing which ones warrant formal oversight.

A useful threshold is whether an agent can, without case-by-case human approval, alter an official record, issue a governance or external communication, block or advance a workflow, trigger a financial or operational action, or materially influence a decision.

For agents above that threshold, I would expect a PMO delegation register built around four domains:

• Mandate: What work has the agent been assigned? What decisions, communications, updates or actions may it perform, and where are the boundaries?

• Accountability: Who owns the agent operationally? Who granted its authority? Where does authority remain with another function or governance body, and what is the escalation path?

• Controls: What systems and information can it access? What technical restrictions enforce the delegation? What policies, frameworks and decision rules is it expected to apply? Where is human approval mandatory?

• Evidence: How is output quality assessed? What exceptions, overrides and incidents have occurred? What known gaps exist? What actions are underway to address them, and when was the delegation last reviewed?

This is not intended to turn every AI assistant into a governance exercise. A story-writing assistant operating under direct human supervision should not require the same controls as an agent acting as a PMO delegate during a stage-gate process. Governance should follow consequence.

Conclusion

The most important governance question for a delivery agent is not whether it is autonomous. It is whether its role, decision rights and limits are explicit.

We should treat every consequential agent action as a delegation. Someone with legitimate authority defines the mandate. A human remains accountable. Technical controls enforce the boundary. Performance evidence determines whether that mandate expands, contracts or ends.

AI may automate parts of delivery governance. It does not automate the need for governance.

About Steven Gabris

Steven Gabris is an enterprise delivery and transformation leader with experience across banking, payments and regulated environments. He has led and supported large-scale transformation, delivery governance, PMO capability and AI-enabled delivery initiatives, with a particular focus on turning emerging technology into practical operating models that improve how organisations plan, govern and execute work.

His current work includes helping delivery teams and leaders apply AI within project and portfolio environments while strengthening the governance, workflows and management disciplines required to make those capabilities operational.

Sources

BNY. Annual Report 2025: Built for Opportunity. 2026. BNY reports 160 enterprise AI solutions in production and 134 digital employees, which it describes as multi-agentic AI solutions operating autonomously alongside human colleagues.

Microsoft WorkLab. The Making of a Frontier Firm: How AI Is Redesigning Work at BNY. 12 May 2026. Describes BNY's digital employees as having login credentials, employee numbers and supervisors, and discusses the developing Digital Employee Agency, including onboarding, scorecards and structured offboarding.

OpenAI. BNY Builds "AI for Everyone, Everywhere" with OpenAI. 12 December 2025. Describes BNY's Eliza platform and advanced AI agents or "digital employees" with identities, access controls and dedicated workflows.