In 2025, an article in MIT Sloan Management Review raised a point most companies don't want to hear: putting AI on a single, isolated task — summarizing a document, drafting an email, generating a snippet of code — rarely moves the needle for the business. The real gain shows up when someone stops, looks at the whole process, and asks why that task exists the way it does. A financial services company cited in the article rebuilt its customer order process this way and reached 50% less effort, 40% lower cost, and nearly 20% less turnover on the team — numbers no isolated automation delivers on its own.
McKinsey's State of AI 2025 research measured the same gap at scale: among nearly 2,000 companies surveyed, only 5.5% reported real financial return from their AI investment. What separates that small group from everyone else isn't the AI model in use, or the budget — it's that top performers are nearly three times more likely to have fundamentally redesigned their workflow, instead of simply plugging AI into a step of the old process.
For companies in Brazil and Latin America, many of which are still testing AI on isolated tasks — a customer-service chatbot here, a contract summary there — this finding lands as a specific warning. The pattern repeats department by department: support tests one tool, finance tests another, and each solves one isolated task inside its own silo. Every team shows a small win in an internal meeting, but by the end of the quarter no one can point to how much of it actually moved the number leadership tracks.
Why the isolated task pays off so little
The temptation to automate task by task is understandable: it's fast to test, it doesn't require touching anything beyond that one step, and it delivers a visible win within weeks. The problem is that an isolated task usually sits inside a process designed for a different reality — a workflow built when every step depended on a person, complete with queues, redundant approvals, and rework baked in as part of "the way it's always been done."
Putting AI on one step of that process makes the step faster. It does not make the process better. If the next step still requires someone to double-check everything because they don't trust the previous one, or if the automated task never should have existed as a separate step in the first place, the company has simply learned to produce the same rework faster than before.
A common example makes this concrete. Many companies put an AI agent to work summarizing emails or support tickets, but leave the next step untouched: a person reads the summary, doesn't quite trust it, and goes to check the original text anyway. The summary got faster to produce; the decision still takes the same amount of time it always did, because the step that actually slowed the process down — the decision-maker's distrust — was never addressed.
McKinsey calls this pattern incrementalism: AI disappears inside the existing process and delivers only marginal gains, when the process itself is what needed to change. It's the difference between putting a stronger engine in a car with the handbrake on and simply releasing the handbrake.
When automating the task makes things worse
A field experiment run by Harvard Business School with the consulting firm Boston Consulting Group made this risk concrete. Researchers split 758 consultants into groups with and without access to an AI model and measured performance on real tasks from the consultants' actual work.
On tasks inside what the researchers called the AI's "frontier" — what it's actually good at — consultants using AI completed 12.2% more tasks, 25.1% faster, with quality rated up to 40% higher. Outside that frontier, on a task deliberately designed to sit beyond the model's real capability, the group using AI performed worse: trusting the wrong answer, they reached the correct solution 19 percentage points less often than the group working without AI.
The point of the study isn't that AI is good or bad. It's that the frontier between what it handles well and what it handles poorly is jagged, and it only becomes visible once someone maps the task inside the process — not when the task is automated in isolation, on the assumption that "AI will handle it."
For a company, the practical lesson isn't to avoid AI on tasks outside that frontier. It's to not trust it blindly there, and instead use the very same task as a thermometer: if the outcome gets worse with AI, that step still needs an experienced person nearby — and that information only surfaces when the whole process is examined, not when the tool is approved in isolation "to help everyone."
What has to be in place
Redesigning a process around AI, in practice, means putting a few mechanisms in place before any step becomes automatic.
Map the process before automating any step of it. That means listing every step, who does it, why it exists, and what would happen if it disappeared — before asking where AI fits in. Many "automatable" steps shouldn't exist as a separate step at all.
Agents working in coordinated steps, not in isolation. One agent summarizes, another checks history, another drafts the response — each with a defined scope, handing work forward, instead of one person manually stitching together the output of several disconnected tools.
Human approval based on the risk of each step, not on every step. A task inside the safe part of the process moves straight through; a sensitive decision pauses in the conversation and asks for confirmation before continuing.
Reuse of what already works, with control over who can use what. When someone on the team finds the right approach for a process, that approach becomes available to the whole team, with reach defined by role and permission — not left open to anyone.
This is how Skyller was designed: agents working in coordinated steps, approval based on risk, and more than 170 ready-made process templates to start the redesign without building from zero.
The gain shows up in the outcome, not just the task
The reason this redesign is a harder call to make than simply turning on another tool is the same reason it pays off: it changes how work is split between people and AI, not which button gets clicked.
When the process is redesigned, the gain shows up in the metrics leadership already tracks — cycle time, cost per interaction, team turnover — not just in how many people used a chatbot that month. That's the exact difference, according to McKinsey, between the 5.5% of companies with real financial return and everyone else: they measure the process, not the tool.
There's also a less-discussed internal effect: when the redesign happens with the team, rather than being decided over their heads, AI shows up as something that removes repetitive work from the path — not as a threat to someone's job. That helps explain why the case cited by MIT Sloan also cut turnover, not just cost: the team stops repeating the part of the work nobody liked doing, and starts deciding the part that actually required someone thinking it through.
Questions to bring to the next meeting
Before approving one more point automation, it's worth bringing these questions to whoever leads the area and to the IT team:
- Why does this step exist the way it does? If the answer is "it's always been this way," it's a candidate for elimination, not automation.
- What happens at the next step once this one gets faster? If the next step still re-checks everything from scratch, the speed gain never reaches the whole process.
- Is this task inside or outside what AI actually handles well today? Testing before trusting avoids the worse outcome the Harvard/BCG study measured outside the frontier.
- Who on the team has already solved a similar problem, and is that knowledge available to everyone else? If the answer is "only in one person's head," the redesign hasn't happened yet.
