The project manager's job when agents do the chasing — the job you were hired for
Thomas Thejn4 min read
When agents chase task owners, verify dependencies and propose the delivery RAG, the project manager's week changes shape. What remains is judgement — is the risk real, is the status honest, what does the sponsor need to decide — and the confirmation step becomes the instrument through which that judgement is exercised, rather than a chore.
Three earlier posts in this series argued that project tools are becoming systems of action, described what TransformRadar's AI does today, and set out where it is going. This one is about the person standing in the middle of all that, holding a coffee: the project manager whose Monday morning is about to change.
The fear is easy to state. If an agent collects the status, checks the dependencies and proposes the RAG, what is the project manager for? The answer, I think, is that the job becomes what it said on the job description, and the parts being automated are the parts nobody mentioned at the interview.
What the job is today, honestly
Ask a programme manager on a large IT transformation how they spend the first half of the week. Collecting. A message to each task owner. A follow-up to the three who did not answer. A third message to the one who answered "yes" without saying yes to what. Checking whether the thing reported as done actually landed. Reconciling the plan against the board. Typing the RAG from what came back. Then building the pack from the result.
That is not project management. It is data entry with a lanyard. The judgement — is this slip a problem, is this risk real, what should the sponsor decide — gets whatever time is left, which is Thursday, after four.
What the agent takes
The status orchestration we are building takes the collecting. It asks each owner for an update on the items due, in the channel they already use. It checks the answers against the plan and the backlog: a task reported done whose successor has not started, a dependency claimed complete that the board shows still in review. It proposes the RAG with the evidence attached, and it does not get tired of asking the person who never answers.
The root-cause tracing takes the reconstruction. When a Programme Health dimension drops, the agent links it to the slipped tasks, the unowned risk, the amber benefit, and assembles the narrative before the meeting rather than leaving the committee to do archaeology in the room.
Both arrive as proposals. Neither is applied until the project manager says so.
What stays human
Four things, and they were always the actual job.
Is it true? The agent proposes a RAG from the evidence it gathered. The project manager knows that the team lead who reported "on track" always does, and that "complete" from the integration team means "complete apart from the integration". The confirmation step is where that knowledge enters the record. An agent that skipped it would be recording the reported truth, which is a different thing from the truth.
Is it a problem? A slipped task is a fact. Whether it matters depends on the gate it threatens, the sponsor's tolerance, and what else is happening this month. That is a judgement about the programme, not about the data, and it is why the pack goes out with a person's name on it.
What should the sponsor decide? Governance is the art of bringing the right decision to the right person at the right moment with the evidence attached. The agent can attach the evidence. Choosing the moment, and the framing, is the craft. Nobody has automated the art of knowing that the sponsor is in a better mood after lunch.
What is not being said? The most important signal on any programme is the thing nobody has written down. An agent grounded in the record will tell you, correctly, that it can find no cause for a health drop. Knowing whose door to knock on is the job, and it always was.
The confirmation step as an instrument
It is tempting to see the confirmation step as friction, the thing that stops the agent being properly autonomous. I think that is backwards. The confirmation step is the point at which the project manager's judgement is applied to the agent's proposal, and it is the only point at which it needs to be. Everything before it is preparation. Everything after it is consequence.
Designed well, it is fast — a proposal with the evidence beside it, one action to accept, edit or reject — and it is the most valuable thirty seconds in the week, because it is the thirty seconds in which the record becomes true. A project manager who spends Monday confirming ten well-evidenced proposals and the rest of the week on the four things above is doing the job as it should have been done all along. They may even make it to Thursday lunch.
What this means for the PMO
For a PMO head or a CIO, the shift changes what a project manager is for and therefore who you hire. The premium moves from diligence in collection to judgement in confirmation: people who know when a green is a nervous green, and who can walk a sponsor to a decision. The tool's job is to make that judgement the whole of the role rather than the remainder of it.
If you want to see the confirmation step as it exists today, start with one project, ask Blip to log a risk, and look at what it puts in front of you before anything is written. Then say no to it, just to feel the power.
- agentic AI
- project management
- PMO
- AI