Quick answerWhen a platform's AI agent and a partner ISV's AI agent both actively touch the same shared customer account, allocate liability and cost by the action each agent actually took, not by an even split or by which company owns the customer relationship. Before either agent goes live on shared accounts, agree in writing on three things: which agent is authoritative for which category of action on the account, a shared incident log both parties can pull from independently, and a per-incident liability rule tied to whichever agent's action was the proximate cause. Cost-sharing for the AI usage itself should follow a similar principle: allocate spend by which party's product surface triggered the agent call, not by a flat revenue-share ratio that has nothing to do with actual usage.
Why a shared account with two active agents is a different problem than a handoff
A handoff, where one company's agent passes a conversation to another company's agent and steps back, has a clean liability boundary: whichever agent is actively serving the customer at a given moment is the one whose decisions matter. A jointly served account is messier, because both agents can be active on the same account concurrently, sometimes in the same conversation, sometimes across parallel touchpoints, like a platform agent handling billing while a partner ISV's agent handles product usage on the same account in the same week.
That concurrency means a bad outcome, a wrong charge, a contradicted answer, a missed escalation, can plausibly trace back to either agent, or to the interaction between them. Liability frameworks built for single-agent-at-a-time relationships, including standard agent-to-agent handoff design, do not resolve this, because they assume sequential control rather than concurrent, overlapping authority over one account.
Draw the authority boundary before either agent goes live, not after an incident
The single highest-leverage step is agreeing, before the joint arrangement launches, on which agent is authoritative for which category of action on a shared account. A workable split assigns each action type, billing changes, product configuration, support ticket resolution, data updates, to exactly one agent as the authoritative source, even if the other agent can read or reference that data. When a customer asks a question that spans both domains, the agent that is not authoritative for that action should hand off or defer rather than attempt to answer or act on the other party's authoritative surface.
Write this authority map into the partnership contract as an exhibit that both engineering teams can reference directly, not just a prose description in the business terms. Update it any time either company changes what its agent is scoped to do, since an authority map that drifts out of sync with what the agents actually do defeats the entire purpose of having one.
This authority-mapping discipline is the same instinct behind what you actually owe a white label partner after your AI agent goes live inside their product, defining obligations explicitly up front rather than leaving them to be inferred after something has already gone wrong.
Liability allocation: trace to the proximate cause, not a fixed split
Resist the temptation to pre-negotiate a fixed liability split, like 50/50 or proportional to revenue share, for incidents on jointly served accounts. A fixed split is easy to write into a contract but produces bad incentives and bad outcomes in practice, since it pays out the same regardless of which agent actually caused the problem, which weakens each party's incentive to invest in their own agent's reliability on the shared surface.
Instead, build the incident-response process around a shared, timestamped log that both parties can independently query, so that when something goes wrong, the proximate cause, which agent took the action that produced the bad outcome, can usually be identified from the record rather than argued from memory. Contractually, tie liability to that proximate-cause finding by default, with an agreed escalation path (a named neutral reviewer, or a pre-agreed arbitration clause) for the harder cases where causation is genuinely ambiguous, such as a bad outcome that resulted from both agents' outputs compounding rather than one agent's single action. This is a meaningfully different problem from the one-directional cascading automation case, where one agent's output feeds another vendor's system with no human in between; here both agents are independently agentic and can each initiate action, so causation has to be established per incident rather than assumed to run in one direction.
Cost-sharing: allocate by trigger, not by relationship ownership
The AI usage cost question is separate from liability but suffers from the same instinct to default to an easy, wrong split. Whoever owns the customer relationship commercially is not necessarily whoever is driving the AI spend on that account; a platform agent might be doing the bulk of the token-heavy work while the ISV's agent handles a handful of lightweight queries, or vice versa. Allocate cost by which party's product surface actually triggered each agent call, which requires the same per-action logging used for the liability boundary, tagged with a cost attribution field at the point of the API call rather than reconstructed after the fact.
Build a quarterly reconciliation into the partnership agreement rather than trying to get real-time cost-splitting perfectly right from day one. A quarterly true-up against the logged, per-trigger usage data is accurate enough for most partnerships and far simpler to operate than a real-time chargeback system, especially in the first year of a joint arrangement when usage patterns are still settling.
FAQ
What if the two agents give the customer contradictory answers?
Treat this as its own incident category with its own resolution rule, not just a liability question: whichever agent is authoritative for that action type should be treated as correct by default, and the other agent's answer should be corrected and logged as a defect. Track the rate of these contradictions separately, since a rising rate is a sign the authority map needs to be redrawn, not just individually patched.
Should the two companies share a single incident log, or keep separate logs that get reconciled?
A single shared log both parties can query independently is more reliable than reconciling separate logs after the fact, since separate logs invite exactly the kind of dispute over what actually happened that the shared-log approach is meant to avoid. Build it as a joint, append-only record both engineering teams write to and read from, ideally established before either agent goes live on shared accounts.
Does this framework change if one company's agent has much higher account-value authority than the other's?
The authority map should already reflect that by assigning higher-value or higher-risk action categories only to the agent with the appropriate decision-authority tier, rather than trying to fix an imbalance after the fact through the liability split. If one agent is authorized for account-value-tiered decisions and the other is not, that asymmetry belongs in the authority map itself, not layered on top as a liability adjustment.