The Automation Rescue Market: Selling Takeover Work in 2026

The week the orphans arrived

The Relay shutdown is worth looking at closely, because it is a clean example of a failure mode that has nothing to do with software quality. The product worked. It had a loyal base of users who liked its human-in-the-loop design. What happened, according to widely reported accounts of the wind-down, is that Google hired founder Jacob Bank and several staff members, taking the team but neither the product nor the brand. The company handled the exit well by the standards of the genre: customers got roughly two months' notice, annual plans were refunded pro rata, and workspaces received bonus step and credit allowances to get their exports done. None of that changes the outcome for the buyer. An automation you cannot run is an automation you no longer have.

For anyone who sells automation work, that window was a market. Every affected business faced the same short list of decisions: what do we actually have running, which of it still matters, where does it go, and who moves it before the lights go out. Most of them could not answer the first question without help, which is the detail that matters commercially. The migration was not the hard part. The inventory was.

One shutdown would be an anecdote. What makes 2026 different is that three other supplies of orphaned automation were filling up at the same time, and they are not going to empty in the next eighteen months.

Where orphaned automation actually comes from

If you are going to build a practice around this work, it helps to be precise about the sources, because each one produces a different kind of mess and a different kind of buyer.

Platforms that close or change shape. Relay is the recent case, but the broader pattern is consolidation and repricing. Make moved its billing from operations to a credits model in August 2025, which changed the cost of every scenario that had been sized under the old unit. Zapier now charges agent tool calls in tasks — each successful call through its MCP endpoint consuming two, with failed calls not counted — which means an automation designed when the unit was a step now has a different bill when an agent drives it. And on 1 July 2026, Microsoft's commercial price increase took effect across most Business, Enterprise and Frontline plans, with published increases ranging from about 5 percent on E5 to 25–43 percent on frontline SKUs. None of these is a shutdown. All of them make finance departments ask what the automation stack costs and whether it should move.

Agent projects that get cancelled. Gartner's forecast that more than 40 percent of agentic AI projects will be cancelled by the end of 2027 — on escalating costs, unclear business value or inadequate risk controls — is now widely quoted, and the interesting part for a seller is what a cancellation leaves behind. It is rarely nothing. There is usually a half-built integration layer, a set of API credentials in use, some data pipeline that other teams quietly started depending on, and a sponsor who needs the salvageable 20 percent to keep working while the rest is retired quietly.

Automations written by AI and reviewed by nobody. This is the largest and least visible supply. The clearest public measurement comes from software rather than automation platforms: GitClear and GitKraken analysed 623 million code changes between 2023 and 2026 and found eight maintainability signals deteriorating simultaneously. Duplication rose 81 percent, from 40.3 to 73.0 duplications per million changed lines. Copy-paste was up 41 percent, error-masking catch blocks up 47 percent, while refactoring fell 70 percent, cross-file reuse 35 percent and legacy maintenance 74 percent. Anyone who has opened an AI-generated automation will recognise the shape: the same branch logic pasted into six scenarios, a catch block that swallows every error into a silent success, and no shared module anywhere. We covered the buyer's side of this in our analysis of vibe automation and what AI-built workflows really cost; the seller's side is that this is now billable work.

People who leave. The most ordinary source, and the one nobody announces. An operations manager who built forty scenarios in their spare time changes jobs, and forty scenarios become an archaeological site. The credentials are under their personal account, the naming convention exists only in their head, and the business finds out which ones mattered by watching what breaks.

The demand signal is already visible in the freelance market. Freelancer.com reported an 87 percent rise in postings for fixing AI-generated work, with Upwork up around 70 percent over a year, and Fiverr's business trends reporting has tracked triple-digit surges in remediation categories. Rates quoted publicly for "cleanup specialists" run from about $15 an hour on offshore listing sites to $150–$400 an hour for senior specialists — a spread that tells you something important. The buyer has no reference price for this work yet, which means how you frame it determines what it is worth.

Why takeover work does not price like build work

The instinct of most automation sellers, when a takeover request arrives, is to estimate it like a build and add a margin for unpleasantness. That is the error that turns rescue work into unpaid overtime. A build has a known starting point: nothing exists, you decide the design, and the scope is what you wrote down. A takeover has an unknown starting point that is actively hiding from you, and the client usually cannot describe it either, because if they could describe it they would not need you.

That last row is the one that changes your pricing power. A build competes with doing nothing, which is why build buyers negotiate hard. A rescue competes with a deadline that someone else set. The deadline does not negotiate.

Sell the diagnosis before you sell the repair

The single most useful thing you can productise here is a fixed-fee automation audit: two to five days, one fixed price, delivered as a document the client owns outright even if they never hire you for the remediation. It de-risks the engagement for both sides and it is the only honest way to quote a fix for a system you have not seen.

A takeover audit should produce five artefacts, and you should name them in the proposal:

1. An inventory. Every automation, scenario, scheduled job and webhook that exists, including the ones nobody mentioned. This is the deliverable clients underestimate most and value most once they see it.
2. An owner and credential map. Which account each automation authenticates as, who holds that account, whose personal login is quietly load-bearing, and which keys have not been rotated since the builder left.
3. A risk-ranked failure list. Not every broken thing, but every broken thing ranked by what it costs when it fails — silent data loss above cosmetic errors, anything touching money or customer communication at the top.
4. A dependency map. Which business processes would stop if each automation were switched off today. This is how you find the four workflows that actually matter out of the sixty that exist.
5. Costed options. Three routes, usually: stabilise in place, migrate, or retire and rebuild — each with a price, a duration and a plain statement of what the client gives up by choosing it.

Three rescue offers, and what each one really costs you

Once the audit is done, most takeovers resolve into one of three engagements. Packaging them explicitly stops the conversation from collapsing into open-ended hourly work, which is where rescue margins go to die.

The migration case has enough structure to be a standing offer in its own right, particularly when a platform announces an end-of-life or changes its billing unit. We set out how to package that specific motion in offering migration as a service, and the same shape works for any platform pair.

One structural warning about migrations: resist the temptation to transliterate. Rebuilding a client's sixty scenarios one-for-one on a new platform reproduces every design flaw, including the duplicated branch logic and the swallowed errors, and then you own them. The audit's dependency map usually shows that sixty scenarios are really twelve processes wearing sixty hats. Quote the twelve.

What to refuse, and how to refuse it

A rescue practice is defined as much by what you decline as by what you accept. Four situations are worth a firm no, delivered early and without drama.

• No independent credentials. If you cannot authenticate as yourself, with keys the client controls and can revoke, you are borrowing someone else's identity to touch production. Decline until that is fixed, and make the fix the first billable step if they want your help doing it.
• The previous builder still has live access. Shared logins that nobody can revoke are not just a security problem; they make it impossible to say who caused the next failure. Insist on rotation before you accept responsibility, and get the revocation confirmed in writing.
• Retroactive liability. Some clients, particularly after an incident, want the new supplier to absorb the consequences of what happened before they arrived. That is not a commercial negotiation, it is a transfer of someone else's risk, and it is uninsurable in practice.
• Diagnosis funded, remediation not. Auditing a regulated process — payroll, invoicing, clinical records, anything moving money — and then watching the findings go unfunded leaves you as the person who documented a known defect and did nothing. Either the fix is funded or the finding is formally accepted by the client in writing.

Finding the work: follow triggers, not prospects

Rescue work has an unusual property for a service business: the demand is dated. A shutdown notice, an end-of-life announcement, a billing model change, a licence price increase or a round of operations layoffs all create a window in which a specific set of businesses must act, and roughly when. That is far more actionable than a list of companies that might one day want automation.

The practical version of this is a trigger calendar. Things worth watching, in rough order of usefulness:

• Shutdown and end-of-life notices from automation platforms, connectors and niche SaaS tools. These come with published deadlines, which means a known decision window.
• Billing unit changes. When a platform moves from operations to credits, or starts charging agent calls differently, every existing cost model on that platform silently becomes wrong.
• Licence price increases in the surrounding stack, like the July 2026 Microsoft 365 commercial adjustment, which push finance teams to re-examine what everything costs.
• Funding events and acquisitions among tools your clients depend on, since integration roadmaps change after both.
• Public signals of an internal builder leaving — a role change on a professional network, a job posting for "operations analyst, automation experience" at a company that never had one.

The way to convert a trigger is to publish something specific and genuinely useful within days of it becoming public: an export checklist for the platform that just announced its closure, a cost comparison under the new billing unit, a migration guide for one particular platform pair. People in this situation search for the name of their problem, and they search in the same week. A page that answers the exact question they are typing is a warmer introduction than any outbound message, and it compounds, because the next platform to shut down sends the same people looking for the same kind of help.

Turning the rescue into recurring revenue

A rescue client has just had an expensive, concrete lesson in what an unowned automation costs. They will never again be as receptive to an ongoing maintenance agreement as they are in the fortnight after the incident. Use that, but use it honestly: the retainer belongs in the audit document as one of the costed options, not as a surprise upsell once the repair is done.

Price it against what the remediation cost rather than against your hours. A client who just paid to rebuild twelve processes can see the logic in paying a fraction of that annually to ensure it does not happen again; the same client asked to pay for "four hours of monitoring a month" will compare your rate to a junior hire and decide it is expensive. The structure of a good ongoing agreement — what is included, what is explicitly excluded, how response times are defined, what triggers a change request — is the same whether you built the system or adopted it, and we go through it in detail in our guide to building a monthly maintenance offer. The only clause that changes for an adopted system is the date line on legacy defects.

If the client declines the retainer, finish properly anyway. Hand over documentation good enough that the next person does not have to repeat your diagnosis: the inventory, the credential map, the dependency map, and a short note on what you would fix next and why. Orphaned systems have a way of coming back, and the person holding a document with your name on it knows exactly who to call.

The uncomfortable conclusion

There is a version of this argument that sounds cynical — that the best business in automation right now is cleaning up after the last wave of automation. It is worth sitting with why that is true rather than treating it as a joke. Building an automation got dramatically cheaper over the last two years. Owning one did not. The cost of ownership is made up of things that no generation of tooling has made cheaper: knowing what you have, knowing who is responsible, knowing what breaks when a platform changes, and having someone available on the morning it does.

That is the gap the rescue market sits in, and it is not a temporary one. Every acceleration in how fast automations get created widens it. The sellers who do well over the next two years will be the ones who stop pitching speed — which is now free and which the buyer has already been burned by — and start pitching the thing that was never automated in the first place: continuity of ownership.

FAQ

What is automation takeover work?

It is paid work on automations you did not build. The client already has something running, or something that recently stopped running, and needs someone to take responsibility for it. In practice it covers four situations: a platform shutting down and forcing a migration, an internal builder leaving without documentation, an AI-generated workflow that works in the happy path and fails everywhere else, and a stalled agent project that has to be either finished or retired. The work is diagnostic before it is technical, which is why it prices differently from a new build.

Why did so much orphaned automation appear in 2026?

Four supplies converged. Platforms closed, most visibly Relay.app, which told customers on 16 July 2026 that it was winding down, cut off free accounts on 15 August and paying customers on 14 September 2026. Agent projects were cancelled, in line with Gartner's forecast that over 40 percent of agentic AI projects will be scrapped by the end of 2027 on cost, unclear value or weak risk controls. AI-written automation piled up faster than anyone could review it. And repricing forced migrations, including the Microsoft 365 commercial increase of 5 to 43 percent depending on SKU that took effect on 1 July 2026.

How should I price a takeover when I cannot see the system yet?

Do not price the repair before the diagnosis. Sell a fixed-fee audit first, typically two to five days of work, that produces an inventory of every automation, an owner and credential map, a risk-ranked list of failures, and a costed set of options. Then quote the remediation as a separate engagement, informed by what you found. This protects both sides: the client gets a decision-ready document even if they hire someone else, and you never fixed-price an estimate you had no way of making.

What should I refuse to inherit?

Refuse anything where you cannot get your own credentials, where the previous builder still has live access you cannot revoke, or where the client wants you to assume liability for outcomes produced before you arrived. Also refuse a takeover that comes with no budget for the fix, only for the diagnosis, in a regulated process such as payroll, invoicing, clinical data or anything touching payments. Inheriting an unfunded liability in a regulated workflow is the fastest way to turn a good client into a legal problem.

Is AI-generated automation really harder to maintain?

The measurements say yes. GitClear and GitKraken analysed 623 million code changes from 2023 to 2026 and found eight maintainability signals moving the wrong way at once: duplication up 81 percent, from 40.3 to 73.0 duplications per million changed lines, copy-paste up 41 percent, error-masking catch blocks up 47 percent, refactoring down 70 percent, cross-file reuse down 35 percent and legacy maintenance down 74 percent. Automation platforms are not codebases, but the pattern is the same one takeover specialists find: logic duplicated across scenarios, errors swallowed silently, and nothing consolidated.

How do I find takeover work without cold outreach?

Follow trigger events rather than prospects. Shutdown notices, end-of-life announcements, billing model changes, licence price rises and layoffs in operations teams all create a dated window in which someone must act. Publish a specific, useful response to each trigger within days of it becoming public: an export checklist, a cost comparison, a migration guide for one platform pair. That kind of page is found by people typing the name of their problem, which is a far warmer entry point than a cold message to someone whose automations are working fine.

Should a rescue engagement always end in a retainer?

It should always offer one, and it should never assume one. A rescue client has just learned what an unowned automation costs, which makes them the most receptive audience for ongoing maintenance you will ever meet. Propose the retainer in the audit document, not after the repair, and price it against the remediation cost rather than against hours. If the client declines, hand over documentation good enough that the next person does not have to repeat your diagnosis, and stay reachable. Orphaned systems tend to come back.

What contract terms are specific to inherited systems?

Four that a standard build contract does not need. An as-is acknowledgement stating that you did not design the existing system and are not warranting its historical behaviour. A liability line drawn at a named date and time, after which your work is covered and before which it is not. A credential reset clause requiring every key, token and shared login to be rotated before you take responsibility, with the old builder's access revoked in writing. And a documentation deliverable defined as a contractual output rather than a courtesy, because the absence of documentation is usually why the client is talking to you.