Mapping the agentic task ecosystem

An agent is only as interesting as the things it can reach. On its own it is a model with a plan and no hands. Connected to a ticketing system, a repository and a calendar, it becomes something that can change how a team's week goes.

So when we set out to understand where agents were landing in real organisations, we did not start with occupations. We started with connections.

Why the connection layer is the right unit

Occupation-level analysis assumes the job is the boundary. In practice the boundary is the integration. Two people with identical job titles in different companies have entirely different exposure to agents, because one of them works in a system an agent can reach and the other does not.

Looking at connections instead of titles changes the questions. Not "is this role automatable" but "what is actually wired up, and what does that let an agent attempt".

What the distribution looks like

Three patterns showed up consistently.

The first is concentration. A small number of connection types account for most of what agents are given access to: version control, issue trackers, documentation stores, calendars and internal search. Everything else is a long tail.

The second is asymmetry between reading and writing. Agents are granted read access almost casually and write access very reluctantly, which is sensible and also explains why so much agent value shows up as preparation rather than completion.

The third is the gap between what is connected and what is used. A large share of available tools are never invoked by the agents that carry them, while still occupying context on every single call. That is a cost with no corresponding benefit, and it is invisible unless someone measures per-tool invocation.

The implication nobody likes

If the useful surface is concentrated in a handful of systems, then most of the value of agent adoption is available to organisations that do the unglamorous work of making those systems accessible and governable. Not the ones with the best model access.

This is an uncomfortable conclusion for a market that prefers capability stories. It is also consistent with what we see in deployments: the differentiator is rarely the model.

What we did with the finding

Two things went straight into the product. Tool trimming in the Optimizer came directly from the unused-tool observation: if a tool is never invoked, its definition is pure overhead on every call, and removing it is a measurable saving with no quality cost. The per-tool invocation reporting exists so that decision can be made from data rather than intuition.

The second was governance shaped by the read-write asymmetry. Policy enforced at the moment of action means the boundary between reading and writing is not a matter of prompt discipline. An agent permitted to read a repository and not to push cannot push, whatever its plan says.

What we are not claiming

This is a map of connections, not a forecast of employment. It says where agents can currently reach, which changes as integrations change. It does not say what proportion of anyone's job will exist in five years, and we would treat any document that does with suspicion, including our own if we wrote one.

Next

The Future of Work pages cover the wider programme this belongs to. The Agent Orchestration System pages cover the governance and optimisation layers that came out of it.