The demo has a beautiful interface. Can your agent use the software?

Suppose you're buying a new order-management system. The salesperson finds a customer, changes a delivery address and sends a confirmation before you've finished your coffee.

Your operations team likes it. Then someone asks whether an AI assistant could prepare that same change from a customer email.

“Yes, we have an API.”

Keep the demo open. You still need to see what that answer buys you.

An API is a way for software to communicate with other software. Its existence doesn't tell you which actions are available, who can authorise them or what happens when a request fails halfway through. Those details will shape the integration your team can build later.

Ask for one ordinary transaction

Choose a task your people already perform. For the order system, use a delivery-address change on an unshipped order. Keep it inside a test environment with sample data.

Have the supplier show the entire path. The assistant reads the order, checks whether it is still editable and prepares a proposed address. A person approves the change. The system records it, and the assistant checks that the new address was saved.

You don't need an autonomous agent for the demonstration. A technician can call the supported interface directly. You're testing the application's capabilities before deciding how much judgment to give an agent.

Record where the supplier switches from a supported function to a workaround. If changing an address requires a browser robot to find a button, that may still be usable. It comes with a different maintenance burden, especially if the interface changes. Put that burden in the buying decision.

Make the permissions visible

Ask for an account dedicated to this workflow. It should have the access the task needs, with unrelated actions excluded.

In this example, an assistant might need to read an order and propose an address change. It shouldn't receive the right to issue refunds simply because a shared administrator account makes the demo easier.

Test the boundary. Try an action the account should be unable to perform and inspect the rejection. Then look at the activity record: can someone identify the account, the exact change and its time? If a human approval is required, can it be tied to the version that was actually executed?

That last question matters when work changes while approval is pending. The customer may revise the address again. Approval for the first address should not silently authorise the second.

Interrupt the demonstration

Ask the supplier to repeat a request after a simulated timeout. Does the software recognise the original operation, or create another one?

For an address update, repetition may be harmless. For a shipment, charge or notification, it can have consequences. The answer should explain how the caller checks an uncertain result before trying again.

Also test an expired login and an order that can no longer be edited. A useful failure gives the integration enough information to stop or route the case to a person. A generic error followed by blind retries is a problem your team will inherit.

Finally, inspect recovery. Some changes can be reversed. Others need a compensating action, such as cancelling an unprocessed request. A message already sent cannot be unsent by restoring a database field. Write down which situation applies.

Put today's capabilities in the buying record

Your procurement notes should distinguish four things: demonstrated now, documented but not tested, promised for later, and unavailable.

Alongside each essential action, record the subscription tier, usage limits and any extra charge. Check how the supplier announces interface changes and how long it supports the previous version. Ask whether your team can export the records needed to investigate a failed operation.

This doesn't mean rejecting useful software because it lacks a fashionable agent feature. A stable, supported interface with suitable permissions may serve the job perfectly. If the purchase is already justified for human users, a manual handoff may be acceptable for the first implementation. Price that work honestly.

At Solve IT, we examine the workflow and connect the systems that can support it. Before you commit to a new application, that means identifying which operations an assistant would need and testing the uncertain parts within an agreed scope.

Request a Strategy Session

Bring the order you want to change and the supplier's answer about its API.