Reference Check Questions for an AI Vendor: What to Ask Customers

The most useful reference check questions for an AI vendor are about life after launch: how problems were reported and fixed, how changes were approved, who held access, and what leaving would involve. A reference who can describe one specific bad week and the provider's response will tell you more than one who says the work went well. Ask for events instead of opinions, and compare the answers with what the provider promised during the sales process.

Key takeaways

• Ask what happened after launch. Demos and kickoffs are easy to polish, while behavior several months in is not.
• Ask for events, not opinions: a specific incident, a specific change, a specific disagreement.
• Cover five areas: the first weeks, incidents, changes, access and data, and exit or renewal.
• Pick references that resemble your situation, and include someone who works with the agent daily, not only the sponsor.
• Treat vague answers and declined questions as information, then verify with documents and a small test.

Why do AI references need different questions from other software?

A reference call for ordinary software usually confirms that the product works and that the vendor answers email. An AI agent is different because its behavior depends on several moving parts: the model underneath, the instructions, the memory it draws on, the tools it can call and the permissions it holds. Any of these can change after launch, and a change in one can alter what the agent does without anyone touching the others.

That is why the revealing part of the relationship starts when the project team steps back. Someone has to watch the agent, decide what counts as a failure, approve changes and review access. A reference can only describe that work if you ask about it directly.

Keep in mind that references are chosen by the provider and are usually invested in their own decision. That is not dishonesty, only a bias to account for. The same caution applies to published stories, covered in How to Evaluate AI Case Studies Without Being Misled. A call is worth more when your questions are concrete enough that polite, general answers are hard to give.

How do you set up a call that produces honest answers?

Preparation matters more than the script. Use this plan:

• Ask for references that resemble you in the role the agent plays, the channels it works in and the size of the team around it.
• Request one reference that has been live for a while, not only recent launches, and ideally one that went through a rough patch.
• Ask to speak with the person who works with the agent day to day, in addition to the executive who signed.
• Share the topics in advance (first weeks, incidents, changes, access, exit), but keep the exact questions for the call.
• Take notes in the same format on every call so you can compare them side by side.
• Close each call with two open questions: what would you do differently, and what should I have asked that I did not?
• Write down what the reference could not answer. Unknowns often point to work the provider did without telling the customer.

What should you ask about the first weeks after launch?

The early period shows whether the provider stays engaged once the contract is signed. These questions work well:

• What did the agent get wrong in the first weeks, and who noticed first: your team or the provider?
• When you reported a problem, how long passed before the agent's behavior actually changed?
• Did the scope that was sold match the scope that ran? What was added or quietly dropped?
• How much of your team's time did the agent need each week, and was that what you expected?
• What did your staff stop trusting, and what did they come to rely on?
• Did the provider ever tell you about a problem you had not noticed yourselves?

The last question is the strongest. A provider who volunteers bad news before you find it is monitoring the agent. A provider who answers only when asked is waiting for you to complain. For a picture of what a healthy opening period can look like, see What the First Months With a Managed AI Agent Look Like.

Which questions reveal how incidents and changes are handled?

Incidents and changes are where providers differ most, and where a customer's memory is usually detailed. Ask for the story, not the policy.

• Describe the most serious incident so far. What happened, how did you hear about it, and what did the provider do in the first hours?
• Was there a written explanation afterward, and did it lead to a change in how the agent is run?
• When the underlying model or a connected system changed, who told you, and was it before or after the change took effect?
• How do you request a change? Who approves it, and can you see what changed afterward?
• Has a change ever made things worse? How was it undone?
• Can you see what the agent did yesterday without asking the provider?
• Has the provider ever declined something you asked for? What was the reason?

The change questions map to a process you should expect from any provider, described in How to Request and Approve Changes to a Managed AI Agent. The visibility question relates to observability, which the OpenTelemetry primer describes as understanding what a system is doing from the records it emits. If the customer depends on the provider to explain every behavior, the monitoring is probably a private service rather than a shared record.

The question about refusals deserves attention. A provider that has said no to a risky or poorly defined request is protecting the customer. A provider that has never said no may simply be agreeable, which is not the same as careful.

What should you ask about access, data and leaving?

These topics feel legal or technical, so references often skip them unless prompted. Prompt them.

• Which systems can the agent read, and which can it change? Who decided that?
• Has anyone reviewed and reduced the agent's permissions since launch?
• Where do the agent's memory and logs live, and who on your side can see them?
• Did the provider state in writing whether your data is used to train any model?
• Could you export the instructions, memory, configuration and logs if you left? Has anyone tried?
• What changed between the pilot and the renewal conversation, in scope and in terms?

The OWASP authorization guidance describes least privilege: give each actor only the access its task requires. A reference who cannot say what the agent is allowed to do suggests that the provider holds that knowledge alone, which makes every later review harder. On the exit questions, a customer who has never tested an export cannot know whether it works. That gap is worth raising with the provider, and How to Avoid AI Vendor Lock-In With Business Agents explains what to ask for.

How should you read the answers?

A reference call produces impressions. Turn them into a decision with a simple guide:

• If the reference names a specific incident and a specific fix, give it heavy weight. Detail is hard to invent.
• If answers about changes are vague, ask the provider for a sample change record and compare.
• If the reference cannot describe the agent's permissions, assume the provider is the only one who knows them.
• If every answer is positive and general, request a second reference and ask for someone closer to daily operation.
• If the reference mentions a refusal or a pushback from the provider, treat that as a mild positive signal.
• If the provider declines to arrange any call, ask for an anonymized conversation or written descriptions, and weigh the refusal.

Illustrative scenario: a buyer calls two references. The first, a senior executive, says the agent is excellent but cannot say who approves changes. The second, an operations coordinator, describes a week when the agent gave outdated answers after a connected system was updated. She says the provider flagged it before the team did, sent a written account and added a check afterward. The buyer weights the second call more heavily and asks the provider for the change records behind the first customer's praise.

No single call settles the matter. Combine what you hear with a small, scoped trial, as described in How to Test an AI Vendor's Claims Before You Commit.

What should a provider show next to the references?

References describe the past experience of other companies. The provider should also be able to show how it works, in documents you can inspect. Ask for a sample monitoring report, a sample change record, the permission review routine, the incident process and the terms for export and exit.

Be Human takes this approach to managed AI infrastructure. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, with the agent's identity, memory, channels, tools and permissions kept under the customer's control. These are the same items worth asking any provider to evidence, because they are what a reference's stories should be matched against.

For a wider set of checks on a provider's behavior, Red Flags When Hiring an AI Implementation Partner is a useful companion, and the NIST AI Risk Management Framework offers a neutral vocabulary for governance questions if your company needs one.

Frequently asked questions

How many references should I ask for? Two or three is usually enough if they differ in useful ways: one long-running, one recent, and one that went through a difficult period. More calls add little unless the answers conflict. If they do conflict, pursue the difference rather than averaging it.

What if the provider says its clients are confidential? Confidentiality is common and legitimate, so offer alternatives: an anonymized conversation, a written description approved by the customer, or sample operating reports with identifying details removed. If none of these is possible, shift weight toward a scoped trial where you can observe the provider's behavior yourself.

Should I contact customers the provider did not suggest? Yes, if you have a natural connection, such as a peer at another company or someone in your professional network. Be transparent about why you are asking, keep the request light and never ask for confidential information. Unprompted views tend to be less polished, which makes them more informative.

How long after launch should a reference have been running? Long enough to have experienced a change in the underlying model or a connected system, a permission review, and at least one staff change on their side. Those events test how the provider behaves when things shift. A very recent launch can tell you about implementation, but not yet about operation.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.