Who's Accountable When the Outcome Doesn't Land?

Last week we asked who gets paid when a deal touches more than one partner. This week's question is the one every CFO asks second, and usually louder: who is on the hook when the outcome everyone was paid to deliver does not arrive?

Picture a deployment that misses. A systems integrator delivered it. A technology partner's model is embedded in the workflow. A platform partner's orchestration agent routed the work between them. The customer signed off on a set of KPIs at the start, and the adoption number lands four points short of the threshold. Nobody did anything wrong in a way a person could point to. The agent made a routing call, the embedded model scored a batch of records, and the integrator's team configured both according to the spec.

Now try to find the contract that says whose miss that is. The customer has a statement of work with the integrator. The integrator has a marketplace or reseller agreement with the technology partner. Each of the three partners has a program agreement with the platform vendor. The orchestration agent belongs to a fourth relationship entirely. Every one of those documents is bilateral, and not one of them was written with an agent's action in mind. The outcome was delivered by four parties. The liability was drafted for two.

AWS's answer, and where it puts the risk

The most important vendor move on outcome accountability so far is the one this series has followed since Week 2. AWS Business Value Realization, covered in depth in Episode 10, ties partner funding to results the customer attests to. AWS's own documentation describes the mechanics plainly: the partner nominates customers and defines the KPIs that measure the business value the customer expects, completes the activities at each stage, and submits KPI progress. The customer attests to the outcomes achieved. "Funding is disbursed automatically at milestone completion, with amounts determined by the size of the opportunity."

Read that sequence as a risk allocation and three things stand out. First, the partner carries the cost of the work up front and gets paid only if the milestone clears, so a missed KPI is unpaid delivery. Second, the payment trigger sits with the customer's attestation, a party with every commercial reason to set the bar high. Third, the public overview is silent on what happens when a milestone is missed, on any repayment provisions, and on how the motion treats more than one partner working the same customer. Those terms may exist in Partner Central. They are absent from anything a partner can read before enrolling.

The program agreement underneath tightens the picture. AWS's Partner Network Terms and Conditions, last updated November 28, 2025, require the partner to hold AWS harmless from any liability "related to any Project, except to the extent directly caused by AWS's acts or omissions," and make the partner "solely responsible for ensuring you are eligible to receive" program benefits. AWS's own liability is limited to a refund of the program fees the partner paid AWS in the prior twelve months. The terms also state that "Nothing in these Terms is a revenue guarantee to either you or AWS."

This is standard program design, consistent with the agreements it was written against. Its effect is to move outcome risk onto whichever partner enrolled the customer. Deloitte's Chris Jangareddy described the BVR toolkit to Channel Dive in June as giving his firm "shared accountability with our customers." That is exactly what it does. The accountability is shared between one partner and one customer. When three other parties shaped the result, nothing in the motion routes any of it to them.

What BlueThread found in the agreements themselves

To see whether that gap is specific to one program or built into the category, BlueThread Research reviewed seven partner agreements that anyone can read in full today. Six are vendor-drafted program agreements: AWS Partner Network Terms and Conditions (November 28, 2025), the Microsoft AI Cloud Partner Program Agreement (last updated March 2024, the version in the public record), the Salesforce Partner Program Agreement (March 11, 2024), the HubSpot Solutions Partner Program Agreement (July 15, 2026), the Atlassian Marketplace Partner Agreement (December 1, 2025), and the Google Cloud Partner Success Services Agreement (June 2019, the oldest in the set and still published). The seventh is the closest thing the industry has to a neutral template, Common Paper's open-standard Partnership Agreement, version 1.1. We read each one against five questions an agentic, multi-party delivery would force.

Does it address actions taken by an AI agent? None of the seven does. Salesforce's agreement is the only one whose operative text mentions AI at all, requiring partners to follow its Artificial Intelligence Acceptable Use Policy. That is a restriction on use, and it allocates nothing. Microsoft's agreement carries AI in the program's name and nowhere in its terms.

Does it allocate responsibility among more than two parties? None does. Every agreement is strictly bilateral, and several say so outright: Salesforce and Common Paper both state there are no third-party beneficiaries. HubSpot comes closest to acknowledging the real shape of the work, noting that a customer's portal "may have more than one Partner involved," and then assigns no responsibility on that basis.

What sets the size of the vendor's liability? In five of the six vendor-drafted agreements, the cap on the vendor's own liability is measured by the partner's relationship with the vendor over the prior twelve months: program fees paid (AWS, Salesforce, Google Cloud), revenue share earned (HubSpot), or Atlassian's own margin on the partner's apps. Microsoft's main agreement sets no fixed cap, though its Partner Center and Store terms limit recovery to the account fee. Not one cap scales with the size of the customer outcome a partner is now being paid to deliver.

Which way do the indemnities run? Mostly from partner to vendor, and broadly. AWS's covers anything related to a project. HubSpot's covers the partner's "participation in the Program." Atlassian's covers content, breach, and security incidents caused by the partner's apps. Microsoft's is the notable exception, written as a mutual defense obligation.

Can either side see what the other's automated systems did? No agreement gives a partner any right to the logs or decision records of a vendor's automated systems. The one inspection right we found, Atlassian's code reviews and scans of partner apps, runs from vendor to partner.

The headline is simple enough to repeat on a call: zero of seven partner agreements address an AI agent's actions, and zero of seven allocate responsibility across more than two parties. The documents governing the most multi-party motion in partnerships today were written for a two-party world.

The Accountability Gap

Put those findings next to the deployment from the top of this piece and the shape of the problem becomes visible. Four parties contributed to the outcome: the integrator, the embedded technology partner, the orchestration agent's operator, and the platform vendor whose funding motion set the KPIs. Contractual liability for the miss sits in one place, with the integrator, through its statement of work with the customer. The integrator's recourse against the technology partner runs through an agreement capped at fees. Its recourse against the orchestration agent's operator may not exist at all, because the two never signed anything with each other. The agent itself, the party that actually made the consequential call, holds no liability under any document, because no document recognizes that it acted.

This is The Accountability Gap: the distance between the parties who shape a multi-party outcome and the parties who hold contractual liability for it. The legal profession is already naming the customer-side version of it. Clifford Chance's February 2026 analysis of agentic AI contracts found that supplier disclaimers routinely cover an agent's actions, that indemnities are usually limited to IP claims, and that liability caps tied to fees paid wipe out "any meaningful recovery precisely when the stakes are highest." The firm's list of what is missing reads like a partner checklist: AI-specific warranties, indemnities for third-party claims arising from agent actions, caps sized to the real exposure, audit rights to logs and decision traces, and the right to suspend or override an agent. Partner agreements sit one layer upstream of those customer contracts, and they are missing every item on the list.

The case against it, and where it holds

Three objections come up whenever a partner team proposes fixing this, and each has a real answer.

The first is leverage. Nobody negotiates the AWS or Salesforce program agreement; it is a click-through, and a partner that redlines it does not get a meeting. That is true, and it matters less than it sounds, because the clauses that close the gap belong somewhere else. They belong in the documents a partner does control: the statement of work with the customer, the subcontract or teaming agreement between partners on a specific deal, and any side letter attached to an outcome-funded engagement. Those get negotiated every week.

The second is speed. Legal review on a multi-party deal already takes longer than sales leaders want, and adding agent language slows it further. The fix is the same threshold discipline Episode 10 recommended for attribution: apply the full accountability package only to deals above a set value, or to any deal where an agent takes actions without human approval or where more than two parties share a funded milestone. Everything below that line stays on the standard paper.

The third is the strongest: existing law already answers the question, through agency principles and ordinary negligence, so why write it down? Because the default answer is the one Clifford Chance describes. When contracts are silent, the loss tends to land on whoever deployed the agent and signed with the customer, regardless of which party's system made the call. For most partner teams in a multi-party delivery, that is the integrator or the enrolling partner, which is to say, probably you. Silence in the contract is itself an allocation. It is just one nobody chose.

The Operator Move: five accountability clauses to raise before your next multi-party deal

Twenty minutes. Pull up the statement of work or teaming agreement for your next deal that involves more than one partner or any agent acting without human sign-off, and check whether it answers each of these.

1. Agent actions are attributable. Each party agrees that actions taken by an AI agent it operates or configures are treated as its own actions under the agreement, and identifies which agents are in scope.
2. A responsibility schedule names every party. One page, attached to the deal, lists every party that contributes to the outcome, including those outside this contract, and states which component of the outcome each one owns.
3. Logs are retained and shared on dispute. Each party keeps the action logs and decision records of its agents for a defined period and provides them within a set number of days when a milestone is disputed.
4. A missed milestone has a pre-agreed allocation. If outcome-based funding fails to disburse, the parties have already agreed how the unpaid work is shared, and what evidence decides whose component caused the miss.
5. Human approval thresholds and a suspension right are written down. The agreement names which agent actions require a person to approve them first, and gives the delivery lead the right to pause any party's agent when a milestone is at risk.

If your current paper answers fewer than three, you are carrying liability for outcomes other parties shape.