The problem
You run a small agency that sells a medical supply company a service. It checks incoming referrals and flags the ones missing paperwork before an order is placed. The service uses a payer-rules feed you license from someone else. It uses an automatic check a former colleague built. And a nurse you contract reviews the hard cases.
On a Tuesday, the payer feed is a week out of date. Three referrals get flagged wrong. The client calls you. Not the feed company. Not your former colleague. Not the nurse. You.
A Canadian tribunal said the same to an airline in 2024. Air Canada's chatbot gave a passenger wrong advice about a fare. The airline argued that the chatbot answered for itself. The tribunal member wrote:
"In effect, Air Canada suggests the chatbot is a separate legal entity that is responsible for its own actions. This is a remarkable submission."
The airline paid. Whoever sells the result answers for every part in it, including the parts they did not build.
You had never written down who answers for what. So you spend the week being the help desk for three other people's work, and you eat the cost. If you have searched for an AI agent SLA template, or asked who is liable when an AI agent makes a mistake, this is the situation behind the search.
Why this keeps happening
A finished AI service is almost never made by one person. It stacks up. Someone supplies the data the AI must not guess at. Someone writes the rules for the line of work. Someone builds the automatic check. Someone reviews the hard cases. You put it together and sold it.
The client bought one thing from one name: yours. That is right. A client should not have to chase four vendors. But it means every promise you make is only as good as the weakest supplier under it. If the feed company will not commit to a freshness date, you cannot promise one either.
There is an upside hiding in this. As of July 2026, Avalara surveyed more than 1,500 finance leaders. Nearly a quarter, 23 percent, said that if an AI tool made a serious error, it was unclear who in their company would answer for it. A seller who puts their own name on the result is offering something one buyer in four cannot get in-house.
| Who answers for | You, the seller | The person who built the part |
|---|---|---|
| The promise and the price | You own it, within the terms you wrote | Nothing |
| The client's calls | You are the only phone number | Answers to you, under your deal with them |
| The data being current | You choose the supplier and pin the version | Keeps it current and says how often |
| The rules being right | You decide which rules the service uses | A named person keeps them dated and correct |
| The hard cases | You price and route them | The named reviewer decides and stands behind it |
| Refunds | Your terms; a rejected job is refunded | Their earnings follow the same record |
It costs you in hours first: unplanned help-desk weeks. Then in trust: the client does not care whose feed was stale. Then in money: refunds you did not price for, and suppliers you cannot charge back because nothing was agreed. In a healthcare setting it can cost more than that. A wrong flag on a referral delays a patient's equipment. That is why healthcare AI agent exception queues get so much attention: the hard cases are where the harm is.
How to fix it
Write it down before the next Tuesday. This is an AI vendor contract requirements checklist, from the seller's side. Each item is one or two sentences in your terms.
- State the result in one sentence, and what counts as a rejected job. "Every referral is checked against this week's payer rules before 9am; a check made against stale rules is a reject."
- Name the path for hard cases. Who looks at them, how fast, and what the client sees while a case waits. A queue of flagged cases is part of the product, not a failure of it.
- Promise only response times you control. How fast you reply. How fast a case reaches a person. Not how the AI will behave on every input.
- List the parts you did not build. Which data comes from whom. Which rules have a named keeper. Which steps are a person.
- Get each supplier to commit in writing to what you are promising the client. If they will not, do not promise it.
- Pin the version. Say which version the client is on, how much notice they get before a change, and what a supplier's price change does to theirs.
- Tie refunds to a rejected job and a record, not to a phone call. Keep a small reserve for them.
- Write the exit. How they cancel, how they switch off your access to their systems, and how they get their results and records out.
Two of your existing playbooks help here. Healthcare AI agent exception queues shows the hard-case queue in a regulated setting like the one above. Approval fatigue in review queues explains why the reviewer must only see the flagged cases, or the queue dies. And change management and versioning covers the notice-before-change habit.
What BlueBear's marketplace does about it
BlueBear's marketplace is built around the same idea: one seller answers to the buyer, and the record pays everyone else. Here is what it does for you today.
The buyer purchases one result from you at one price. You are the seller named on the offer page, and the terms on that page are what you answer for. The other people whose parts sit inside your offer never become the buyer's problem.
Every job produces a receipt. It shows what ran, which version, what it cost, and who signed off if a person did. It also records which parts did work: whose data, which rule, which check, which reviewer. When a client calls about a stale feed, you can see in one place what happened and when.
Earnings for you and for the others are worked out from that record and written to a ledger that is only ever added to. If a job is rejected, the buyer is refunded, and the reversal is recorded the same way for everyone. Nobody has to argue about shares after the fact.
The big software stores mostly go the other way. As of September 2026, Microsoft's marketplace says offers billed on use after the fact are not eligible for refunds. A refund on a rejected job is more risk than that norm asks of you. The receipt is what makes it bearable. It settles the argument before it starts.
In the pilot there is a reviewer queue. A named person sees a result before it goes out, records corrections, and either signs it off or declines it. Only a signed-off result is released. That is how the nurse in the story becomes part of the product rather than an afterthought.
Two rules to know. People in regulated professions, such as lawyers, are paid a fee per review and a licence for their rules. They are not paid a share of the sale, because their professional rules usually forbid fee splitting. And payouts in the pilot are done by hand. Publishing is by invitation, and BlueBear lists your offer for you.
What to do next
Take the eight-item list above and fill it in for your busiest service this week. Where an item is blank, that is your next Tuesday. Where a supplier will not commit, that is a term to remove or a supplier to replace.
Have you priced the reviewer's time and the refund reserve into the job yet? If not, do that first. Why your AI service loses money on small jobs has the worksheet. Then look at how a live offer states its terms and its reviewer step to a buyer on /marketplace.
Questions people actually search for
- who handles support when an ai solution has multiple vendors
The seller who listed it. On BlueBear's marketplace a buyer purchases one result from one seller, and that seller answers for support and results within the terms on the offer page. The people who built parts inside it, such as a data feed or a checking rule, answer to the seller, not to the buyer. They are paid from the receipt for each job their part helped with. Write your support terms as if yours is the only phone number the client has, because it is.
- what should an ai agent sla actually promise
Promise what you control and can show. How fast you answer a support request. How fast a hard case reaches a named person. That the service is up. Which version the client is on, and how much notice they get before it changes. A refund path with clear rules. Do not promise the AI will give the same answer every time. Back each promise with something a receipt or a review record can prove, so a dispute is settled on evidence, not memory.
- how are refunds handled for ai agent outputs
Tie refunds to a rejected job, not to general unhappiness. On BlueBear's marketplace a rejected result is refunded to the buyer, and every job has a receipt that shows what ran and what was charged. In the pilot a named person can correct or decline a result before it goes out, which stops most refunds before they start. Put the reject rules on the offer page so both sides know what counts, and keep a small reserve for the ones that happen anyway.
- how do contributors inside an ai solution get paid
From the receipt. Each job's receipt records which parts did work: whose data was used, which rule fired, which automatic check ran, who signed off. Earnings for each contributor are worked out from those records and written to a ledger that is never edited, only added to. If a job is refunded, the reversal is added the same way. In the pilot BlueBear works out the amounts and pays people by hand. The buyer never sees any of this; they see one price and one seller.