Why project management tools are the substrate for agentic AI
By Ismail El Houcheimi
Most demonstrations of agentic AI are impressive for about ninety seconds. An agent takes an instruction, decomposes it, calls some tools, and produces something plausible. Then you try to use it on real work and it falls apart, not because the model reasoned badly, but because it was reasoning about almost nothing. It knew what you typed into a box. It did not know what your team had already committed to, how this piece of work related to anything else, who owned the outcome, or what was already blocked.
I have come to think this is the central constraint, and that it is a data problem rather than a model problem. Agents fail in production for the same reason a brilliant new hire fails in their first week: not incapability, but absence of context. Which leads somewhere non-obvious about where useful agents will actually live.
Three things an agent needs before it can act
An agent that does more than generate text needs three distinct kinds of context. They are easy to conflate and they fail in different ways.
Intent: what are we trying to do?
Not the immediate instruction, but the goal it serves. Without intent an agent optimizes the literal request and misses the point: it will happily produce a beautifully formatted document nobody needed, because nothing told it what the work was for.
Structure: how does this decompose?
How work breaks into steps, what depends on what, what constitutes done. Without structure an agent cannot sequence anything. It treats a twelve-step project as one undifferentiated instruction and produces a single lump of output.
Accountability: who owns this?
Which human is responsible, who needs to review, who is waiting. Without accountability an agent cannot hand off, cannot escalate, and cannot know when to stop and ask. This is the ingredient most often missing, and its absence is why so many agent demos end with output that goes nowhere.
Notice that a chat interface supplies none of these durably. It has whatever is in the current conversation. Every session starts over. You can paste context in, and people do, but pasting context is the work you were trying to avoid.
The execution graph
Project management tools already hold all three ingredients, and they hold them as a connected structure rather than a pile of documents. Tasks carry owners and states. Projects carry goals and deadlines. Dependencies carry sequence. Comments carry the decisions and the reasoning behind them. Taken together this is something more useful than a database of tickets; it is a record of how a team actually decides and executes.
The useful framing is that this data is a graph, not a list. A list of tasks tells you what exists. A graph tells you that this task blocks that one, that both serve a goal with a date, that the person who owns the blocker is out this week, and that a decision three weeks ago in a comment thread is the reason the approach changed. An agent reasoning over the graph can answer questions no amount of prompt engineering will extract from a list.
What this actually unlocks
Concretely, having intent, structure, and accountability in one place makes a class of automation possible that is otherwise out of reach.
- Triage that accounts for reality. Assigning incoming work based on who actually has bandwidth and the relevant skills, rather than round-robin or whoever answers first. This requires knowing current load, which requires the graph.
- Scoped agents that finish something. An agent asked to draft a project breakdown, research a competitor, or produce a status update can do so without hand-holding, because the scope and the definition of done are already recorded rather than described in a prompt.
- Detecting drift instead of reporting it. Surfacing that a project has had no activity in three weeks while its deadline stayed fixed is a question about the graph over time. No one has to notice and raise it.
- Cross-referencing commitments against records. Finding the promise made in a meeting note that never became a task is trivial with both in one system and nearly impossible with them in two.
What these have in common is that the hard part is breadth of context, not depth of reasoning. That is exactly the shape of problem where this approach wins, and it is worth being precise about the boundary: none of these examples asks the agent to decide what matters. They ask it to see across more than a person can hold at once, and to surface what it finds, the same division of labour that makes asking an assistant about your workload useful in the first place.
Explainability is the real constraint at scale
Here is where I think most of this will succeed or fail, and it is not the part that demos well. For a team to let an agent touch real work, the team has to be able to see why it did what it did.
An agent that reassigns a ticket needs to show the load calculation behind the choice. An agent that flags a project as at risk needs to point at the dependency and the date. An agent that proposes a breakdown needs to make clear which parts came from an existing template and which it invented. Without that, the first wrong decision destroys trust permanently, and it will make a wrong decision, because it is operating on incomplete information like everyone else.
This also argues against a particular temptation: letting an agent perform silent bulk changes because it can. Reorganizing a backlog unprompted is technically easy and a trust catastrophe. Proposing the reorganization and letting a human accept it costs one click and keeps the relationship intact.
What this means for the tools themselves
The shift is already visible across the category: Jira, Notion, Linear, and others are all moving in this direction, which is a reasonable signal that the underlying observation is not controversial. What is less settled is what it demands of the products.
- The graph has to be genuinely connected. If tasks live in one system and the decisions behind them live in another, the agent inherits the same fragmentation the team has.
- Context has to include the places work actually happens: documents, chat, code, customer conversations. A project tool that only knows about its own tickets holds a partial graph.
- Reasoning has to be inspectable by default, not exposed behind a debug view nobody opens.
- The interface has to adapt, because teams genuinely do not work the same way, and a rigid workflow forces the graph to record a fiction.
This is the direction we are building Serena AI toward, so treat the enthusiasm accordingly. But the underlying claim stands independent of any product: whoever holds the execution graph is positioned to make agents useful, and whoever does not will be doing prompt engineering against context they never had.
Key takeaways
- Agents need intent, structure, and accountability. A chat window supplies none of them durably.
- Project management tools already hold all three, as a connected execution graph rather than a list.
- The wins come from breadth of context, not depth of reasoning: triage against real load, drift detection, cross-referencing commitments.
- Explainability is the constraint at scale: the first unexplained wrong decision ends the trust permanently.
- Automate where verification is cheap; keep judgment where it is not.
Frequently asked questions
Is this just saying AI belongs in project management software?
It is a claim about where the necessary context lives, not about a product category. If your execution graph lived somewhere else, in a well-instrumented codebase or a CRM that captured decisions, the argument would point there. Project tools happen to be where intent, structure, and accountability already coexist.
Why not give a general-purpose agent access to all our tools instead?
That helps with breadth but not with structure. Read access to ten systems gives an agent ten piles of text; it still has to infer what depends on what and who owns which outcome. The value is in the relationships being recorded rather than reconstructed, and reconstruction is exactly where confident wrong answers come from.
What should an agent never be allowed to do here?
Irreversible bulk changes, and anything where being confidently wrong is expensive and hard to check. Final prioritization is the clearest example: it depends on political weight, stakeholder history, and how real a deadline actually is, none of which is usually written down anywhere the agent can read.
Does this require a large team to be worth anything?
No, but the value scales with fragmentation rather than headcount. A solo operator whose commitments are spread across notes, chat, and a calendar has a real graph worth reasoning over. A ten-person team with everything on one readable board has less for an agent to discover.