Your First Project Management Agent
AI agents are beginning to move beyond simple question-and-answer tools. BNY has described digital employees with defined responsibilities, system credentials, nicknames and human managers, while KPMG has discussed redesigning work across human, hybrid and agent-led roles. These models suggest that organisations are beginning to think about AI as part of their workforce and operating model, rather than simply another application used by employees.
The idea is interesting, but it can also make the first step appear more complicated than it needs to be. A project manager does not need to begin with an agent that has its own login credentials, communicates independently with stakeholders and updates enterprise systems. Most organisations are not ready to provide that level of access, and many project managers would struggle to justify it before the agent has demonstrated that it can perform a narrower role reliably.
A better starting point is an on-demand project coordination agent.
Its first responsibility should not be managing the project. It should support a defined management process, such as preparing a status report or reviewing updates to a RAID log. A narrowly designed agent can help collect, compare and organise information while leaving judgement, approval and accountability with the project manager. It provides a practical way to test whether AI can improve delivery work without giving it more authority than the organisation is ready to manage.
Start with a problem that project managers already understand
Project status reporting is a sensible first use case because the process is familiar, repetitive and often inefficient. A project manager may spend a large part of each reporting cycle requesting updates, following up incomplete responses, reviewing workstream reports, checking plans, reconciling conflicting information and restructuring the material for a steering committee.
The administrative work is considerable, but producing the document is not the hardest part. The more important task is determining whether the information being reported reflects delivery reality.
A workstream may report that it is green while several milestones are slipping. A dependency may appear in a plan but have no confirmed commitment from the team expected to deliver it. A risk may have an owner but no meaningful mitigation. A decision may have been discussed several times without being formally made.
These are the areas where a useful agent should assist. It should not merely combine several updates into a cleaner report. It should help the project manager identify missing evidence, inconsistent claims and matters requiring intervention. That gives us a clear starting role:
The agent collects, compares, challenges and drafts. The project manager decides, approves and remains accountable.
What the minimum viable agent should do
For an initial trial, I would give the agent a limited set of responsibilities. It could review updates from workstream leads, compare them with the previous reporting period and check whether each update contains the information required for project reporting. This would include progress completed, planned work, milestone confidence, risks, issues, dependencies, decisions and overdue actions.
The agent could then review the project plan and RAID log to identify inconsistencies. It might notice that a milestone remains green even though a supporting dependency is overdue, or that a risk has been repeatedly carried forward without an effective response. From that analysis, the agent could prepare:
a draft executive status summary
proposed workstream summaries
material changes since the previous report
proposed RAID-log updates
overdue actions and dependencies
inconsistencies and missing information
questions requiring project-manager judgement
The agent should not independently change an official RAG status, close a risk, approve a mitigation, record a decision as final or send a steering committee report. The agent may recommend that the overall status requires review. It should not decide what the final status will be.
The first version does not need to contact anyone
It is easy to describe an agent as if it will independently seek updates from workstream leads. In practice, that capability requires more than a well-written instruction.
An agent would need approved access to email, Teams, Slack or another communication platform. It would need a recognised identity, a defined stakeholder list, rules governing what it may send and controls over how frequently it follows people up.
It would also need access to the correct project documents and sufficient permissions to distinguish between approved records, working drafts and superseded information.
A project manager copying instructions into a public AI tool will not automatically create that capability.
The minimum viable version should therefore be on demand. The project manager provides the workstream updates, previous report, current RAID log and relevant milestone information. The agent analyses the information and prepares a draft review pack.
This may appear less ambitious, but it is a better test. Before an organisation allows an agent to seek information or update records, it should first establish whether the agent can interpret the supplied information reliably.
Build the agent around a clear job description
The quality of the agent will depend heavily on the clarity of its role. Telling an agent to “help with project reporting” leaves too much room for interpretation. It does not explain what sources it may use, what conclusions it may draw or what must remain with the project manager.
I would define the role more precisely:
You are a Project Status and RAID Coordination Agent supporting a human project manager. Your purpose is to collect, organise, compare and assess project-delivery information. You may prepare draft outputs and recommend follow-up questions. You do not have authority to approve, finalise, publish or communicate an official project position.
First, the agent has a defined management process to support. It is not expected to perform every activity associated with project management.
Second, all outputs remain drafts. This preserves the distinction between analysis produced by the agent and an approved project position.
Third, the human project manager remains visibly accountable.
That last point matters because a polished output can create an illusion of authority. A status report may be clearly written and professionally structured while still being based on incomplete or contradictory information. The agent should be designed to expose that uncertainty, not write around it.
Tell the agent what it must never invent
Project information frequently contains gaps. A workstream may omit an owner, due date or mitigation. A decision may be mentioned without a clear record of who approved it. A progress percentage may be reported without evidence explaining how it was calculated.
An agent may be tempted to resolve those gaps by producing the most plausible answer. That is unacceptable in a delivery environment. The instructions should explicitly prohibit the agent from inventing:
dates
owners
progress percentages
decisions
commitments
risks
mitigations
financial information
RAG ratings
Where information is missing, the agent should state that confirmation is required. Where sources conflict, it should describe the conflict and ask for clarification. It should not silently choose the version that appears more likely.
This sounds basic, but it changes the nature of the output. The agent is no longer rewarded for producing the smoothest report. It is expected to preserve uncertainty where the project evidence is uncertain.
Teach it to challenge reported status
Many status-reporting processes rely too heavily on the colour selected by the workstream. If a team reports green, the status often remains green unless someone actively challenges it. The result can be a project that looks healthy until a delayed dependency or incomplete deliverable becomes impossible to ignore.
A useful agent should not accept the reported colour without reviewing the supporting information.
Where the relevant evidence is available, it should test the status against:
milestone dates
completed and remaining work
testing progress
unresolved risks and issues
overdue actions
dependencies
decisions still required
resource or capacity constraints
changes to scope or assumptions
This should identify where the evidence does not support the reported status and place the matter before the project manager.
For example:
The technology workstream remains reported as green. However, two integration components remain incomplete, developer capacity has been reduced and the testing team has not received a stable environment. Project-manager review of the milestone status is recommended.
That is a useful observation. It does not allow the agent has authority to make the final judgement.
Testing matters more than the prompt
The first set of agent instructions will not be perfect. The agent may produce too much information, fail to distinguish a risk from an issue or repeat the language used by a workstream without sufficiently challenging it. It may identify every missing field and bury the project manager in low-value questions.
That is why the agent should be tested before it is introduced into a live reporting cycle. I would create a fictional project scenario containing deliberately weak reporting. The scenario should not be designed to make the agent look good. It should be designed to reveal whether the instructions are strong enough.
For the initial test, I used a fictional customer onboarding platform with a target go-live date of 30 September. The previous report stated that the project was green, the build was 80 per cent complete and system testing would begin on 3 August. The data migration approach was still awaiting approval but was not expected to affect delivery.
The current updates included several warning signs:
two integration components remained under development
a developer had been moved to another priority
the planned testing start was under pressure
the test environment had no confirmed delivery commitment
the migration approach would not be considered until 6 August
two operational exception pathways remained unresolved
the migration risk had a weak mitigation
phased migration had been discussed but not approved
A weak agent would combine these updates and reproduce the existing green status.
What the test should prove
Before I considered the agent ready for a real project, I would expect it to pass several acceptance tests. It should identify that the planned testing start is at risk because the required interfaces and stable environment are not yet available.
It should recognise that the test-environment dependency has no confirmed commitment. Recording a dependency is not the same as securing agreement from the team expected to deliver it.
It should question whether “continue working through the approval process” is a meaningful mitigation for the migration risk.
It should distinguish the discussion of phased migration from an approved decision and refuse to place it in the decision register as final. It should flag that the overall green status requires project-manager review but avoid inventing a replacement rating.
It should also keep the output focused. A project manager does not need another document that simply repeats every workstream update. The value is in identifying what changed, what does not add up and where judgement is required.
The test should produce changes to the agent
The purpose of testing is not to validate the original design. It is to improve it. Suppose the agent detects the testing concern but fails to recognise the weakness of the migration mitigation. The instructions may need a more explicit rule requiring it to check whether a risk response changes the probability or impact of the risk.
If the agent records phased migration as a decision, it needs a stronger distinction between:
an idea raised in discussion
a proposed decision
a decision awaiting approval
an approved decision
If the output contains twenty questions for the project manager, the agent may need to prioritise only matters affecting milestones, scope, cost, risk, dependencies or executive decisions.
Each test should result in an improvement log:
Problem observed | Instruction changed | Expected improvement |
Agent accepted green status too easily | Added evidence checks against milestones, testing and dependencies | Stronger challenge of unsupported status |
Agent treated discussion as a decision | Added decision-evidence rules | Only approved decisions recorded as final |
Agent generated too many minor questions | Added materiality and prioritisation rules | Shorter management review list |
Agent proposed missing owners | Added prohibition on invented ownership | Missing owners clearly marked for confirmation |
Creating the agent is not the final step. The manager must continue reviewing how it performs and adjust the design when recurring weaknesses become visible.
The project manager still needs to know the project
An agent does not remove the need for the project manager to understand the delivery detail.
In some respects, it makes that understanding more important. If the agent produces an inaccurate summary, the project manager needs enough knowledge to recognise it. If the agent identifies a possible contradiction, the project manager must determine whether it is material. If the agent recommends a RAID update, someone must assess whether the item is appropriately framed and whether the proposed response is credible.
The manager cannot become a passive reviewer who accepts a polished output because the source references appear convincing. The agent may make information easier to process, but the project manager remains responsible for the judgement applied to it.
My draft-to-final rule would therefore remain firm:
The agent may prepare, analyse, compare and recommend. Anything moving from draft to final requires human review.
This is particularly important for executive reporting, financial information, stakeholder commitments, risks, decisions and formal escalations.
How to measure whether the agent is helping
Time saved is an obvious measure, but it is not sufficient. An agent that drafts a report in five minutes may still create significant rework if it misses important information or produces unreliable conclusions.
I would evaluate the agent against several practical questions:
Did it identify meaningful inconsistencies?
Did it preserve the distinction between evidence and analysis?
Did it correctly identify missing information?
Did it avoid inventing owners, dates or decisions?
Did it reduce the time required to prepare the reporting pack?
How much rework was needed?
Did it improve the quality of the questions asked of workstream leads?
Did it help the project manager intervene earlier?
Did it make the final report more accurate and useful?
It may be the identification of a dependency, decision or risk that would otherwise have remained hidden inside fragmented project information.
A practical maturity path
The minimum viable version is only the first level.
At Level 1, the agent operates on demand. The project manager provides the information and requests an analysis.
At Level 2, the agent is connected to approved project folders and can retrieve current records without the project manager manually loading each document.
At Level 3, the agent can coordinate the reporting process through approved communication channels, including requesting updates and following up incomplete responses.
At Level 4, the agent may be permitted to propose or make controlled changes to project systems, subject to approval gates and auditable records.
You should not rush through these levels. An agent that has not demonstrated reliable analysis at Level 1 should not be given the ability to independently contact stakeholders or update official records. Greater integration increases potential value, but it also increases the impact of poor instructions, incorrect conclusions and inappropriate access.
Your first agent is a management experiment
The first project management agent should be treated as a controlled management experiment.
Give it one defined process. Provide clear sources. Establish what it cannot do. Test it with difficult information. Review its output and improve the instructions.
Do not begin by asking it to manage the project. Begin by asking whether it can make one part of project management more reliable. Status reporting and RAID coordination are suitable starting points because they expose the agent to the realities of delivery information: incomplete updates, disputed commitments, optimistic status and decisions that have not been properly recorded.
If the agent can help the project manager see those problems earlier, it has created value.
If it only produces a more polished version of the same weak reporting, it has not.
The goal is not to create the appearance of a digital employee. It is to establish whether a defined piece of digital capacity can be managed, tested and trusted within clear limits. Only then should the organisation consider giving it more work.
A simple agent-builder template
The following is a shortened version of the instructions I would use to create the minimum viable agent.
Role
You are a Project Status and RAID Coordination Agent supporting a human project manager.
Your role is to review project updates, compare them with approved project records, identify missing or inconsistent information and prepare draft reporting outputs.
You may:
review workstream updates
compare current and previous reporting periods
identify missing information and contradictions
flag possible risks, issues, actions and dependencies
prepare a draft status summary
recommend draft RAID-log updates
prepare questions for the project manager
You may not:
finalise or publish a status report
change an official RAG status
close a risk, issue, action or dependency
record a decision as approved without evidence
invent owners, dates, commitments or mitigations
communicate an official project position
Source rules
Use only the project information supplied or contained in approved project sources.
Separate:
reported information
approved project records
your analysis
missing information
recommendations requiring approval
Where sources conflict, describe the conflict and request clarification.
Status challenge
Do not accept a reported green status automatically.
Where the information is available, test the reported status against milestone dates, remaining work, testing readiness, unresolved risks, overdue actions, dependencies, decisions and resource constraints.
Required output
Prepare:
draft executive status
material changes since the previous report
proposed RAID updates
overdue actions and dependencies
inconsistencies and missing information
decisions requiring confirmation
questions requiring project-manager judgement
Mark all outputs:
Draft — project-manager review required
A simple acceptance-test template
Do not test the agent with a perfect project update. Give it information that contains the kinds of problems a project manager regularly encounters.
Create a fictional project with:
Project context
project objective
current reported status
major milestones
reporting period
workstreams and owners
Previous approved report
Include:
the previous RAG status
progress claims
milestone expectations
known risks or dependencies
Current workstream updates
Include at least:
one milestone under pressure
one incomplete update
one dependency without an accepted commitment
one risk with a weak mitigation
one discussion incorrectly presented as a possible decision
one contradiction between the plan and a workstream update
one missing owner or due date
one optimistic status claim
Test instruction
Ask the agent to:
prepare a draft status summary
compare current and previous positions
recommend draft RAID changes
identify contradictions and missing evidence
list unconfirmed dependencies
distinguish discussions from approved decisions
prepare prioritised questions for the project manager
Tell it not to accept the current RAG status automatically.
Expected behaviours
The agent should:
challenge unsupported status
identify milestone and dependency concerns
question weak mitigations
avoid inventing missing information
distinguish proposals from approved decisions
preserve human approval
prioritise material questions
keep the output concise and traceable
Failure conditions
The agent has failed the test if it:
repeats the reported status without challenge
invents an owner, date or mitigation
records a discussion as an approved decision
updates the RAID log as though it were final
hides uncertainty in polished language
produces so much information that the material concerns are difficult to find
About Steven Gabris
Steven Gabris is a senior enterprise delivery and transformation leader with experience across financial services, payments, consulting and regulated environments.
He has led complex programs, delivery functions and operating-model improvements across organisations including Australian Payments Plus, BNY, PALO IT, Westpac, Commonwealth Bank and the Reserve Bank of Australia.
Steven writes about program delivery, AI-enabled ways of working, PMOs, governance and enterprise transformation. His focus is practical: how organisations can improve delivery confidence, strengthen decision-making and use AI without removing human judgement or accountability.
About Gabris Group
Gabris Group helps organisations align strategy, operations and execution.
Its work focuses on:
enterprise delivery and governance
program and portfolio improvement
PMO and operating-model design
AI-supported delivery practices
leadership and capability development
transformation in financial services and regulated industries
Gabris Group works with leaders who need greater clarity, stronger delivery discipline and practical support turning strategic priorities into measurable outcomes.
Learn more at gabrisgroup.com.
Comments