Acceptance Tests for an AI Sales Agent Before It Touches Live Leads

Do not test an AI sales agent by asking whether the email sounds good.

The email can sound good while the wrong person is selected, a suppression rule is ignored, a field maps incorrectly, a LinkedIn touch duplicates the cold email pitch, the CRM write lands in the wrong record, or a timeout creates the same lead twice.

An acceptance test begins with a controlled input and ends with destination evidence. It defines the expected route before the run, executes in an isolated test scope, injects realistic failures, and compares the final stored state with the expected state.

Acceptance tests are different from prompt tests

A prompt test asks whether the model produced an acceptable answer. A worker-contract test asks whether one component returned the correct schema, evidence, and error. An acceptance test asks whether the business system behaved correctly from source to destination.

The distinction matters because failures often occur between components:

• the researcher returns the right person but the importer maps the wrong email column
• the copywriter uses the right evidence but the sequencer renders a blank variable
• the email sends correctly but the CRM activity attaches to another contact
• the LinkedIn reply arrives but the cold email sequence keeps running
• the tool call succeeds but the destination never stores the expected value

The worker-contract guide covers component outputs. This article covers the end-to-end test that proves those components cooperate.

Build a fixture pack, not one perfect example

A useful fixture pack contains small, controlled records with known outcomes. It should include normal cases, boundary cases, and failures that the agent must refuse or escalate.

Use synthetic test addresses or accounts you control. Never point a fixture at a prospect's real inbox merely because the campaign is paused.

Define the expected result before the run

Every fixture needs an oracle: the exact result the system should produce.

fixture_id
input_record
expected_icp_state
expected_email_state
expected_suppression_state
expected_copy_variables
expected_approval_state
expected_channel_actions
expected_destination_records
forbidden_actions
expected_evidence
maximum_cost
maximum_duration

The forbidden_actions field is as important as the expected action. A suppressed fixture should prove that no email was sent, no LinkedIn message was queued, and no campaign state advanced. Absence must be verified from the destination, not inferred from a local log.

Test the lead decision before the message

The agent should classify each fixture before drafting. Test positive and negative ICP rules, source freshness, person-company identity, geography, seniority, company exclusions, and evidence completeness.

Then perturb one field at a time. Change the job title, move the company outside the geography, remove the source URL, or insert a negative keyword. The route should change for the intended reason. If five variables change together, you learn only that something changed.

Test every variable in the final rendered message

Do not approve a template by reading the source CSV. Preview the rendered email and LinkedIn message exactly as the recipient channel will store or send it.

1. Use unmistakable fixture values for first name, company, role, and personalization.
2. Render every sequence step, not only the first email.
3. Fail on blank variables, duplicated greetings, broken punctuation, or unsupported claims.
4. Verify links, tracking settings, sender identity, and reply-to routing.
5. Export or read the stored lead back to confirm the values survived import.

The cold email campaign import gate provides the CSV, mapping, and reconciliation checks that belong inside this acceptance phase.

Test approvals as durable state transitions

Drafted, QA-passed, approved, executed, and verified are different states. The agent must not turn approval of copy into approval to send, or approval for one campaign into authority over another workspace.

Run these tests:

• approved copy with sending permission absent
• sending permission present for the wrong account or campaign
• approval attached to an older artifact version
• approval revoked before execution
• one approved channel and one unapproved channel
• an action whose recipient count exceeds the approved scope

Each test should fail closed and preserve the narrower state. The agent should surface the exact mismatch instead of searching for another account or broader permission.

Inject failures before production injects them for you

A system that passes only when every API responds quickly has not been tested.

The AI sales agent exception queue explains how these failures should be routed after launch. Acceptance testing proves those routes before they are needed.

Verify the destination, not the tool's confidence

OpenAI's Agents SDK includes tracing for model generations, tool calls, handoffs, guardrails, and custom events. Traces are valuable for debugging what the agent attempted. They are not a substitute for reading the business destination.

Google Sheets can return updated cell counts and, when requested, the values written. Gmail's API returns a Message resource when a message is sent. Those responses are useful transport evidence. For important actions, follow them with a destination read:

• CRM: retrieve the exact contact, company, activity, owner, stage, and external ID.
• Sequencer: inspect the lead, campaign, variables, suppression state, and scheduled steps.
• Google Sheets: read the exact A1 range and compare stored values with the intended row.
• Gmail: search Sent by exact subject and recipient, then read the resulting message.
• LinkedIn tooling: inspect the contact state, queued action, and channel suppression record.

A local artifact, a 200 response, or an agent message saying done is not destination proof.

Test cross-channel suppression

An outbound agent may coordinate cold email and LinkedIn. That makes the shared identity and timeline part of the acceptance surface.

Test at least these transitions:

1. A LinkedIn positive reply pauses the person's remaining cold email steps.
2. An out-of-office email pauses only that contact and does not suppress every colleague.
3. A cold email opt-out blocks future email and any prohibited cross-channel continuation.
4. A referral creates a new candidate without rewriting the original reply history.
5. A duplicate identity across channels resolves to one canonical person record.
6. A human reply owner prevents another agent from sending a competing response.

The exact policy can vary. The acceptance result cannot. Each fixture needs one expected timeline and one readback method.

Turn every incident into a regression fixture

OpenAI's Evals API supports reusable evaluation criteria and datasets, while agent tracing captures the steps inside a workflow. Use both ideas at the business layer: every resolved production exception becomes a fixture with the source input, expected route, forbidden action, and final destination evidence.

Track:

• fixture pass rate by workflow version
• false keeps and false exclusions
• unauthorized action count
• duplicate-write count
• destination mismatch count
• suppression failures
• unknown outcomes left unresolved
• cost and duration per acceptance run

A release passes only when the required fixtures pass. An improved average score does not excuse one critical forbidden action.

A practical release checklist

1. Lock the exact client, workspace, account, campaign, mailbox, Sheet, and CRM test scope.
2. Load the versioned fixture pack and expected outcomes.
3. Run sourcing, ICP, verification, suppression, copy, and mapping checks.
4. Verify approval boundaries and artifact versions.
5. Execute only against isolated test destinations or accounts you control.
6. Inject transient, permanent, permission, partial-batch, and unknown-outcome failures.
7. Read every destination back and compare it with the oracle.
8. Check forbidden actions and duplicate side effects explicitly.
9. Save traces, row-level results, costs, and evidence references.
10. Release only when the critical suite passes with no unexplained state.

Frequently asked questions

How do you test an AI sales agent?

Use controlled fixtures with known expected outcomes, run the complete workflow in an isolated scope, inject realistic failures, and verify the stored destination state. Test what the agent must refuse as carefully as what it should do.

Is a prompt evaluation enough for a sales agent?

No. Prompt evaluations can measure model behavior, but an outbound agent also depends on identity matching, field mapping, permissions, suppression, retries, APIs, CRM writes, and channel state. Acceptance tests cover the assembled business workflow.

Should an AI sales agent send real test emails?

Use inboxes and accounts you control. A real prospect should not become a test fixture. Keep campaign destinations paused and bounded until the complete suite passes.

What is the most important AI agent acceptance test?

The highest-risk test is often a forbidden action: prove the agent does not send, overwrite, duplicate, or switch scope when approval, identity, suppression, or destination evidence is missing.

How often should the suite run?

Run the critical fixtures before every workflow, prompt, model, tool, mapping, or policy release. Run the broader regression pack on a regular schedule and after any incident.

AnswerThePublic research note

The English and United States AnswerThePublic report for AI sales agent showed a seed volume of 1.3K, CPC of US$80.76, and 556 organic variants when reviewed on July 29, 2026. Those figures describe the seed at that review time, not this exact acceptance-testing phrase. The article targets the specific operational intent around testing, evaluation, guardrails, and deployment readiness.

Sources