The Redeployment Gap: Why AI Savings Vanish

In March this year, a working paper out of the National Bureau of Economic Research put a number on something a lot of founders already felt. Based on the Duke CFO Survey of 750 US companies, the researchers found that 44 percent of finance chiefs plan AI-related job cuts this year, and they estimated roughly 502,000 roles could go to AI in 2026. That is about nine times the 55,000 AI-attributed cuts in 2025. The same paper noted something quieter and more damning: CFOs believe AI is lifting their productivity more than the data actually shows.

Weeks earlier, a senior Goldman Sachs economist had said the bank “still does not find a meaningful relationship between productivity and AI adoption at the economy-wide level.” So here is the picture at the start of October 2026. Companies are cutting half a million jobs on the theory that AI did the work. And at the level where it would show up, the work AI supposedly freed is not turning into measurable output.

I have run four companies, and I have made a version of this mistake myself. The trap is subtle. You assume that when AI takes a task off a person’s plate, you have captured a saving. You have not. You have created capacity. Capacity and savings are not the same thing, and the distance between them is where most of the value leaks out. AI does not save you money. It hands you back hours, and by default you point those hours at nothing. That default is the redeployment gap, and closing it is the actual job.

The savings everyone is counting do not exist yet

Start with the number that is driving the layoffs, because it is built on a quiet assumption. When a CFO signs off on cuts “because of AI,” the mental math is: this tool now does what three people did, so I can remove three salaries and keep the output. The output part is doing a lot of work in that sentence, and it is usually wrong.

The economy-wide evidence is the first tell. If AI were converting into output at the rate the layoffs imply, you would see it in productivity statistics by now. You do not. Goldman’s read in early 2026 was flat. The NBER authors landed in the same place from the other direction: executives are more confident about AI’s productivity effect than their own results justify, which they attribute to a lag in realized returns. A lag is a polite word for a gap that has not closed.

The company-level evidence is sharper, and it points at the mechanism. A multi-month study out of UC Berkeley found that AI gains get absorbed by expanded tasks and higher expectations, a pattern the researchers called workload creep. A Fortune analysis found the time people spent on certain responsibilities rose by as much as 346 percent as they managed AI tools alongside the work they already had. Read those two findings together and the story is not “AI frees up time.” The story is “AI frees up time, and then the time refills before anyone decides where it should go.”

This is why I separate the two words so stubbornly. A saving is money that leaves your cost base and does not come back. Capacity is an hour that is now unspoken for. An hour is only worth something once you spend it on purpose. Leave it unspent and it does not sit in a bank earning interest. It gets eaten, usually by work that looks busy and produces little. The redeployment gap is the difference between the capacity a tool creates and the capacity you actually move to higher-value work. Every company that bought AI has opened this gap. Almost none of them are managing it.

AI returns capacity, and capacity is not the same as cash

Here is the model I use, and it is the one named idea in this piece, so I want to be precise about it. When AI absorbs part of a job, the freed capacity goes to exactly one of three places. I call the whole thing the redeployment gap because the gap is the point: the value you keep depends entirely on which of the three you choose, and two of the three are chosen for you unless you intervene.

The first fate is cut. You remove the person or the headcount the freed capacity represented. You book a one-time reduction in your cost base. It is real, it is legible, and a board loves it. It is also the lowest-ceiling option available to you, for reasons I will get to.

The second fate is evaporate. You keep the people, the tool quietly takes a slice of their work, and the freed hours refill with whatever is nearest: another standup, a longer Slack thread, a report nobody reads, more passes on a thing that was already fine. Nothing on a spreadsheet changed, so nobody noticed anything happened. This is the most common fate by a wide margin, and it is invisible, which is what makes it dangerous.

The third fate is redeploy. You name a higher-value use for the freed capacity in advance, you move the person or the hours to it deliberately, and you check that the move produced something the old work did not. This is the only fate that compounds, and it is the only one that does not happen on its own.

The reason this matters is that the three fates are not equally likely. Redeploy is the only one that requires a decision, so it is the only one that does not happen by default. If you do nothing, you get evaporate. If you react to a board that wants a win, you get cut. Redeploy is a thing you have to reach for on purpose, every time, and most organizations have no habit for it because for most of corporate history capacity did not arrive in loose, unassigned chunks. It came attached to a hire. AI changed that, and management has not caught up.

There is a second axis worth drawing, because it explains why so many redeployment efforts fail even when a leader means well. Freeing the capacity and reallocating it are two separate acts, and skipping either one wrecks the result.

The bottom-left quadrant is where most companies sit without knowing it. They never measured what got freed, so they never moved it, so it evaporated. The bottom-right is the clean cost cut: you measured, you banked the saving, and you stopped there. The top-left is the one that burns good intentions. A leader announces that everyone should now “focus on higher-value work,” but never actually frees the time, so the new mandate lands on top of the old load and produces burnout instead of output. Only the top-right compounds, and getting there takes both moves, done in order.

Cutting the capacity looks smart and compounds the least

Let me take the two defaults one at a time, because the arguments against them are different. Cutting first.

Klarna is the case everyone points to, and it earns the attention because it ran the full arc in public. In early 2024 the company said its AI assistant was doing the work of 700 agents and handling about two thirds of its customer chats. Over the following year it let headcount fall by roughly a fifth, down toward 3,500 people, mostly through a long hiring freeze. For a while it was the poster child for AI efficiency, with revenue-per-employee figures that made every founder jealous. Then, in May 2025, the CEO changed his tune in an interview. The chatbots were cheaper, he said, but the quality was lower. The company would make sure customers could always reach a human. His words were that investing in the quality of human support “is the way of the future for us.” Klarna started hiring customer agents again.

I do not read that as a story about AI not working. I read it as a story about what cutting costs you that does not show up on the saving. When you cut, you book the reduction, and in the same motion you throw away three things you cannot cheaply get back. You throw away the option to use that capacity for something better, because the capacity is gone. You throw away the institutional knowledge in the people who left, which is the expensive kind. And you throw away your own flexibility, because re-hiring is slow, costly, and, as Klarna found, it is hard to re-hire into a role you publicly declared obsolete.

Cutting has a ceiling built into it. A headcount reduction is a one-time event. You can do it once per role, and then that lever is spent. If your entire AI strategy is “find work AI can do and remove the person who did it,” you are running a subtraction business, and subtraction bottoms out at zero. The companies that will pull away are not subtracting. They are taking the same freed capacity and compounding it, which is an operation with no natural ceiling.

None of this means never cut. It means be honest that a cut is the floor of what freed capacity can be worth, not the ceiling, and that you are choosing the floor because it is easy to measure and easy to defend, not because it is the most value available. I wrote about a related version of this trap in the way AI shifts fixed salary cost into variable metered cost, which changes the math on what a cut even saves you. Cutting feels like the disciplined move. Often it is just the legible one.

The capacity you keep disappears unless you go looking for it

The second default is the one almost nobody talks about, and it is the one I think destroys more value, precisely because it leaves no trace.

Say you do the humane thing and keep your team. AI takes 30 percent of a role off someone’s plate. You did not cut, so you feel good. Now watch what happens to that 30 percent. In 1955, C. Northcote Parkinson wrote the line that still runs most offices: work expands to fill the time available for its completion. He meant it as satire about the British civil service. It reads today like a warning label for AI adoption. The freed 30 percent does not sit there waiting for you to assign it. It gets colonized by whatever is nearest and least resisted. A meeting that used to be 30 minutes becomes an hour because there is now an hour. A document gets a fourth and fifth review it did not need. A person who finished early finds more of the same work to do, because that is what good employees do when nobody has told them what the freed time is for.

This is exactly the workload creep the Berkeley researchers measured, and it is why the Fortune finding of up to 346 percent more time on some tasks is not a paradox. The time AI gave back got spent managing AI, formatting its output, checking its work, and doing more of the low-stakes activity that is always available to expand. The capacity was real. It just never left the gravity of the existing job.

The reason evaporation is so hard to fight is that it produces no signal. A cut shows up as a smaller payroll line. Evaporation shows up as nothing: same headcount, same hours, a vague sense that everyone is busy and the needle has not moved. You cannot manage what you cannot see, and freed capacity is invisible by default. Nobody files a report that says “I had four spare hours this week and spent them on things that did not matter.” They just spent them. If you want the capacity back, you have to go hunting for it before it is absorbed, because once it is absorbed it looks exactly like normal work.

There is a connection here to a constraint I have written about separately. When generation gets cheap, the bottleneck moves to the step AI did not speed up, which is usually a human one. I called that the verification ceiling, the limit on how much AI output a person can actually check. Evaporation and the verification ceiling are cousins. Both are cases where the freed capacity flows straight into the nearest human constraint instead of into new value, and in both the mistake is assuming cheaper generation automatically means more throughput. It does not. It means you now have a choice about where the freed effort goes, and choices left unmade get made for you.

Where the freed hours are supposed to go

If cutting is the floor and evaporation is the leak, redeployment is the thing you are actually trying to do, and it helps to be concrete about where the hours should land. The useful split is between work AI made abundant and work it made scarce.

AI made the production of ordinary output abundant. Drafts, first-pass code, summaries, routine analysis, the middle 80 percent of most knowledge tasks. The value of doing that work yourself fell, which is the whole point. What stayed scarce, and got relatively more valuable, is the work that sits on either side of that middle. Deciding what is worth building at all. Carrying real accountability for an outcome. Going deep with a specific customer instead of shallow across many. Holding a quality bar when the tools will happily produce plausible mediocrity. Building the relationships and the trust that no model can manufacture. That is where freed capacity is supposed to go, and the move is to pull people toward it, not to let them refill the abundant middle faster.

Notice that the left column is not lazy work. It is diligent work. That is what makes it such a good hiding place for freed capacity. A team that fills its new hours with more reviews and more meetings looks responsible. It is responsibly running in place. The redeployment job is to interrupt that reflex and point the same effort at the right column, which almost always feels riskier because its payoff is less certain and further out. Customer depth might not pay this quarter. A new line might fail. That uncertainty is exactly why the hours drift left unless a leader pushes them right.

The deepest version of the right column is the work that is incompressibly yours. I have argued that every company has a core that cannot be compressed by tools, the taste, the relationships, the specific judgment that is the actual business. Redeployment at its best is a transfer: you move hours out of the compressible middle, which AI now does, and into that incompressible core, which it never will. Done repeatedly, that is how a team gets more valuable rather than just cheaper.

How to actually move capacity instead of hoping it moves

The gap between knowing this and doing it is a process gap, and the process is not complicated. It is just unnatural, because it asks you to manage something invisible. Here is the sequence I use, and the discipline it takes.

First, measure the freed capacity before it disappears. When you put a tool into a workflow, estimate the hours it actually takes back, per person, per week, in plain numbers. Not the vendor’s claim, your own read. If you cannot say roughly how many hours a tool freed, you have already lost them, because you have nothing to reallocate and no way to tell whether reallocation worked. This is the step everyone skips, and skipping it is what drops you into the bottom-left quadrant.

Second, name the higher-value use in advance, in writing, before the hours arrive. “This tool frees about six hours a week per analyst, and those six hours go to building the customer-health model we have deferred for a year.” The specificity is the whole trick. “Focus on higher-value work” is not a plan, it is a hope, and hopes lose to Parkinson every time. A named destination gives the freed time somewhere to go that is not the nearest meeting.

Third, protect the reallocated time like it is a customer meeting, because defended time is the only kind that survives. Freed hours that stay inside the old job will be reabsorbed by the old job. The redeployed work often needs to be physically moved: a different block on the calendar, a different owner, a different success metric, sometimes a different room. If the new work has to compete with the old work for the same unstructured hours, the old work wins, because it is louder and more familiar.

Fourth, verify that the move produced something. This is the counterpart to measuring at the start. A quarter after you redeployed, ask what exists now that would not exist if you had done nothing. A model, a new line, a set of deeper customer relationships, a quality bar that visibly rose. If the honest answer is nothing, the capacity evaporated despite your plan, and you need to find out whether the destination was wrong or the time was never really protected.

If you look at that sequence, the hard parts are the first and the third steps, measure and protect, and they are hard for the same reason. Both ask you to treat an invisible thing as if it were real. A freed hour has no invoice and no calendar entry. You have to invent the accounting for it, because your existing systems only track money and headcount, and capacity is neither. Companies that build even a rough version of this accounting will capture the dividend. Companies that wait for it to show up in the usual reports will keep wondering where the AI savings went.

Two ways founders get redeployment wrong

I have watched two failure modes often enough to name them, and they are mirror images.

The first is treating redeployment as a headcount policy instead of a capacity practice. This is the Shopify posture in its blunt form. In April 2025 the company’s CEO sent a memo telling staff they had to prove AI could not do a job before they could ask for new headcount. As a discipline on reflexive hiring, that is reasonable. As a theory of value, it is incomplete, because it only governs the gate for new people. It says nothing about the capacity AI is freeing inside the people you already have, which is where the larger and more invisible pool sits. A hiring filter catches the capacity you were about to add. It does nothing for the capacity quietly evaporating across your existing team, and that is the bigger number.

The second failure is the opposite: using redeployment as a way to avoid every hard call. Not every freed hour has a higher-value home. Sometimes a function is genuinely shrinking, the work is commodity work, and there is no adjacent high-value task to move people into that your business actually needs. In that case, “we will redeploy them” becomes a comfortable fiction that parks people on invented work and calls it strategy. That is just evaporation with a nicer name. Redeployment is only worth anything if the destination is real and genuinely more valuable. If it is not, you are back to a cut you are avoiding for the wrong reasons, and avoiding it slowly is worse than making it cleanly.

The honest middle is to hold both at once. Default to redeployment because it is the only fate that compounds, and stay ruthless about whether the destination is real, because a fake destination wastes the capacity as surely as the nearest meeting would.

Sometimes the honest move is to cut, not redeploy

I want to argue against my own thesis for a moment, because the strongest version of this idea survives the pushback.

There are real cases where cutting is the right answer and redeployment is the self-indulgent one. If a line of business is in structural decline, freed capacity inside it is not an asset, it is a stranded cost, and moving those people to “higher-value work” that does not exist in your business is a way of refusing to face the decline. If your company is not growing and has no credible new bet for the freed hours to fund, holding extra capacity on the theory that you will find a use for it is how payroll outruns revenue. And at the extreme, the most valuable thing a struggling company can do with freed capacity is return the cash to a runway that keeps it alive. A cut that extends your life is worth more than a redeployment into work that does not pay.

So the test is not “cut versus redeploy” as a moral stance. It is a question about whether you have a real, higher-value destination that your business needs and can fund. If you do, redeployment compounds and cutting throws away the compounding. If you do not, cutting is the honest move and redeployment is theater. What you are not allowed to do is the third thing, which is the one most companies actually do: keep the people, free the capacity, name no destination, and let it evaporate while telling yourself you kept your team for their sake. That is the worst of both worlds. You carry the cost of the headcount and capture none of the value of the capacity. If you are going to pay for the people, make the capacity earn its keep. If you cannot make it earn its keep, be honest about the cut.

Running your first capacity audit in 30 days

If you want to close the gap in your own company, you do not need a transformation program. You need one audit and the willingness to act on it. Here is the shape of it over a month.

In the first week, pick the two or three workflows where you have already put AI to work, and estimate the capacity it freed, in hours per person per week, with real numbers. Do not try to boil the ocean. Two workflows you can measure honestly beat ten you guess at. The output of week one is a single number per workflow: this is how much capacity we created and have not assigned.

In the second week, decide where each pool of freed hours should go, and write it down as a specific destination with an owner and a metric. Not a theme, a destination. If you cannot name a real higher-value use for a given pool, that is not a failure of the exercise, it is the exercise working: you have just found capacity that should either be cut honestly or pointed at a bet you have been deferring. Either answer is better than letting it drift.

In the third and fourth weeks, move the time and protect it. Put the redeployed work on the calendar, give it an owner, and defend it against the old job’s gravity for the rest of the quarter. Then set a date, 90 days out, to check what exists because of the move. If something real exists, you have run the loop once and you can run it again on the next workflow. If nothing does, you have learned that your destination was wrong or your protection failed, which is a cheaper lesson to learn on two workflows than across the whole company.

The founders who will look prescient in two years are not the ones who cut the fastest in 2026. The layoff numbers will keep climbing, and most of those cuts will capture the floor of what the capacity was worth. The ones who pull ahead are running this loop quietly, turning freed hours into customer depth, new lines, and a rising quality bar, while their competitors wonder why the AI savings everyone promised never showed up on the P&L. The savings were always going to be small. The capacity was the prize, and the prize goes to whoever decides what to do with it.

Questions founders ask about freeing up capacity

Is the redeployment gap just a fancy way of saying don’t lay people off?

No. It is upstream of the layoff question. The gap is the distance between the capacity AI frees and the capacity you deliberately move to higher-value work. Cutting is one legitimate way to resolve that capacity, and sometimes it is the right one. The point is that cutting captures only the floor of what the capacity is worth, and that doing nothing, keeping people while letting their freed hours evaporate, captures nothing at all. The gap is about managing capacity on purpose, whichever way you resolve it.

How do I measure capacity that AI frees when it does not show up anywhere?

You estimate it directly, per workflow, in hours per person per week, using your own judgment rather than the vendor’s claim. Pick a specific workflow, ask the people in it how much time the tool actually took back, and write down one number. It will be rough, and rough is fine. The purpose is not accounting precision, it is having something to reallocate and something to check against later. Capacity you never measured is capacity you have already lost, because you cannot move what you did not name.

Why do the productivity gains from AI not show up in the numbers?

Because freeing a task is not the same as creating output. Goldman Sachs found no meaningful economy-wide link between AI adoption and productivity in early 2026, and researchers have documented workload creep, where freed time gets absorbed by expanded tasks and higher expectations rather than new value. The gains are real at the task level and invisible at the output level because most of the freed capacity evaporates into nearby low-value work before anyone redirects it.

What counts as higher-value work to redeploy into?

The work AI made scarce rather than abundant. Going deep with specific customers, making and owning judgment calls, building new products and lines you never had hours for, and holding a quality bar the tools cannot hold on their own. The simplest filter is to move hours out of the compressible middle, the ordinary output AI now produces, and into the parts of the business that are incompressibly yours and that no model can manufacture.

Klarna cut staff with AI and then rehired. Does that mean AI did not work?

No. It means a pure cut threw away things the saving did not account for: the quality the humans provided, the knowledge that left with them, and the flexibility to adjust. The AI worked at the task. The mistake was treating the freed capacity as a one-time cost reduction instead of asking what the right mix of human and machine actually was. The reversal is a lesson about redeployment, not about capability.

We are a small startup, not an enterprise. Does this still apply?

It applies more. A small team feels freed capacity faster and has fewer places to hide it, which means the choice between evaporation and redeployment hits your output almost immediately. For a founder, the freed hours are usually your own, and the highest-value destination is almost always customers and the parts of the product only you can judge. The capacity audit is lighter for you because you have fewer workflows, so there is less excuse not to run it.

How is this different from just being more productive with AI?

Productivity framing stops at the task: the tool makes a given job faster. The redeployment gap is about what happens to the hours that speed creates. You can be dramatically more productive at a task and capture none of it at the company level, because the freed time refills with other work. Being productive is necessary. Deciding where the resulting capacity goes is the part that actually changes your results, and it is the part most teams never manage.

What is the single first step if I only do one thing?

Pick one workflow where you already use AI and write down how many hours a week it frees, per person. That one number forces the invisible thing into the open. Once you can see the capacity, you can argue about where it should go. Until you can see it, it will keep going to the nearest meeting, and you will keep wondering where the savings went.

Where I land on this

The layoff wave of 2026 is being sold as an efficiency story, and the productivity data says the efficiency is not arriving. Both of those can be true at once, and the redeployment gap is why. AI is handing companies real capacity. Most of them are either banking a one-time cut and stopping, or keeping the capacity and letting it dissolve into busywork. Neither captures the prize. The prize is the deliberate act of moving freed hours into the work that compounds, and that act does not happen unless someone makes it happen. If you take one thing from this, let it be the habit of asking, every time a tool takes work off your team’s plate, a simple question: that capacity just came back to us, so where exactly is it going. Answer that on purpose, and you are already ahead of the companies counting savings that never show up.

I write about the founder mindset, AI opportunities, and the mechanics of building with AI. If this was useful, the companion pieces on why buyers still pay for software anyone can clone, the metric that should replace benchmark rank, and what the collapse in junior hiring costs you later go deeper on the operating decisions AI is forcing. The rising cost of keeping what is now cheap to make and what happens to the people you free up are the closest companions to this one. The full map is in the AI-native founder playbook.

I am a four-time founder building AI-native companies. I write about the founder mindset, AI opportunities, and the mechanics of building with AI at vikasmalpani.com.