"Lol, why would an AI agent even need a project management tool? It just takes a task and does it!" \u2014 dozens of people wrote me this.<\/p>\n
That reaction is based on a narrower definition of project management than the one I mean here.<\/p>\n
<\/p>\n
People brought up Jira, Trello, Linear, GitHub Issues. All of these start working only after a task is already defined \u2014 somewhere in the second half of project management.<\/p>\n
Nobody thought about stakeholder management. About gathering requirements and surfacing contradictions. About aligning different priority scales when multiple organizations are involved. About estimation and resource planning, about resolving conflicts in goal-setting, about budgeting and risk management. About the mundane act of scheduling a call with decision-makers.<\/p>\n
These are project tasks too, right? Shouldn't the agent handle them?<\/p>\n
If we're talking about software delivery management beyond task execution through AI, the agent needs to run stakeholder management, make sure decision-makers agree on goals, constraints, and priorities, schedule meetings when unresolved decisions block progress, discuss risk mitigation, curate annual and quarterly portfolio planning, and work with prioritization and organizational dependencies.<\/p>\n
Project management also includes choosing, defining, prioritizing, and de-risking work before it becomes a ticket. It starts with deciding which projects your organization will run over the next year \u2014 accounting for the interests of all VIP customers and the capacity of your contractors.<\/p>\n
How would an agent work here? With what tools? Most responses I saw did not address this layer.<\/p>\n
For most people, tasks fall from the sky, and all project work begins the moment one lands on your head. Some even tried to convince me that this is<\/em> what management is about \u2014 efficiently redistributing whatever arrives in the backlog.<\/p>\n The problem is we've all grown too accustomed to thinking in an execution context. We hand the agent a task, it executes the given instruction. But where do these tasks come from? Why these particular ones? Who decided? How do they connect to the strategic direction of your organization? And what happens when so many tasks arrive that the agent physically can't code them all \u2014 and you're forced to choose which ones go to work and which don't? Humans still do all of this.<\/p>\n This is where AI advocates start stumbling. "Well, that's a business problem. Let the business somehow \u2014 outside the agent\u2019s workflow \u2014 figure out priorities, agree among themselves, align a dozen stakeholders and budgets, and tell us what to do. Then we'll happily hand it to the agent."<\/p>\n That assumption is the problem. This is the same old "garbage in, garbage out" trap, applied to AI-agent workflows. Teams that ignore upstream decision-making will automate only the easiest part of delivery. As long as you think "someone will give me a task, and I'll shove it into Obsidian, Linear, Plane, Jira, whatever, and blast out a result" \u2014 you're losing.<\/p>\n Look at the work before a ticket exists. Handing a defined task to an agent is the easier part. The harder and more valuable work is upstream, where you need to align a dozen opinionated, living stakeholders with limited budgets and limited horizons. Just understanding what the aggregate result looks like in the eyes of that crowd is a project in itself.<\/p>\n Scheduling a meeting with a clear agenda is a project task. Gathering requirements from decision-makers is a project task. Gathering<\/em> doesn't mean parsing a ready-made spreadsheet with Claude, by the way. It means surfacing inconsistencies between two key stakeholders, organizing a meeting, running it while cross-referencing budgets and strategy in real time, then formulating and communicating the final decision. Those are separate project-management actions, not a single parsing step.<\/p>\n Does your agent do that?<\/p>\n That's exactly where the agent should be working effectively. Where it should assist you \u2014 and do the work for you. Where there are no tickets or tasks yet, just a dozen murky stakeholders \u2014 people! \u2014 each with their own quirks, ambitions, and commitments. That is still an under-served area for AI tooling. That is where teams still spend significant manual effort.<\/p>\n Executing the tasks afterward \u2014 bolting Jira MCP onto Claude \u2014 that is already comparatively easy to prototype.<\/p>\n I tested this in live delivery work. I built this \u2014 specifically for the first half of project management, the part where tickets don't exist yet.<\/p>\n End-to-end tracking from the very first pre-sales conversation. The system knows each participant's role and their legitimacy to make statements \u2014 and weighs fact credibility accordingly. A financial manager's statement about finances carries high credibility; the same statement from a layout designer or QA carries low credibility. That lets the system distinguish source credibility during requirements work.<\/p>\n Requirements gathering means surfacing contradictions between decision-makers. A contradiction detector flags discrepancies between sources instead of silently overwriting with the latest entry. Two versions of a SOW with different contract end dates \u2014 caught before signing. A client was promised a solution for X, but the estimate came out at 2X \u2014 surfaced early, before the document goes to the client. Potential scope creep is flagged when promised outcomes and estimated effort diverge.<\/p>\n Organizing a meeting at the right moment is also a project task, and the system handles it. Three open questions unanswered for 30+ days \u2014 flagged before the next meeting so the manager shows up prepared.<\/p>\n This has been running for about two months across two live projects simultaneously. The core is Claude with skills plus a couple of scripts. Almost no code. And it's deployed in a mature enterprise organization, where I was the first to embed AI not into code but into the management loop \u2014 requirements, task definition, cross-team alignment \u2014 from the very start of the delivery role.<\/p>\n AI-assisted execution is already crowded and improving quickly. Relying on AI failure as a long-term moat for programmers is risky. It is not a strategy I would rely on.<\/p>\n So while fools debate whether AI can code at all and which model is best for it \u2014 look at the less-automated parts of delivery management. In planning, in uncovering unstated requirements and conflicting priorities, in analyzing ambitions and emotions, in aligning people, in estimation and prioritization, in surfacing organizational dependencies.<\/p>\n This hasn't become commodity yet. It isn't solved by a couple of Claude skills. Though Claude and similar tools are moving toward this space, so it is worth evaluating how these tools fit upstream project work.<\/p>\n This is NOT solved by connecting Jira or Linear via MCP. The missing capabilities are broader than issue-tracker integration \u2014 relationship building, expectation management, risk and budget handling, estimating expected economic impact, the lifecycle of hypotheses, alignment and conflict resolution between people. And then two-way translation into execution and acceptance. I have not seen a ready-made tool that combines these functions well.<\/p>\n Basic execution assistance is becoming commoditized. The less saturated opportunity is upstream project management \u2014 where stakeholder alignment, cross-organization prioritization, and demand shaping still require manual work. That is where an AI agent could provide more leverage than in simple ticket execution.<\/p>\n That is why an AI agent needs project-management context before tasks become tickets.<\/p>\n","protected":false},"excerpt":{"rendered":" Everyone who answered me showed tools that start after the task is already defined. The real work \u2014 and the real money \u2014 is everything that happens before a single ticket exists.<\/p>\n","protected":false},"author":0,"featured_media":122,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-123","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tThe value is where no ticket exists yet<\/h2>\n
This already works. I built it.<\/h2>\n
While most debate focuses on code generation<\/h2>\n