How to assess a recommendation for an AI tool

Consider a fictional company that receives employees’ IT requests in a shared inbox. An AI assistant is supposed to read each message and send it to the right person. An employee writes: “I need new software.”

They may want to buy an application, obtain an already-purchased licence or repair software that will not start. Those situations belong with different people. A useful demonstration shows how the assistant clarifies the request and how its recipient can handle it. Quickly classifying the message does not establish that the employee’s problem will be resolved.

Start with a request the team understands

Choose a recent request and walk through it with the people who handled it. Record what the employee needed, which information was required and where time was spent. Use that case to assess the proposed solution, removing confidential information from the demonstration.

If messages wait several days because nobody checks the shared inbox, better text interpretation will leave much of the delay intact. The company also needs to decide who receives requests and when that person takes responsibility for them.

Anthropic’s recommendation to start with a simple solution suggests a practical question for the provider: which observed difficulty requires the proposed design? A form may suit a predictable request. AI may help interpret varied messages. The choice should be explainable through the work that needs doing.

Ask for an explanation when the assistant makes a mistake

Suppose the assistant sends a purchase request to technical support. Before switching tools, examine the information it received and the rule it was supposed to apply.

What you observe	What to examine next
The message does not distinguish a purchase from a repair.	Identify the question the assistant should ask the employee.
Two managers give conflicting instructions.	Clarify who handles the request and under which conditions.
The rule exists, but the assistant cannot access it.	Check how the application supplies that information.
The rule and details are available, but routing is still wrong.	Compare instructions and tools using the same requests.

These checks require understanding the company’s work as well as the software. Useful expertise includes connecting an error to its cause, then showing that a correction helps with other comparable requests.

Keep some difficult cases for later trials. Anthropic’s work on evaluation recommends explicit tasks and success criteria. For this company, a properly handled request reaches someone able to act, with the information they need.

Review the proposal as a nontechnical founder

You can ask for this explanation without writing code. The provider should be able to show what the user will do, what the system will check and what happens when information is missing.

Also ask who will maintain the solution and which changes will require a developer. That helps you compare the purchase cost with the work needed after launch. A tool that is easy to demonstrate may still need connections and rules specific to your company.

In founder mentoring, these questions help you examine options and prepare a decision. You or your developer carry out the implementation. Detailed code analysis or building the system requires a separate engagement.

Keep the cases that let you compare tools

After a trial, retain examples of misrouted requests, missing information and the corrections made. Record the time employees spend redoing the assistant’s work as well.

When another tool is proposed, test it against these same situations. You can then ask exactly what it improves, which difficulties remain and how much preparation it requires. This set of examples remains useful when the team changes platforms.