A tool no longer has one type of user
Half the users of our project tracker will never open its UI. Humans, agents and other systems are all users now, and the API surface is the product.
Half the "users" of our project tracker will never open its UI.
Most of our code is already written with Claude Code. Right now we are rebuilding our ways of working from zero for that reality, and one realization is reshaping how we evaluate every tool along the way:
A tool no longer has one type of user.
It has three.
- Humans, working in the UI.
- LLM agents, working through APIs and MCP.
- Other systems, talking through webhooks and events.
If any of the three is second-class, that is exactly where your speed dies.
We are testing this on real work. An agent stood up two competing trackers in a single afternoon: same initiative, the same product brief pulled from our docs, the same nine issues, each one already specified in full. Built entirely through MCP, with zero clicking.
The first finding landed before the actual test even began. In one tool, the agent could build and tear down everything. The other tool's API can create but not delete, so a human cleaned up by hand. Same task, same agent. The only difference was the API surface. When agents are half your workforce, the API surface is the product.
The same logic applies between systems. A branch is pushed, a merge request opens, a deploy completes: the board should already know. Native integrations are highways someone else paves and maintains. Every missing integration puts a human in the middle, and a human copy-pasting between two tools is the slowest API in the company.
The tooling rules we are converging on:
- Pick tools where the integrations are native. Vendor-maintained beats self-maintained almost every time, and the exceptions are what rule 2 is for.
- If you must write glue, own it like production code. The day automation silently stops, people stop trusting the board.
- Write process docs for a reader with zero context. Humans skim them once. Agents read them on every single task.
- If the tool fights the process, change the process. If that keeps happening, change the tool. Never accumulate patches.
The old question for choosing tools was "will my team like it?"
The new one: "can everyone in my org work with it, including the workers that are not people?"
Where this first appeared
Written for LinkedIn and posted there on . Read it on LinkedIn.