The pattern everyone falls into
Companies tend to pick their first agent job the same way. Somebody asks what AI could do for us, and the room converges on the work everyone can picture: write our blog posts, answer our customers, handle the inbox. It is the most visible work in the building, so it is the work that comes to mind.
Six months later the pilot is quietly parked and the conclusion is that the technology was not ready. The technology was fine. The job selection was the problem, and visibility is what made it a bad one.
What makes a job easy for an agent
A job is easy for an agent when three things are true. There is a checkable right answer. A bad output is cheap. And somebody in the building already does the job and can tell good from bad on sight.
There is no right answer to "is this blog post good." There is only a preference held by a person who will recognize the wrong version instantly and struggle to specify the right one in advance. That gap is where most quality complaints actually live. A bad internal summary costs somebody four minutes. A bad reply to a customer costs a relationship, and occasionally a compliance conversation. The cost of a failure sets how much supervision the job needs, and supervision is the expensive part of running agents.
And the visible jobs usually fail the third test in a way nobody notices until late. The person who would judge the output is a senior person whose attention is the scarcest thing in the company. Handing them a review queue involves moving work onto your most expensive calendar.
What actually works
When NTT DATA Group expanded its agent tooling across the organization, the first job they automated was an internal engineering one, not a customer experience one. OpenAI's account of the deployment describes the automation of a complex incident analysis for a critical system, work that had previously required five experienced engineers and taken three days, completed in 30 minutes. That result, the write-up says, quickly gained attention from senior leaders and became an early proof point.
Look at the shape of that job rather than the impressive time saving. The task had a checkable answer: did the agent find the right root cause and pull the right signals from the right systems? A bad output was cheap: a wrong incident analysis gets reviewed, not shipped to a customer. And the people who would judge the output were the same engineers who had been doing the job. They had the context to evaluate quality on sight, and they were the right people to spend an hour reviewing a draft.
The pattern is the same in every successful enterprise agent deployment I have seen. The first job is internal. The output is checked by the same person who used to do the job manually. The cost of a bad result is bounded, and the win is auditable.
The visibility trap, in one sentence
The most visible work in your company is the worst first agent job because the cost of failure is the highest, the standard of quality is the most contested, and the reviewer's time is the most expensive.
The progression that follows
Once an internal job is automated, the next step is rarely the customer-facing one. It is the second internal job. The team that built the first agent now has both the technical infrastructure and the organizational trust to do the second deployment faster and with less hand-wringing. Over time, the surface area of what the agent owns expands inward from low-stakes internal work to higher-stakes internal work, until the cost of failure has been calibrated by a series of real incidents the team knows how to handle.
The mistake is inverting that order. When teams jump straight to the visible job, the first failure is also the most expensive one, and the recovery costs compound. A bad blog post is forgotten in a week. A bad customer reply that gets screenshotted into a tweetstorm is a six-month brand project. The visible jobs are the ones where the cost of being wrong is highest and the standard of being right is most contested. They are the right jobs to automate last, not first.
What the bias toward visibility costs
There is a deeper reason teams reach for the visible work first. It is the work leadership can picture. It is the work that shows up in a board deck. It is the work that justifies the AI initiative in the next budget cycle. The pressure to produce visible wins is real, and it pushes teams toward the worst first jobs.
The honest move is to keep the visible wins for later, after a few internal jobs have produced the technical and organizational capacity to handle them. The internal wins will be less photogenic, and the board will not get to see a customer-facing demo in the first quarter. They will get a 30-minute incident analysis that used to take three days, and that is the proof point that justifies the next round of investment.