Almost every AI consolidation we have run has the same three months of pain. The consolidation is correct — the math works, the architecture is sound, the eventual outcome is materially better than the seven-vendor baseline. The first three months are still hard in a way nobody warned the team about, and a meaningful fraction of consolidations have been reversed during this window despite the fact that the long-term direction was right.
The pain is not random. It has a shape. The shape is consistent across deployments, which means it can be planned for, communicated to leadership in advance, and survived. Teams that know the shape make it through; teams that do not assume something is uniquely wrong with their deployment and reverse before the curve bends.
Where the pain comes from.
Three sources, in roughly the order they show up.
The migration tax. Weeks one through three are spent setting up the new architecture, ingesting the corpus, fine-tuning the model, and standing up the workflow runtimes. The legacy tools are still running in parallel because the new system is not yet trusted. The team is paying for both, doing the work twice, and producing roughly the same output as before. This is the most expensive period of the deployment, and the one with the least visible payoff. Leadership sees double cost and no incremental value.
The recalibration drag. Weeks four through eight are when the new architecture goes live and the editorial team has to recalibrate against it. Every editor who developed implicit conventions against the legacy tools is now being asked to do the same work on a different surface, with different defaults, against a model that has not yet absorbed the editor's specific judgment. Output quality dips temporarily. Editor satisfaction dips temporarily. The dip is real and is exactly the cost of moving the editorial signal into the new architecture.
The political cost. The consolidation usually involved sunsetting tools that specific people in the organization advocated for and felt accountable to. Those people are watching the consolidation closely. If the migration tax and recalibration drag are visible without context, the political cost can become a campaign to reverse the consolidation. The campaign is rarely explicit; it shows up as escalating concerns about the new system, framed as risk management, that compound the original pain.
When the curve actually bends.
In the consolidations we have measured, the compounding curve typically begins to bend visibly around week ten. By week twelve the editor satisfaction recovers past the legacy baseline. By week sixteen the line-item delta is meaningful enough to defend in a board conversation. The trajectory is consistent enough that we now write it into the install schedule explicitly: leadership is briefed on day one that weeks four through ten will look harder than weeks one through three, that this is normal, and that the curve bends in week ten or eleven absent a specific architectural failure.
The briefing is the most important risk management we do. Consolidations that fail in our cohort almost never fail because the architecture was wrong. They fail because the leadership reading the dashboard at week six does not know that week six is the worst week, and acts to reverse the consolidation when the right action is to wait two more weeks.
Three things that materially shorten the pain window.
Pre-stage the corpus. The corpus ingest can begin two to three weeks before the rest of the architecture is live. The team is doing this work anyway; doing it early shifts week one's cost off the visible deployment timeline.
Recalibrate one editor cohort first. Instead of asking the entire editorial team to switch to the new surface in week four, pick the smallest cohort that can produce statistically meaningful editorial signal — usually two to four editors. Recalibrate them first, let the model absorb their corrections, then expand. The recalibration drag is shorter because the model is converging on a smaller editorial signal first.
Communicate the curve in advance to the political stakeholders. The people who advocated for the legacy tools should be brought into the consolidation conversation explicitly, with the curve shown on day one. Their concerns become collaborative if they feel included in the design; they become a campaign if they feel excluded. The political cost is largely communicative, not technical.
Why this matters for the next consolidation you run.
If you are about to run an AI consolidation, the most useful single thing you can do before week one is to brief leadership on the shape of the pain curve. Most leadership teams have not seen this curve before because most consolidations they have heard about did not survive long enough to publish it. The teams running the consolidation that lasted are the ones who knew the curve in advance and held the line.
We have written about the seven-tool consolidation a Fortune 100 brand ops team ran elsewhere in the dispatch. The consolidation took eight weeks of install plus four weeks of recalibration before the curve bent. The team made it because leadership had been told the curve in week one. We are not aware of an alternative pattern that produces consolidations that survive.
The communication discipline matters more than the architectural one. We have run consolidations against worse architectures successfully when the communication was disciplined, and seen consolidations against excellent architectures fail because nobody told leadership what to expect. Both observations point at the same conclusion: the consolidation curve is a leadership conversation, not an engineering exercise. The engineering team can do everything right and still see the program reversed at week six if leadership has been left to interpret the dashboard alone. The week-one briefing is the cheapest insurance the program will ever buy.