When an AI agent stack with three vendors breaks in production, the contracts rarely say who pays first, and most founders find that out during the incident, not before.
- A liability waterfall is the contractual order in which vendors absorb cost when an AI agent causes damage, and most startups never negotiate one
- Foundation model providers like OpenAI and Anthropic cap liability in standard terms, often at fees paid in the prior 12 months, which can be a few hundred dollars for a small account
- Orchestration layers such as LangChain or Microsoft's Copilot Studio typically disclaim liability entirely and push risk back to the customer through indemnification clauses
- Air Canada was held liable in 2024 for its own chatbot's bad advice because a tribunal ruled the company responsible for all information on its site, regardless of which vendor built the tool
- The fix is a written waterfall clause naming which vendor pays first, second and third, backed by proof of insurance, not a verbal assumption about who's covering what
Ask a founder running an AI agent stack who pays when it breaks, and you'll get a shrug. Ask the same question about a single SaaS vendor, and they'll point to a specific clause in a specific contract. That gap is the whole problem. The moment you stack a foundation model, an orchestration layer and a data provider into one customer-facing agent, you've built a liability chain with no agreed order, and nobody signs anything that says who goes first.
This isn't a hypothetical. In February 2024, a Canadian tribunal ruled that Air Canada was liable for incorrect bereavement fare advice given by its own website chatbot, rejecting the airline's argument that the bot was "a separate legal entity" responsible for its own words. Air Canada paid damages to the customer. It never got to make the chatbot's vendor pay instead, because nothing in its public-facing contract or its internal tooling agreement had established that order in the first place. The company was the one with the customer relationship, so the company ate the cost, full stop.
Liability waterfalls aren't new. Construction contracts have used them for decades to decide which subcontractor pays first when a building fails. Insurance has used them even longer, stacking primary coverage under excess layers under umbrella policies, each one kicking in only after the layer below it is exhausted. What's missing is the AI-specific version, because the stack itself is new enough that standard vendor paper hasn't caught up.
A typical setup today: a foundation model from OpenAI or Anthropic generates the response, an orchestration layer like LangChain, Microsoft's Copilot Studio, or a custom agent framework decides when and how to call that model, and a data provider feeds it retrieval context, maybe pricing data, maybe medical records, maybe inventory counts. Three different companies, three different contracts, three different liability caps, and in most cases, zero language connecting them. You negotiated each deal separately, probably with different people on different timelines, and nobody asked how they interact.
How to Structure an AI Agent Indemnification Clause Before It Fires An AI agent indemnification clause startup teams sign today rarely covers autonomous action at all, and Air Canada's 2024 chatbot ruling shows who pays when nobody mapped it first: the deployer, not the vendor. - indemnification clause for AI agents in contracts - who pays when an autonomous agent makes mistakes
Read OpenAI's business terms and you'll find liability capped at the fees paid in the preceding twelve months, a standard SaaS limitation. For a startup paying $400 a month in API costs, that's a $4,800 ceiling on what OpenAI owes you if its model output causes a six-figure loss. Anthropic's commercial terms carry a similar structure. These aren't hidden; they're boilerplate, and they exist because no foundation model provider is going to accept unlimited liability for a probabilistic system serving millions of customers. You knew that going in, or you should have.
The orchestration layer is often worse. Open-source frameworks like LangChain ship with no warranty and no liability provision worth the name, because you're not really in a commercial relationship with them, you're using free software. If you're on a managed version, like LangSmith's paid tier, the contract will usually mirror the SaaS-standard low cap. Microsoft's Copilot Studio terms route through the broader Microsoft commercial agreement, which caps liability similarly to the fees paid for that specific service, not your downstream revenue.
Where the money actually lands #
So picture the agent failure Air Canada had: a chatbot tells a customer something wrong, the customer relies on it, and real money is lost. If this were a three-vendor AI stack instead of an in-house bot, here's the order the waterfall actually follows once lawyers sort it out. The data provider is liable only if the underlying data was wrong and its contract doesn't disclaim accuracy, which most data contracts do disclaim, aggressively. The orchestration vendor is liable only if it can be shown the failure was in the routing logic, not the model's output, and that's a hard technical argument to win, let alone prove in court. The foundation model vendor is liable up to its capped amount, usually a rounding error relative to actual damages. And the startup, the one with the direct customer contract, is liable for everything that's left, which in practice is almost all of it.
That's not a theoretical worst case. It's the default outcome of stacking standard-form AI vendor contracts with no waterfall negotiated between them. Each vendor's legal team did its job and protected its own client. Nobody on your side connected the dots, because connecting them requires someone to ask each vendor, during negotiation, "where does your liability cap sit relative to the other two vendors in this stack," and almost no founder asks that question before a deal closes.
Frankly, this is a solvable problem, and the fact that it isn't being solved is a failure of process, not a lack of legal tools. Construction contracts solve it with named subcontractor indemnification chains. Insurance solves it with explicit attachment points between layers. AI vendor contracts can use the same mechanics; they just need someone to insist on it before signing, not after an incident.
What an actual negotiated waterfall looks like #
Start with order of attachment, which is contract language for who pays first. If you're building a customer support agent that pulls product data from a data vendor, routes through an orchestration tool, and generates text through a foundation model, you want language that says the data vendor's liability attaches first for data-accuracy failures, the orchestration vendor's attaches second for routing and logic failures, and the foundation model vendor's liability, capped as it will be, attaches last and only for generation failures traceable to the model itself. That ordering has to be negotiated into each separate contract, because none of these vendors has any contractual relationship with each other, only with you.
Next, push on liability caps that scale with your actual exposure, not with fees paid. A $4,800 cap tied to API spend is fine for a prototype. It's not fine once that agent is making decisions that touch six-figure transactions. Some vendors will negotiate a higher cap for enterprise-tier customers; most startups never ask because they assume standard terms are non-negotiable. They're not, especially once you're spending real money with a vendor who wants to keep the account.
How Does AI Agent Liability Insurance Actually Work? How does ai agent liability insurance work when the product itself takes the action instead of just recommending one? Most startups are still covered by errors and omissions policies written before agentic AI existed, and a growing number of carriers are now writing autonomous-action claims out of the fine print entirely. Here is what the new... - how does AI agent liability insurance actually work - AI agent errors and omissions policy coverage gaps
Insurance fills the gap the contracts won't close. Tech errors-and-omissions policies, and increasingly AI-specific liability riders that insurers like Munich Re and Lloyd's syndicates have started writing since 2025, exist specifically because vendor caps leave so much exposure on the table. If your agent stack touches healthcare, finance, or anything with real downstream harm, carrying your own E&O coverage sized to your actual risk, not to what your vendors are willing to promise, is the backstop that makes the thin vendor caps survivable.
Finally, get indemnification language that's specific to AI failure modes, not generic IP indemnification boilerplate. A clause that protects you against a copyright claim over training data does nothing when the failure is a hallucinated discount code or bad medical guidance. Ask each vendor directly: does your indemnification cover harm caused by incorrect or hallucinated output, and does it cover harm caused by a failure in your integration with the other vendors in my stack. Most will say no to the second part, because they genuinely can't control what happens in your orchestration layer. That's fine. It's still useful to get the no in writing, because it tells you exactly where your own insurance and your own caps need to carry the weight.
None of this is complicated law. It's checklist work that nobody is doing, because the stack is new enough that the standard playbook hasn't been written down anywhere founders actually read before signing. The Air Canada case is the cleanest real-world proof of what happens when nobody does it: the company with the customer relationship pays, regardless of whose code or whose model actually got it wrong.
If you're stacking vendors right now, go pull your three contracts and check one thing: do any of them mention the other two by name, or by function. If the answer is no across all three, you don't have a liability waterfall. You have three separate agreements and a gap where the money will land if something breaks. Also read: How to Calculate Lead Conversion Velocity Before the Blame Game Starts • How to Calculate Your Startup's Support Cost Per Customer • Your AI Vendor Contract Hides Who Else Touches Customer Data
This article is posted in AI News, check it out for more related stories.
Join the discussion #
Open in the community → Almost there. Sign in and your reply posts straight away.