How to test an AI agent before deployment

This article explains how to test an AI agent before deployment in plain language. An agent is software that takes steps to finish a job. Depending on its task and access, it may read documents, check a calendar or prepare drafts. The introduction to what an agent does explains the broader idea.

Truline provides AI consulting for service businesses. Here, the practical question is whether one proposed workflow is ready for a small supervised trial. The office examples throughout are hypothetical. Use fictional or properly anonymized examples that reflect the work you want to test.

Define the result before you start

You cannot judge a test without a standard. Pick one task the agent would do for your business and describe the finished result you would happily put in front of a client.

For example, imagine a summary of a client meeting. A good result carries the correct date, names everyone who attended, lists the decisions made and gives every action a named owner. It adds nothing that nobody said. Each requirement can be checked against the meeting notes.

Here is a second example, a draft invoice. The standard might read that the client name and address match the current client record, every line item traces to a timesheet entry, and the total adds up. Checkable from start to finish.

Keep the standard specific enough that another person can use it to check the result. If people disagree about what success means, resolve that before judging the software.

Write the boundaries beside the standard. Name the folders and calendars it may access. Specify what it can draft and what needs human approval before sending. Include requests beyond that scope in your tests.

Test ordinary work and likely failures

Start with these situations, then add cases specific to your workflow. Use a practice environment that cannot send messages or change real client records. Make the examples realistic without including confidential information.

Include the person who normally does the task in the review. They can check details that may be easy for somebody else to miss. In an invoice draft, that might be an outdated fee schedule or a changed client address.

Check the output against your written standard. Confirm that the finished record matches the completion message and that no unexpected action occurred. A polished answer does not excuse an incorrect result.

Check a normal request

Ask for the normal task, done the normal way. Using the meeting example, ask it to summarize yesterday's client meeting and list the agreed actions.

What works is a summary that meets your standard line by line. What fails is a fluent summary with an invented action item. Check every decision and action against the meeting notes, even when the writing sounds convincing.

Make a required detail unavailable

Remove the date from both the request and the practice notes, leaving no approved source for it. Then ask for the meeting summary. If the date is available elsewhere in the approved material, using it correctly is not a failure.

What works is a question about which meeting you meant, or a draft that clearly marks the date as missing. What fails is a plausible date filled in without evidence. An unsupported detail can look just as convincing as a supported one.

Supply conflicting information

Give it a decision it cannot make on its own. For example, prepare an invoice for a client whose file shows two different addresses, and do not say which one is current.

What works is a stop and a question about which address applies. What fails is a silent choice between conflicting records. Include the conflicts your staff encounter, such as different versions of an engagement letter or an old fee schedule beside a new one.

Interrupt a tool connection

An agent may depend on documents, a calendar or another application. In the practice environment, make a test folder unavailable, then request a summary that depends on it. Keep this test separate from live client work.

What works is a report that the notes cannot be reached and the summary remains unfinished. What fails is invented content or a message claiming that a summary was saved when nothing exists. The response should identify what failed and what needs a person to act.

Test requests beyond the approved scope

Remind yourself what you approved, then ask for something next to it. If the agent is approved to draft invoices, ask it to email the client's bank directly. If it may read one client folder, ask about a different client.

What works is a refusal, or a request for approval that waits for a person. What fails is carrying out the action anyway. Check that the action was prevented, including when the request is repeated or phrased differently.

Check the result behind the message

After every test, compare the completion message with what actually changed. Open the summary file, calendar entry or drafts folder. A completion message needs evidence in the place where the work should appear.

In the meeting example, the agent may say the summary is saved and the follow-up email is drafted. Open both. Check the date on the summary, the recipients and attachments on the draft, and whether anything already there got overwritten.

What works is a record that matches the message. What fails is a draft in the wrong folder, an incorrect appointment time or no saved draft at all. Agree who checks the results during the trial and how often, based on the consequences of an error.

Ask the seller to show failures

Once the ordinary demonstration works, change an input or make a required practice resource unavailable. Ask the seller to run a summary request without a date. Ask for something outside the approved scope. Watch what the software does, then inspect the result together.

Then watch which of three things happens.

It stops and says it cannot complete the request. That is the outcome you want.

It stops and asks you for the missing piece. Also good, and better still when the missing detail is one you can supply.

It carries on and reports that the job is done. Check that completion claim against the record. If the record is empty while the message says success, you have found a specific failure to repair and test again.

If the seller cannot demonstrate a behavior, record it as unverified and ask what evidence they can provide.

Keep consequential actions under human review

A draft can be revised before it is shared. Decide which actions need review before they happen.

The working rule for a first deployment is simple. The agent prepares, a person reviews and a person sends. Test the rule like everything else. Try to get the agent to send directly, politely first and then insistently.

What works is a draft that waits for approval, however the request is phrased. What fails is a message sent before that approval. Test both that approval is requested and that the action waits for it.

Uncertainty also needs a clear handover. When information is missing, the software should explain what it needs or leave the decision with a person. Check that the reviewer receives enough context to decide what happens next.

Repeat tests after each change

The same request can produce different drafts on repeated attempts. Different wording may be acceptable, while different facts may fail your standard. Check the result rather than requiring identical sentences.

Repeat important tests using the same practice inputs. After a change, check the affected behavior and earlier cases it could disturb. A new instruction, changed folder or removed tool can affect more than the immediate task.

Updates to the underlying software or model can affect behavior. Ask your supplier how changes are communicated and which tests are repeated before an update reaches your workflow.

What works is meeting the same standard across repeated attempts. What fails is an invented date appearing in a later run of a case that passed before. Repetition helps reveal variation that a single successful demonstration can miss.

Save failed examples for future tests

Every failure you find is worth keeping, because old mistakes come back after changes. Keep one list. For each failure, write what you asked, what a good result would have looked like, and what actually happened.

The missing-date example becomes a standing test you can repeat after changes. Record the version tested and the observed result. Keep the examples free of unnecessary confidential details and limit access to the people who need them.

Expand the trial when checks hold

Use these examples as a starting set, then add tests for your workflow and its risks. Agree the conditions for a small supervised trial before it starts. Choose a narrow task with a named person responsible for checking the results.

The agent prepares the work and the reviewer checks it. Keep the trial narrow enough that the reviewer can examine the results and stop it when a problem appears.

Expand in steps, beginning with more examples of the same task under supervision. A different task needs its own standard and tests. Change one thing at a time where practical, so you can tell what affected the results.

There is no universal pass mark or fixed number of runs that qualifies a workflow for client work. The consequences of a mistake should help determine the testing effort. An internal draft and a message sent directly to a client need different oversight.

Copy this worksheet for your first trial

Keep this table beside you during the trial and fill it in as each test runs, not from memory afterwards. One row per test. The example row is hypothetical, to show the level of detail that makes the sheet worth keeping.

Add a row whenever the software surprises you. Surprises, good or bad, are the tests you did not know you needed.