From Human-in-the-Loop to Governance by Design: orchestration, delegated authority and bounded autonomy in AI-enabled project management.

Intelligent Agents Do Not Make an Intelligent System

Consider a Project Management Information System (PMIS) that continuously monitors schedules, identifies emerging risks, analyses financial deviations, reviews contractual commitments and recommends corrective actions. Suppose these tasks are performed by specialised AI agents that communicate with one another, retrieve organisational knowledge, use enterprise tools and execute some actions on their own.

Most of what is needed to start building such a system is already available. Yet connecting several capable agents to a PMIS does not, in my view, produce an Intelligent PMIS. The harder problem is architectural: creating the conditions in which multiple agents can collaborate, act within delegated authority and remain under effective organisational control.

This article synthesises three pieces I published in Portuguese on PM2ALL over the past few weeks. Each asked a different question. The first asked whether Human-in-the-Loop is enough, and concluded that a human approval step does not by itself amount to oversight. The second asked who governs the agents once the PMIS starts to act, and separated orchestration from governance and authority. The third asked how delegated authority can be made enforceable, and proposed the Agent Authority Envelope and the principle of Governance by Design.

Together they support a single thesis: the value of an Intelligent PMIS will depend less on the intelligence of its agents than on the quality of the governance architecture that bounds what they are allowed to do. I also connect this thesis to my FinOps for AI series, because the economics of multi-agent systems turn out to be a governance question as well.

1. From Intelligent Agents to an Intelligent System

Enterprise AI has followed a fairly clear progression. Large Language Models came first, then Retrieval-Augmented Generation (RAG) to connect them to organisational knowledge, and then AI agents able to pursue objectives, use tools, reason across several steps and act.

In project management this suggests a Planning Agent analysing schedules and dependencies, a Risk Agent monitoring threats, a Cost Agent evaluating financial performance and a Procurement Agent examining contractual implications. Each could grow more sophisticated within its own domain, but a collection of competent agents is not necessarily a competent system.

Take a critical supplier that is likely to miss a delivery milestone. The Risk Agent flags the threat. The Planning Agent recommends accelerating other activities. The Cost Agent concludes that doing so will raise expenditure. The Procurement Agent points to contractual constraints. All four may be right, and their recommendations still conflict, because locally optimal advice rarely adds up to a globally optimal project decision. This is the familiar problem of sub-optimisation, now reproduced across autonomous components.

These are the trade-offs project managers have always faced: protecting the schedule may raise costs, minimising expenditure may increase risk, and strict contractual compliance may reduce flexibility. What changes is that analysis, recommendation and potentially execution are now spread across autonomous components operating at machine speed. An Intelligent PMIS therefore needs an architecture able to coordinate that intelligence and to resolve its conflicts under rules the organisation has set.

2. Orchestration and Governance Are Different Responsibilities

In a multi-agent Intelligent PMIS I distinguish two responsibilities.

The Orchestration Layer answers the question: who should perform this task? It coordinates the specialised agents, manages dependencies, maintains workflow state and keeps the execution process coherent.

The Governance and Authority Layer answers a different question: is this agent authorised to perform this task? It determines whether the proposed action is permitted, which conditions apply, what authority has been delegated and whether human intervention is required.

The two problems are distinct. An orchestrator may correctly select the Planning Agent to update the schedule, yet the Planning Agent may have no authority to modify an approved baseline. A Cost Agent may rightly recommend drawing on contingency reserves without being entitled to commit additional expenditure. Selecting the right agent and authorising its action are different decisions.

The separation is conceptual and does not require two independent software products. Implementations may combine the components, provided the responsibilities remain clearly defined and enforceable. What matters is that intelligence determines what an agent can recommend, while governance determines what it is allowed to do.

3. Capability Is Not Authority

Organisations have never treated technical capability and decision-making authority as the same thing. A project manager may have access to financial systems without authority to approve every expenditure, and a procurement manager may be able to issue purchase orders yet remain subject to financial limits. There is no obvious reason why AI agents should be different, and emerging work on bounded autonomy and delegated authority offers a useful conceptual basis for this view.

I find it helpful to separate three concepts: Capability → Authority → Execution. Capability is what an agent can technically do. Authority is what the organisation has permitted it to do. Execution is the action actually performed, subject to the applicable controls. That an agent can perform an action should never, by itself, justify letting it do so.

A Planning Agent, for instance, might be capable of restructuring an entire schedule while its delegated authority is limited to optimising activities that do not affect contractual milestones or approved baselines. It could analyse alternatives, simulate consequences and prepare change proposals without being permitted to implement them. This is what I mean by bounded autonomy. The aim is to define the conditions under which autonomy can exist safely rather than to remove it, so the useful question is not whether an agent should be autonomous but under what conditions it may act without further authorisation.

4. The Agent Authority Envelope

To make delegated authority explicit, my most recent article proposes the Agent Authority Envelope, an architectural representation of the authority granted to an individual agent. It draws on established principles of delegated authority, bounded autonomy, runtime governance and auditability. The envelope would define, among other things:

the agent’s identity, responsibilities and authorised capabilities;
the data sources, tools and enterprise systems it may access or modify;
the financial, operational and temporal limits within which it may act;
the decisions it may execute autonomously and those that require human approval;
the conditions that trigger escalation, interruption or recovery;
the evidence that must be preserved for audit and accountability.

Autonomy thus becomes contextual rather than absolute. The same Planning Agent might work with broad authority on a low-risk internal initiative and under much tighter limits in a highly regulated programme. Its envelope could also change with the project phase, the criticality of the activity affected or the consequences of the proposed action. This is a richer description than the binary label of autonomous or non-autonomous, and it raises the next question: how to ensure that delegated authority is actually respected.

Intelligent PMIS architecture showing specialised AI agents, orchestration, governance, delegated authority and runtime controls

Figure 1: From agent coordination to governed execution: orchestration determines who should act; governance determines what each agent is authorised to do.

5. Policies Are Not Controls: The Case for Governance by Design

Most organisations already have governance policies, from decision rights in project management plans to approval limits in procurement procedures. Documenting a rule, however, is different from enforcing it. Suppose a governance policy requires Steering Committee approval for changes above €100,000. If an AI agent can technically execute a €150,000 change without that approval, the organisation has a policy but no effective control. The gap widens when agents act at machine speed, because an instruction written in an agent’s prompt is not an independently enforced authorisation mechanism.

Governance must therefore move from documentation into the execution architecture. This is the core of what I call Governance by Design, and it operates at three moments:

Before execution, the system defines the agent’s authority, permissions, operational limits, accessible data, permitted tools and escalation conditions.
During execution, independent runtime mechanisms verify that proposed actions remain within those limits, and block or suspend any action that requires authority not yet granted.
After execution, the system preserves enough evidence to reconstruct what happened: which information was used, which authority applied, which actions were performed and who approved consequential decisions.

This goes well beyond conventional Human-in-the-Loop, because governance becomes a continuous property of the system rather than an approval step added at the end of a workflow.

6. Human Oversight Should Be Meaningful, Not Decorative

My earlier article argued that an approval button inside an automated workflow does not create effective oversight. A project manager asked to approve dozens of AI-generated recommendations every day can drift into rubber-stamping, and the more convincing the agents become, the stronger the temptation to accept their output without scrutiny. Meaningful oversight requires that the responsible person has enough information to understand the recommendation, enough time to evaluate it, real authority to challenge it and an effective way to stop or change the resulting action.

Asking humans to validate every minor action is neither realistic nor desirable, since it dilutes the attention available for decisions that matter. I therefore see effective oversight as a combination of anticipatory governance, bounded autonomy, continuous observability and human intervention triggered by risk, authority or consequence. The objective is to preserve human judgment where it is indispensable rather than to involve humans in every decision. Clear boundaries can, in this way, enable more autonomy and not less.

7. What Would This Look Like in a Real Project?

Return to the supplier delay, now handled as a Change Request. The PMIS starts a coordinated process in which the Risk Agent evaluates the exposure, the Planning Agent analyses schedule alternatives, the Cost Agent estimates the financial consequences and the Procurement Agent reviews the contractual implications. The Orchestration Layer coordinates their contributions and maintains a consistent view of the project’s state. The Governance and Authority Layer decides which actions may proceed automatically and which need further authorisation.

The agents could be authorised to retrieve information, run calculations, evaluate alternatives and prepare a consolidated recommendation, while changing an approved baseline, committing additional expenditure or modifying contractual obligations triggers mandatory approval. Instead of four disconnected AI responses, the project manager receives a structured decision package with the evidence and the trade-offs between alternatives. After an authorised decision, the system executes the permitted changes through controlled tools and preserves an auditable history.

The value therefore does not lie in having several agents that can each analyse a Change Request. It lies in a governed system that turns their analysis into coordinated, authorised and auditable execution.

8. Governance Also Includes Data, Memory and Costs

Two further dimensions deserve attention. The first is organisational knowledge. In an Intelligent PMIS, RAG is more than a way to improve the accuracy of answers. Governing it means knowing which documents an agent consulted, whether it was authorised to access them, which versions it used and whether the information was still valid. The same applies to persistent agent memory. Who can modify it? How is incorrect information corrected? Can unvalidated information produced by one agent influence others?

The second is economics. A single request may trigger several agents, retrieval operations, model calls, simulations and repeated attempts, and each consumes resources. An architecture that cannot measure the cost of its own decisions lacks an important governance capability. We should be able to measure the cost of AI per project or per agent, and also the cost of processing a Change Request, evaluating a risk or producing a decision that delivers measurable value.

This is where the Intelligent PMIS work meets my FinOps for AI series, and the connection is direct. The Authority Envelope already includes financial limits, and FinOps for AI supplies the visibility and unit economics needed to set those limits sensibly and to verify them at runtime. The distinction from section 5 applies here as well: cost visibility without enforcement is a report, whereas cost limits enforced during execution are a control. Cost visibility, model selection, orchestration efficiency, consumption limits and value attribution therefore have to be designed into the architecture, and cannot be treated as an accounting exercise after deployment. A technically capable Intelligent PMIS with uncontrolled operating costs would be hard to call intelligent.

9. The Project Manager’s Role Is Changing

If Intelligent PMIS architectures evolve in this direction, much of the reporting, schedule analysis, risk identification, financial forecasting and preparation of decision alternatives that project managers do today will be automated or heavily assisted by AI. I do not think they need to become AI engineers. Their contribution will remain managerial.

They will help define which decisions can be delegated, what autonomy boundaries apply and when decisions must be escalated to sponsors or governance bodies, and they will have to decide which trade-offs are acceptable when recommendations conflict. Technical enforcement will depend on AI engineering, enterprise architecture, security and platform governance, but the organisational meaning of authority cannot be defined by technology alone. The project manager’s role may therefore shift from supervising tasks and consolidating information towards governing a decision-making process in which humans and autonomous agents work together.

Conclusion: The Agent Is Not the Product

We are likely to see a growing number of AI agents designed for project management. Some will prove useful and others will be little more than existing workflows with an AI interface, but the more important distinction will be architectural. An Intelligent PMIS should not be understood as a PMIS with several agents added. I see it as a sociotechnical system for project execution, in which people, agents, organisational knowledge, enterprise tools and governance mechanisms operate within a common architecture.

The progression can be summarised as: AI Assistant → Agent → Delegated Authority → Bounded Autonomy → Runtime Governance → Auditable Execution.

This remains an architectural exploration, and it does not claim that all these elements have been implemented and validated together in a production-grade system. My expectation is that the next stage of AI in project management will be shaped less by how many agents we can build than by how well we govern what they are allowed to do, and that this may be the difference between adding AI to project management and changing how projects are actually executed.

Pesquisar este blog

PM2ALL - Gestão de Projetos | IA | Intelligent PMIS