We’re adding AI agents to project teams, but still managing project status with tools designed for human self-reporting.
A few years ago, I managed a large ERP implementation with significant custom development layered on top of the platform. We had dozens of developers and a separate group of business SMEs defining requirements. The problem wasn’t a lack of process. It was fragmentation.
Requirements lived in one system. Development status lived somewhere else. Risks, issues, decisions, testing, and schedule information were tracked in other places. Each source could be reasonably accurate on its own while the overall picture was wrong.
We missed deadlines I should have seen coming earlier. I remember situations where a requirement appeared to be progressing normally while the development work behind it had already encountered a blocker. The evidence existed. It just wasn’t connected to the project information I was using to make decisions.
That experience has shaped how I’ve been thinking about the AI-native project operating system I’m building. Two ideas are central to it.
First, the delivery team now includes more than people. AI agents can draft requirements, analyze meeting transcripts, write code, identify emerging risks, prepare documentation, and perform other project work. That work needs to be visible in the same operating model as human work.
That doesn’t mean an AI agent has the same accountability as a person. Human owners still remain accountable for outcomes. But agent assignments, activity, outputs, dependencies, and constraints shouldn’t disappear into a separate AI layer that the project manager can’t see. Otherwise, we’ve simply recreated the same information fragmentation with a new type of contributor.
Second, project status should increasingly be derived from evidence rather than manually reported. On many projects, we ask people to perform the work and then separately ask them to describe the state of that work in Jira, spreadsheets, status reports, RAID logs, and meetings. Those two versions of reality inevitably drift apart.
The alternative is to derive more of the project picture from the evidence the work already creates. A Git commit or pull request can provide evidence of development activity. Test results can provide evidence of quality. Meeting transcripts can surface decisions and risks. Requirement changes can expose scope movement. Deployment records can confirm that something actually reached an environment.
None of those signals alone tells you whether a project is on track. Together, however, they can give AI enough evidence to draft a much more current picture of the project for a human to evaluate.
That’s an important distinction. AI shouldn’t decide that a risk is accepted, approve a scope change, or declare a milestone complete simply because it found supporting signals. People still make those decisions. The AI’s job is to connect the evidence, identify inconsistencies, and surface what deserves attention.
If I had had that capability on the JDE program, it wouldn’t have magically made the project more successful. But there’s a good chance I would have seen some of those blockers weeks earlier.
And in project management, sometimes seeing the problem three weeks earlier is the difference between managing a risk and explaining a miss.
← Back to Articles