Is Your PM Toolset Agent-Ready? The AUX Audit for Project Managers
Most enterprise project management tools weren’t designed with AI agents as users. They expose atomic API calls where agents need compound outcomes - and the resulting friction is invisible until you actually try to deploy. Running a simple AUX audit before you build surfaces which integrations will bottleneck your agents, and gives you the right questions to ask vendors.
The bottleneck in most agent workflows isn’t the agent - it’s the tools it’s trying to work with.
A PM deploys agents for programme work - risk triage, status reporting, action tracking. The prompts are good. The agent is capable. But the workflow keeps breaking down at the same point: the agent needs to understand the full project picture before it can do anything useful, and getting that picture requires forty-odd API calls across three systems. By the time it’s assembled the context a human could scan in thirty seconds, the session has timed out or the cost has blown past anything sensible.
We’ve spent the last few years evaluating software for how well it works for people - how intuitive the interface is, how clean the dashboards look, whether the mobile app is any good. None of that matters to an agent. An agent needs something different: it needs to be able to get a complete outcome in a single well-scoped request, not chain together dozens of low-level operations just to find out what state the project is in.
This is what Dharmesh Shah calls Agentic User Experience, or AUX. The idea is straightforward: agents are now users of our software, and software that wasn’t designed for them will create friction that makes agent workflows slow, expensive, or simply unworkable.
The Core Problem - Atomic Calls vs. Compound Outcomes
Traditional software APIs were designed for developers building applications. They expose granular, atomic operations: create a record, update a field, retrieve a specific item. That design works well for programmatic interfaces. It works badly for agents.
An agent trying to assess project health doesn’t want to know the value of a single field. It needs to retrieve the full programme context, compare it against baseline, identify anomalies, and surface a summary - ideally in one request, with enough context loaded to make the response meaningful. When the tools only offer atomic operations, the agent has to chain dozens of them together, introduce state management between steps, and handle failures at each point in the chain.
The result: workflows that should take seconds take minutes. Workflows that should cost cents cost dollars. And workflows that should be reliable break unpredictably because there are forty places where something can go wrong.
Four Criteria for AUX Readiness
Before deploying agents into a workflow, it’s worth running a quick readiness check against four criteria. They don’t require technical expertise to assess - you need to understand what the agent will be doing and what the tool needs to support it.
Outcome-level abstractions. Does the tool offer endpoints that deliver whole outcomes - “get programme health summary,” “retrieve all open risks with owners and mitigations” - or does it only expose field-level operations? Tools that only offer the latter will force your agent to assemble context from scratch on every run.
Full-context retrieval in a single call. Can the agent get everything it needs about a project in one request? Or does it need to call multiple endpoints, stitch responses together, and infer relationships that the tool’s data model doesn’t expose directly?
Idempotent writes. If an agent retries a write operation - because of a network failure, a timeout, or an upstream error - will the system handle it gracefully, or will it create duplicate records, double-posted updates, or conflicting state? Agents encounter more retry scenarios than human users do; tools that don’t handle idempotency gracefully will corrupt your data.
Reliable event streams. Can the tool notify the agent when something relevant changes - a risk status update, a new action item, a milestone slip - without requiring the agent to poll constantly? Polling is expensive and brittle; event streams are how agents become genuinely reactive rather than running on a fixed schedule regardless of whether anything’s changed.
Running the Audit
You don’t need to score every tool in your stack at once. The useful starting point is the tools your agents will actually interact with - typically your project management platform, your document environment, your communication tools, and your reporting layer.
For each tool, work through the four criteria. Not as a formal scoring exercise - just as a structured way to surface the friction before you’ve built the workflow and discovered it the hard way.
What you’ll typically find: the tools your team uses every day for human work have wildly variable AUX readiness. Some have invested seriously in agent-friendly APIs because their enterprise customers are demanding it. Others are still exposing the same granular endpoints they shipped five years ago, with an MCP wrapper bolted on top.
MCP claims deserve scrutiny. A lot of tools are now claiming “agent-ready” status because they’ve published an MCP connector. That’s not the same thing. MCP makes the tool accessible to agents. It doesn’t change the underlying data model or the granularity of the operations the tool supports. An MCP connector over a poorly designed API is still a poorly designed API - the agent can reach it, but the work of assembling compound outcomes still falls to the agent rather than the tool.
What to Do With the Results
The audit gives you three decisions to make.
The first is about data retrieval. If a tool scores poorly on full-context retrieval or outcome-level abstractions, ask how you can get the data you need in the most efficient way possible. Can you pre-load context into the agent’s session? Can you cache a programme snapshot so the agent isn’t rebuilding it from scratch on every run? The goal is to reduce the number of calls required to get the agent to a working state - because every unnecessary call is latency, cost, and a point of failure.
The second is about the tool itself. If the retrieval problem can’t be engineered around, the question becomes whether the tool can be improved or whether there’s a better alternative. Some vendors are moving fast on agent-friendly APIs - and they’re far more likely to prioritise improvements if their customers are asking pointed questions. An AUX audit gives you the specifics: “Your risk endpoint requires fourteen calls to assemble a programme-level risk summary. When can we expect an outcome-level endpoint?” That’s a more productive procurement conversation than “when will you support AI agents?” - which almost every vendor will answer with “we already do.” If the vendor roadmap doesn’t have a credible answer, that’s useful data too.
The third is about data architecture - which is really an extension of the first. Even if a single tool can’t deliver what the agent needs in one call, can you bring the data together reliably from multiple sources? A well-designed data layer - a project context store, a shared state object, a middleware layer that aggregates across tools - can compensate for poor AUX in individual tools. The risk is that you’re now maintaining that layer yourself. The teams that get this right treat it as infrastructure, not a workaround.
The teams that will get the most out of agent-augmented delivery in the next few years won’t necessarily be the ones with the best agents. They’ll be the ones who ran the audit, knew which tools were actually ready, and built their workflows accordingly.
Frequently Asked Questions
What does “agent-ready” mean for project management tools? A project management tool is agent-ready when it can deliver whole outcomes - full programme context, risk summaries, action logs - in a single API call rather than forcing an agent to chain dozens of low-level operations. MCP support alone doesn’t make a tool agent-ready; the underlying data model has to support compound outcomes.
What is AUX and why does it matter for PMs? AUX stands for Agentic User Experience - the idea that AI agents are now users of software, not just humans. A tool with poor AUX requires agents to make many more calls to accomplish the same task, making agent workflows slower, more expensive, and more likely to fail. PMs deploying agents into delivery workflows need to assess AUX readiness before building, not after.
What is an idempotent write and why do agents need it? Agents retry operations far more often than humans do - network failures, timeouts, and upstream errors are all common triggers. An idempotent write is one that produces the same result whether it runs once or ten times. If a tool doesn’t handle retries gracefully, agents will create duplicate records or corrupt data. It’s a basic infrastructure requirement that many PM tools simply haven’t addressed yet.
How do I start an AUX audit on my current tools? Start with the three or four tools your planned agent workflows will actually touch - typically your project management platform, document environment, communication tools, and reporting layer. For each, run through the four criteria: outcome-level abstractions, full-context retrieval in a single call, idempotent writes, and reliable event streams. You don’t need technical expertise to assess most of these - you need to understand what the agent will be doing and whether the tool can support it cleanly.
Which tool in your current stack is creating the most friction for agent workflows - and have you told the vendor?
Yes, AI helped me to write this :)