.png)
In brief: Agentic AI mostly fails in rollout, not in technology. McKinsey's first-year lessons converge on one idea: an agent behaves like a new hire, not a piece of software — it needs a job description, evaluation, expert supervision, and a trustworthy interface. The human role shrinks in headcount but shifts to oversight, training, and sign-off rather than disappearing.
By 2026, plenty of companies had dived into agentic AI, and those who made it to production are now confronting the unpleasant part: the agent that was impressive in the demo stumbles in real work, colleagues avoid it, and the return on investment is slow to come. This isn't an isolated phenomenon. Gartner estimates that more than 40% of agentic AI projects will be scrapped by the end of 2027 — and typically not because the technology is bad, but because implementation gets stuck.
That's exactly what one McKinsey piece is about, summing up the lessons of agentic AI's first year, drawn from more than fifty of its own agent builds and a dozen-odd market projects. Most of the six lessons organize themselves around a single insight: an agent isn't software, it's labor. Anyone who treats it as software runs straight into the very walls that most disillusioned executives are talking about in 2026. The points below illuminate that insight — and, at the same time, why choosing the right process isn't enough: the hard part begins when the agent goes to work.
According to McKinsey, one of the most common pitfalls is that the agent is convincing in the demo, but in production it starts producing low-quality, inaccurate output. Users have a term for this: "AI slop." And the consequence isn't technical but human: colleagues lose their trust, few use it, and the efficiency gained through automation is eaten up by the drop in quality and the loss of trust.
This point is easy to underestimate. In many cases the biggest obstacle to adoption isn't the model's capability, but the moment the employee realizes that they'll have to check the agent's output line by line anyway. From there they tend to return to manual work, and the project works on paper but is dead in practice.
If the agent is labor, then its development has to be handled that way too. As one interviewed executive put it, bringing an agent online resembles hiring a new colleague more than installing software. No new hire performs well on day one either: they get a job description, training, and continuous feedback until they settle in. According to the piece, an agent should be treated the same way — and this has three practical consequences.
The first is that the agent needs a precise "job description": it isn't enough to say what it should do; you have to write down what good output is and what bad output is, in as much detail as it takes to separate the best human performer from the rest.
The second is that evaluation (in McKinsey's terminology, "evals") isn't optional, and there's no "launch it and leave it alone." The piece offers a global banking example: whenever the agent's compliance recommendation diverged from the human decision, the team located the logical gap, refined the criteria, and re-ran the tests. This is continuous performance evaluation, just as with a human team.
The third is that you can't take the expert out of the process. Evaluation can't be left to a generic metric; the domain's human expert has to continuously judge what good output is and what bad output is — sometimes across thousands of cases. So the best people's time isn't freed up immediately; instead it shifts to training and checking the agent.
One of the piece's most instructive examples isn't about the model but about the user interface. A property and casualty insurer built visual elements alongside the summaries the agent produced — elements that, with one click, scroll to the relevant page of the source document and highlight the relevant text. The result was nearly 95% user acceptance.
The lesson is that people generally aren't hostile to the agent; they just aren't willing to spend long minutes searching for support for a decision they'll ultimately have to approve in their own name. From this angle the interface isn't cosmetics but a precondition of trust: if the agent shows where it drew its conclusion from, the person signs off; if it doesn't, they're forced to verify, and the efficiency evaporates.
At one point the piece goes against its own genre, and this is worth highlighting: an agent isn't always the right tool. Many business problems can be solved more reliably in a simpler way — with rule-based automation, predictive analytics, or a plain LLM prompt. Into well-standardized, low-variance processes, such as investor onboarding or regulatory reporting, an agent introduces uncertainty rather than value.
This chimes with what the analyses on task selection say too, only McKinsey puts it a notch more bluntly. The right question isn't whether an agent can be built, but which tool solves the given job best: sometimes an agent, sometimes a simpler solution, and often human and machine together.
The closing lesson is the least catchy, yet it's the one that speaks most to executives. Agents do a lot, but the human remains an essential part of the labor equation: someone has to oversee accuracy, ensure compliance, handle exceptions, and at the end sign off on the decision under their own responsibility. In McKinsey's legal example, the agent organizes the claims and the amounts, but the lawyer has to approve it, because it's their authorization and their liability that cover the decision.
Headcount, meanwhile, changes — typically decreasing in a transformed process — but the role doesn't disappear; it relocates: from execution to oversight, training, and evaluation. According to the piece, anyone who doesn't manage this transition deliberately risks quiet failures, accumulating errors, and user rejection even with the most advanced agent program.
McKinsey's main message is that, in practice, adopting agentic AI is organizational development more than an IT project. The technology is the easier half; the harder half is training the agent, measuring it, fitting it into the workflow, and giving it an interface that colleagues dare to trust.
The demo is about what the model is capable of. Production is about whether people accept it. According to the piece's experience, the gap between the two isn't filled by more technology, but by more attention to the way the agent is put to work.
.png)
.png)