BLOG · POST-MORTEM
Of the cohort that launched in 2024 and 2025, 70% to 75% have failed. The causes are not mysterious and they are not about technology quality. Three structural patterns account for most of it — and each is visible before the first client signs.
The failure rate in this category is close to a coin flip weighted badly: 70% to 75% of AI agencies that launched in 2024 and 2025 have failed. That is not a normal attrition rate for a services business, and it is not explained by a shortage of demand — the same period saw adoption move from 8% to 34% in the US alone.
Something specific is killing them, and the pattern is consistent enough to name. These are the three causes, in order of how much they explain.
The most common fatal error is automating a task rather than a workflow. The distinction sounds like semantics and it is not.
A task is a discrete action: draft a reply, summarise a document, classify an enquiry. A workflow is a process with an owner, a beginning, an end, and a consequence when it fails. Automating a task produces an impressive demo and no operational change. Automating a workflow produces something the client now depends on.
The commercial consequence is direct. Task automation is easy to demonstrate and impossible to charge for repeatedly, because the client's dependency never forms. Workflow automation is harder to demo — it requires understanding how the client actually operates — and it creates the dependency that justifies a retainer.
If the client can turn it off on Monday without noticing by Wednesday, you have automated a task. That is a demo, not a deployment.
The second pattern is buying the stack before understanding the work. It manifests as an operator who has strong opinions about orchestration frameworks and no map of the client's intake process.
This inverts the order of the two decisions that actually determine success. The process tells you what must be true for the automation to be correct. The tool tells you only what is convenient to build. When those conflict — and they always conflict — an operator who chose tools first will bend the process to fit the tool, which produces something that runs and does not match how the business works.
Clients experience this as an agent that is "almost right," requiring constant correction, and they conclude the technology is not ready. It is usually the mapping that was not ready.
The third pattern is the one that kills businesses that were technically competent. It runs on a predictable schedule.
An operator signs 4 to 8 clients in the first 90 days — achievable, because early sales are usually warm network deals. Delivery is stretched but holds, because early deployments are novel and the operator is personally motivated. Then, around month four to six, the accumulated maintenance load on those clients exceeds the capacity of the team delivering the new ones. By month nine, delivery has collapsed.
The mechanism is that in this business, sales consume capacity and delivery consumes capacity, and both scale linearly while the operator is the only constant. Growth is therefore not a neutral act — every new client adds revenue and subtracts from the ability to serve the existing ones. Operators who treat sales as purely additive discover the subtraction around month seven.
Eight clients signed in ninety days is not a growth milestone. It is a delivery liability with a nine-month fuse.
There are approximately 24,556 AI agencies worldwide by direct count, with consultancy estimates ranging from 35,000 to 50,000. The spread is itself informative: nobody has a clean census, which means the category is young enough that its own participants cannot count it.
Median time to a first paid result in focused execution is 8 to 10 weeks. That is the honest timeline for someone doing the work in the right order — and it is considerably slower than the timelines implied by people selling courses about the category, which is part of why so many entrants over-extended on acquisition.
Three questions, answerable today, no data collection required.
One: name your last three deployments and state what happens if the client switches each off. If the answer is "they would not notice," those are tasks. Two: for your current build, can you describe the client's process including the step that will still be manual afterward? If not, the mapping is incomplete. Three: count your active clients and the hours per week each consumes in maintenance. If that total exceeds one full-time person, your next sale is a decision about whether you can serve it.
None of these require admitting anything uncomfortable out loud, which is why they are worth doing. The failure modes above are not character flaws. They are structural patterns that look like sensible decisions at each individual step.
Because attaching one would undermine the only thing it is good for. If you are running one of these patterns, the valuable action is naming it accurately and deciding what to change — and a vendor's deployment check is not a neutral instrument for that.
The useful output of a post-mortem is a diagnosis, not a purchase. If it prompts you to count maintenance hours per client, it has done its job.
There is no offer attached to this piece. If you are running one of these patterns, the useful next step is naming it precisely — and that starts with the pattern, not with a vendor.
Run the deployment checkNo form. No call. Read the patterns and check yourself against them.