AI Agent Companies: Buy for the Wind-Down, Not the Demo

AI agent companies are the firms that build and sell software agents which decide and then act inside your systems, and in 2026 they come in five corporate shapes: model labs, agent-native startups, incumbent platforms, source-available projects, and services firms. The shape is a deployment variable, because it decides what happens to your running agents when the company behind them changes.

Our position, and it is not the usual advice: every exit clause you negotiated assumes you are the one leaving. Almost none of them survive the case that actually happens in this market, which is the vendor leaving you — acqui-hired, wound down, refocused, or quietly re-priced after a change of control. On 17 July 2025 a Humanloop customer posted the email he had just received to Hacker News, because nothing was public yet. The vendor had "entered into a process to be acquired" and was sunsetting the platform on 8 September. Buried lower: "all customer data will be removed from our servers and backups". That is 53 days from private email to dead API.

The short answer: Evaluate AI agent companies on custody, not capability — count how many of the five things an agent needs to run (credentials, agent definition, policy, model access, action record) live only inside the vendor, and treat anything above two as a wind-down you have already agreed to absorb.

Last updated: July 31, 2026.

The custody map: an agent needs five things to run, and each one sits with you, with the vendor, or with someone further upstream.

One honesty note before the argument starts. We have not operated most of the platforms named below, so nothing here is a review. What we did do ourselves is a count: we took four public wind-downs and one policy page per major model provider, and measured the interval between the first notice a customer could act on and the date the service stopped. Those intervals, and the table in the fourth section, are our own arithmetic from primary sources. They are the only original numbers in this piece, and we say where each one comes from.

What an AI agent company actually is

An AI agent company sells software that perceives, decides and then acts. It calls your APIs, writes to your records, sends messages under some identity, with a person supervising the outcome rather than each step. That last clause separates AI agent companies from the much larger set of firms selling chat interfaces, because a chat window that only produces text cannot leave a mess in your CRM.

It helps to say what the category is not. It is not a synonym for "AI companies": a model lab that sells raw inference is a supplier to agent companies as much as a competitor. It is not the same as automation vendors, whose products execute a graph you drew rather than a plan the software chose. And it is not a tier of quality. "Agentic" is a description of authority, not of intelligence, which is why our earlier analysis of enterprise agent deployment argues the deciding variable is reversibility rather than model capability.

What makes this category structurally different from ordinary SaaS procurement is the number of parties standing between you and a working agent. A conventional application vendor holds your data. AI agent vendors hold your data, your credentials to third-party systems, the definition of the agent itself, the policy that constrains it, and the only record of what it did, while renting the model underneath from someone else entirely. Five custody points, and typically two companies. That stack is the reason a question that sounds like corporate gossip ("will they still be here?") is really an availability question about production systems.

The five corporate shapes, and the failure each one carries

AI agent companies do not fail in one way, because they are not built one way. Sorting the market by corporate shape rather than by feature set gives you five buckets, and each carries a different characteristic failure. None of the five is safe; the point of the sort is that they fail differently, so the mitigation differs too.

The middle row is where most of the interesting products are, and it is also where the market has been most eventful. That is not a moral judgment about startups. It is an observation that the same conditions which make an agent-native startup worth buying from — small, fast, unencumbered by a legacy suite — are the conditions that make its corporate future least predictable.

Each shape fails in a different direction, and each one has a different clause that answers it.

A services firm deserves a specific warning, because it is the shape buyers most often mistake for the safest. An agency-built agent has no vendor to go bust, which sounds like an advantage until the engagement ends. What you are left with is a set of prompts, tool credentials, and glue code whose behaviour nobody on your payroll has ever changed. The failure is not insolvency, it is orphaning, and it arrives on a predictable date: the day the statement of work closes.

Why corporate shape became a deployment variable

Two things changed between 2024 and 2026. The first is that agents moved from demo to production, so a vendor's disappearance stopped being an inconvenience and started being an outage. The second is that the market found a way to remove the best people from a company without ever acquiring it, which broke the normal signal buyers rely on.

That second mechanism is worth naming precisely, because the press calls it several things. Big technology companies hire a startup's founders and senior researchers and license its technology non-exclusively, leaving the corporate entity, its investors, its remaining staff and its customers behind. CNBC reported in August 2025 that Microsoft used the pattern with Inflection AI in March 2024, Amazon with Adept in June 2024 and Covariant two months later, Google with Character.AI in August 2024 for $2.7 billion, and Google again with Windsurf on 11 July 2025 in a $2.4 billion licensing deal. Samir Kumar of Touring Capital described what remains as resembling a zombie company: "Frankly, you hollowed out the organization."

For a buyer, the significance is that none of those events look like distress from the outside. Adept had raised over $415 million at a valuation near $1 billion when Amazon hired its co-founders in June 2024; the company did not close, it appointed a new chief executive from the engineering team and refocused. Funding raised, logo wall, headcount, even a healthy valuation — every conventional viability signal stays green through a transaction like that. What changes is the thing you were actually buying, which was the team's continued attention to your product.

Ordinary failure has not gone away either, and it is the volume business. TechCrunch reported Carta's data in January 2025: 966 startups on Carta shut down in 2024 against 769 in 2023, a 25.6% rise, with enterprise SaaS accounting for 32% of them, the largest single category. Carta's head of insights, Peter Walker, noted the figure is a floor rather than a ceiling, because some companies leave Carta without saying why. Read that alongside the acqui-hire wave and the picture is not "AI startups are uniquely fragile"; it is that a buyer now faces two independent exit paths for the same supplier, one of which produces no distress signal at all.

Notice windows we measured from primary sources, alongside the minimum notice two model providers publish.

What the record shows: how much notice buyers actually got

This is the count we ran ourselves. For each event we took the earliest date a customer could have acted on the news, took the date the service stopped, and subtracted. No industry average exists for this, so the sample is small and the sources are named in full.

The Humane figure comes from The Verge's report of 18 February 2025: HP bought most of the company for $116 million, and purchased AI Pins continued working only until 15:00 ET on 28 February, after which they no longer connected to Humane's servers and lost calling, messaging, AI responses and cloud access. Users were told to download their photos, videos and notes before those were permanently deleted at the same moment. Ten days.

The Humanloop figure comes from the customer email posted to Hacker News on 17 July 2025, which set the sunset for 8 September. The company was candid about it. Export tooling was offered, the team was committed to staying available until the last day, and larger customers were invited to discuss bespoke extraction. That is roughly the best version of this event, and it was still 53 days to move prompt management, evaluations and observability data out of a platform teams had built process around.

The model-provider rows are policy minimums rather than events. OpenAI publishes at least six months of notice for generally available models, at least three months for specialized variants, and warns that preview models may be retired "with much shorter notice, such as 2 weeks". Anthropic publishes at least 60 days for publicly released models, and states plainly that partner-operated platforms such as Amazon Bedrock and Google Cloud set their own retirement schedules, so the same model can carry a different clock depending on where you call it.

Put the two halves of the table together and the asymmetry is the finding. The infrastructure layer of this market publishes notice periods measured in months and honours them on a public page. The application layer above it, where most AI agent companies live, publishes nothing at all, and the observed windows sit between ten and fifty-three days. You are relying on a supplier whose own supplier gives it more warning than it gives you.

The Wind-Down Test: five custody questions

Here is the diagnostic. It is called the Wind-Down Test because it assumes the answer to "will they survive?" is unknowable and asks a question you can actually resolve: if this company stopped existing on Friday, what would still be true on Monday? Five questions, each about one thing an agent needs in order to run, and each answered with a single word: ours, shared, or theirs.

You can run it from public documentation and one call with the vendor's solutions engineer. It does not require financial disclosure, which matters, because financial disclosure is the part of vendor diligence private companies decline most often and the acqui-hire pattern makes least informative.

The Wind-Down Test scored across five custody points; the count of "theirs" answers sets the decision.

Question 1 — Who holds the credentials the agent acts with?

An agent is only useful because it can reach your systems, and it reaches them with something: an OAuth refresh token, a service-account key, a stored password. Ask where that credential is stored, who can read it, and, this being the part vendors are least prepared for, whether you can rotate or revoke it from your side without the vendor's console. If the answer is that the vendor's database holds long-lived tokens to your CRM, your file store and your mailbox, then a wind-down is not merely a service interruption. It is an unplanned credential migration on the vendor's timetable, and every integration re-authorises by hand. Our earlier work on non-human identity argues every agent should carry an owner, a scope and an expiry for exactly this reason: an expiry date you set is a wind-down you have already rehearsed.

Question 2 — Where does the agent's definition live, and can you export it as text?

The agent definition is the prompt or instruction set, the tool list, the schemas, the routing rules and the guardrails. It is the intellectual property you created while using the product, and in most agent platforms it exists only as rows in the vendor's database, reachable through a canvas UI. Ask for an export in a format you can read without their software (JSON, YAML, plain text) and ask whether the export round-trips or is merely a viewer. A vendor who can hand you a versioned definition file has given you the option to rebuild elsewhere in days. A vendor who can hand you a PDF of a flowchart has given you a memento.

Question 3 — Who authors and enforces the policy?

Every deployed agent runs under constraints: what data may leave, which actions need a human, what it may never touch. Ask where those constraints are expressed. If policy lives in the vendor's product, then policy is a feature you are renting, and it disappears at the same moment the product does, including, awkwardly, on the day you most need it, because a migration is when agents get pointed at unfamiliar systems by tired people. If policy lives in a layer you own that sits in front of every AI surface, the vendor's departure changes which agent runs, not what any agent is allowed to do. This is the question our five control questions for agent platforms treats as a product-capability test; here it is a continuity test, and the same answer serves both.

Question 4 — Whose model is underneath, and on whose contract?

Most AI agent companies do not train the model they run on. Ask which providers they use, whether you can bring your own key, and what happens to your rate limits and data-handling terms when they change provider, because they will. If the vendor resells inference on their own contract, you have a sub-supplier you cannot see, cannot audit, and cannot follow if the vendor goes. If you bring your own key, the model relationship survives the agent vendor entirely, which is a materially different position on the day of a wind-down: the expensive part of your stack still works.

Question 5 — Where does the action record live, and how long does it survive the contract?

The audit trail is the only asset in this list whose value increases after the vendor is gone. It answers the auditor asking what an agent did in March, the customer asking why they received a message, and the incident review asking which change caused the failure. Ask three things: can you stream the record to your own storage continuously (not export it on request), what retention applies after termination, and what happens to it in an insolvency. Humanloop's email is the reference case. The platform's evaluation and observability data was leaving with the platform, and the notice said data would be removed from servers and backups shortly after sunset. A record you can only read inside the vendor's UI is a record you do not have.

Score it: the custody count in one sitting

Count the "theirs" answers. That number, not a feature score, is the output of the Wind-Down Test, and it maps onto a decision you can defend in a procurement meeting.

The scoring is deliberately blunt. A weighted rubric invites negotiation about weights, and in our experience of writing these frameworks the weights are where the discipline leaks out. A count of five plain answers survives being repeated in a meeting nobody prepared for.

Two practical notes on running it. First, ask the five questions in a single written message and keep the reply; a vendor's willingness to answer in writing is itself a signal, and the reply becomes the attachment to your risk register. Second, run it before the pilot, not before the renewal. The custody position is set by how you integrate, and integration decisions are made in week two of a pilot by an engineer who has never seen your vendor-risk policy.

The test also has a version for the services-firm shape, where four of the five questions collapse into one: at handover, does the artifact (definitions, credentials location, policy, runbook) exist in your repository, owned by a named person on your payroll, or does it exist in the agency's Notion? Ask it in the statement of work, not at the closing meeting.

The sub-supplier under your vendor: model retirement clocks

Even a perfectly healthy AI agent company hands you a dependency it does not control. The model underneath is retired on the model provider's schedule, and the behaviour of your agent changes when it moves. This is the failure mode people miss because it does not involve anyone going out of business.

The published clocks are specific. OpenAI's deprecations page commits to at least six months for generally available models, at least three months for specialized variants, and as little as two weeks for previews, adding that safety or compliance concerns may force a shorter timeline. Anthropic's page commits to at least 60 days for publicly released models and lists retirement dates model by model. Claude Sonnet 3.7 deprecated 28 October 2025 and retired 19 February 2026, Claude Opus 4 and Sonnet 4 deprecated 14 April 2026 and retired 15 June 2026. Both providers publish, both notify, and both retire on the date they said.

Now put an agent vendor in the middle. The clock starts when the model provider notifies the vendor, not you. If the vendor takes six weeks to test and migrate, your effective notice on a 60-day window is a fortnight, and the first you hear of it may be a changelog entry saying the default model changed. Ask the vendor two questions: what is your policy when an underlying model is deprecated, and do you notify customers before you switch. A vendor with a written answer has thought about it. A vendor without one will make the decision for you at 11pm on a deadline.

There is a second-order effect worth naming. An agent's behaviour is tuned against a specific model, and a forced migration is a behavioural change to production automation that no one requested. If the agent writes to records, that is a change-management event, not a maintenance window. Treating model retirement as a scheduled behavioural change, with a re-run of your acceptance cases against the replacement model before the retirement date, is the cheapest control available here, and both providers give you enough notice to do it if you are watching their pages rather than waiting to be told.

What source-available code does and does not buy you

"It's open source, so we're fine" is the most common answer we hear to the wind-down question, and it is usually half true at best. Much of the agent tooling described as open source is source-available under licences that permit internal use but not much else, and the enterprise features that made you choose it are often outside the licence entirely.

n8n is the clearest published example, and its licence is worth reading rather than assuming. The LICENSE.md in the repository puts most of the code under a Sustainable Use License permitting use or modification "only for your own internal business purposes or for non-commercial or personal use", with distribution to others only free of charge and non-commercially. Separately, files containing .ee. in the filename or directory are explicitly not covered and require a valid n8n Enterprise License. Content on branches other than master is not licensed at all.

Read that as a continuity question rather than a philosophy one. If the company is gone, the master-branch code remains usable for your internal business purposes, which is genuinely valuable and a better position than a closed platform. But the enterprise-licensed modules sit behind a licence granted by an entity that may no longer be there to grant it, nobody is shipping security patches, and the maintained fork you are hoping for has to appear, gain trust, and stay alive. A repository is a recovery option, not a service.

The honest scoring is that a source-available project usually converts one "theirs" answer to "shared". The agent definition and often the runtime become recoverable, while leaving credential custody, policy authorship and the action record exactly where they were if you use the vendor's cloud. Self-hosting from day one converts more, at a real operating cost we have written about separately in our comparison of SaaS against your own cloud. The point is not that one is right. It is that "open source" without self-hosting buys you far less continuity than the phrase implies.

What the regulators already require

If your organisation is in scope for financial-sector rules, most of this is not optional and has not been for a while. The EU's Digital Operational Resilience Act is explicit. Article 28(8) requires that "for ICT services supporting critical or important functions, financial entities shall put in place exit strategies", and says those strategies must account for "a possible failure on their part, a deterioration of the quality of the ICT services provided", business disruption, and termination of the arrangement. Entities must be able to exit without disruption to business activities, without limiting regulatory compliance, and without detriment to service quality for clients. Article 28(3) additionally requires a maintained register of information covering all contractual arrangements for ICT services, which means an unregistered agent pilot bought on a credit card is already a finding before anything goes wrong. The text is reproduced at digital-operational-resilience-act.com.

Outside financial services the language is softer but the expectation is the same. The NIST AI Risk Management Framework playbook puts third-party dependency in the GOVERN function. GOVERN 6.1 asks for policies and procedures addressing AI risks associated with third-party entities, including transparency into third-party system functions and testing of third-party AI systems. GOVERN 6.2 is the one that matters here: "Contingency processes are in place to handle failures or incidents in third-party data or AI systems deemed to be high-risk", with suggested actions covering redundancy for vital third-party AI systems and incident response plans that address them. Neither of those is a novel demand invented for AI. They are the third-party resilience controls every mature security programme already runs, applied to a supplier category that mostly did not exist when the programme was written.

For a fuller treatment of what third-party risk management looks like under DORA, this recorded webinar session covers the oversight and contractual side in detail.

The practical translation for a buyer with no regulatory obligation at all: regulators converged on exit strategy as the control because it is the one that works when prediction fails. You do not have to forecast which AI agent companies survive. You have to be able to leave any of them inside a window you choose rather than one you are given.

A worked example: running the test backwards on Humanloop

Retrospect is unfair to the vendor and useful to the buyer, so treat this as a diagnostic exercise rather than a criticism of a company that handled its sunset better than most. Humanloop sold prompt management, evaluations and observability for LLM applications, adjacent to agent tooling and subject to the identical dynamics. Its team joined Anthropic, and the platform was sunset.

Score the five questions the way a customer would have in June 2025. Two rows resolve from the public record; three do not, and marking them unknown is the correct answer rather than a gap in the exercise, because "we never asked" is the state most buyers are actually in.

One confirmed "theirs", one "shared", and three questions nobody had asked. That is the honest output, and the useful part is how cheap the three unknowns would have been to resolve in a single email before the pilot started.

What the record does establish is how the sunset ran: the email offered export tooling via existing API endpoints plus a tailored option for very high log volumes, committed the team to remaining available until 8 September, and said data would be removed from servers and backups soon after the platform closed. As wind-downs go, that is the good version.

The lesson is not "they should have scored better". It is that the two things which decided how painful those 53 days were — whether the definitions could be pulled through an API, and whether the logs had been streaming somewhere you own — were both settled at integration time, months earlier, by an engineer choosing the fastest path. Nothing about the vendor's finances would have told you anything. The custody position would have told you everything.

Run the same exercise on your own current stack and it takes an afternoon. Pick the three agent products already in production, answer five questions each, and note which "theirs" answers are cheap to convert. Log streaming is usually the cheapest and the highest value; credential custody is usually the most expensive and the most consequential.

What to put in the contract before you sign

Diligence that does not end in a clause is a memo. Five provisions cover the wind-down case, and none of them is exotic. They are standard outsourcing terms that simply did not make it into fast-moving contracts with AI agent vendors.

A notice floor tied to the model layer. Ask for a minimum notice of termination or material service change that is at least as long as the notice the vendor's own model providers give it. If your supplier gets 60 days from Anthropic and 180 from OpenAI, a 30-day termination right against you is a term they should struggle to defend.

Transition assistance, priced and time-boxed. DORA's language is the right shape even if you are not in scope: a defined transition period during which the provider keeps delivering while you migrate or bring the function in-house. Name the duration, name the rate, and put it in the contract rather than in a conversation with a solutions engineer who may not be there.

Continuous export, not export on request. The right to request your data is worth much less than a live feed of it. Ask for the ability to stream run logs and traces to your own storage during normal operation. This is also the provision that keeps working when the vendor's staff are down to a skeleton crew and nobody answers the support inbox.

Change-of-control notification with a walk-away right. The acqui-hire pattern is precisely a change of control that is structured not to look like one, so write the trigger broadly: a transfer of the majority of the engineering or leadership team, a licensing of the core technology to a third party, or a discontinuation of the product line. Attach a termination-for-convenience right with a pro-rata refund.

Data return and deletion, with a survival clause. Specify the format, the window, and what happens to backups. Then check that the clause survives insolvency, because a liquidator is not bound by an operational promise made in a support email.

One more thing that is not a clause: keep the pilot's blast radius small enough that the wind-down case is survivable at any point. A vendor holding read access to a document store is a bad weekend. A vendor holding write credentials to your billing system is a project.

When this diligence is the wrong use of your time

There is a real argument against everything above, and it deserves stating properly rather than as a token counterpoint. Applied indiscriminately, wind-down diligence is a tax on exactly the vendors most likely to solve your problem, and it slows adoption in a market where being late is also a cost.

Three cases where we would skip most of it. First, when the agent is genuinely non-critical and read-only. A drafting assistant with no write access and no regulated data. The wind-down case is that someone drafts by hand for a fortnight. Second, when the pilot is deliberately short and disposable, with an explicit intent to learn rather than to run. Buying a three-month experiment on twelve-month resilience terms is how organisations end up with no experiments. Third, when your own control layer already answers questions one, three and five for every AI surface. If credentials, policy and the action record sit in something you operate, then the vendor is already a replaceable component and the custody count is structurally low before you ask anything.

There is also a fair objection to the framework's premise. Large incumbents fail this test in a different direction: they will still exist, but the specific agent capability you built on may be deprecated inside a suite you continue to pay for, with the same practical consequence and no negotiating leverage at all, because you are not leaving over it. Corporate survival is not the same as product survival, and the Wind-Down Test measures the second. If you read the first two shapes in our table as "startups risky, incumbents safe", you have read it wrong.

Finally, the test can be gamed. A vendor can answer "ours" to the credential question because they support bring-your-own-key while defaulting every customer to their managed option. Ask what the default is, and what your own configuration actually does today. The answer that matters is the one describing your tenant, not the one describing the product's capability matrix.

Where this analysis is uncertain

The honest limits of this piece, so you can weigh it accordingly.

The notice-window sample is five rows, two of them events and three of them published policy minimums. That is not a distribution, and it should not be quoted as an industry average. We looked for a systematic dataset of SaaS shutdown notice periods and did not find one; if a reader knows of a rigorous one, we would rather cite it than our own arithmetic.

Financial viability is deliberately absent from the framework, and that is a choice with a cost. Runway, burn and revenue concentration genuinely predict failure, and a buyer with the leverage to demand audited figures should use it. We built the test around custody instead because most buyers do not have that leverage, private companies rarely disclose, and the acqui-hire pattern makes the disclosure that is available least informative. A well-funded company with two years of runway can still lose its founders on a Friday.

The corporate-shape taxonomy is a description of the market in mid-2026 and will age. Model labs are moving into the application layer, incumbents are acquiring agent-native startups outright, and the boundary between a source-available project and a commercial platform moves with each licence change. Treat the five shapes as a sorting aid, not a permanent structure.

We also cannot tell you what any specific AI agent company will do, and we have deliberately not scored named vendors here. Every vendor-specific claim in this article describes a completed public event or a published policy page, cited and dated. The reason for that restraint is not diplomacy. It is that a ranking of AI agent companies by survival probability would be exactly the kind of confident guess this framework exists to avoid.

Where LeapForce fits, and where it does not

LeapForce is not an AI agent company in the sense this article has been using. We do not sell the agent that reads your tickets or drafts your quotes, and if you are shortlisting vendors for that job, we are not on the list. What we build is the layer underneath: one controlled endpoint to every model, SSO in front of every AI surface with every non-human identity carrying an owner, a scope and an expiry, a connector registry your IT team vets once, and an audit record of what agents did that lives with you. That layer is what turns three of the five custody questions into "ours" regardless of which agent vendors you pick, and it is the same layer that lets you swap one of them out without renegotiating your security posture. Our gateway rollout model is deliberately staged for that reason — observe first, enforce second, optimize third — because a control layer adopted in observe mode gives you the inventory that DORA's register and NIST's GOVERN 6 both ask for, before it changes anyone's workflow.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.