Want help applying this guide?Ask the DripTell team
Meta now gives teams two practical ways to test Meta Business Agent before opening it to every customer. Use Agent Test for fast, repeatable checks through the agent pipeline. Then use an allowlisted conversation to prove the real WhatsApp operating path. Neither should be treated as a complete release decision on its own.
That sequence matters because a correct answer in a test call does not prove that the right person receives a handoff, that conversation context survives, or that a downstream action is safe. The useful question is not simply whether the agent works. It is which evidence you have collected before customers depend on it.
This guide focuses on the Business Agent Platform path. If you are still deciding whether a phone number is eligible or who should own each state, start with DripTell's Meta Business Agent eligibility and ownership guide.
The two testing routes do different jobs
Meta's current Agent Test reference says the endpoint sends a test message through the full agent pipeline without requiring a real consumer phone number. The consumed test tokens are not billed. Its response can include the answer, a conversation identifier, and reasons for a handoff or no response.
Meta's Agent Settings reference describes the second route. Set the audience to ALLOWLISTED_ONLY and the enabled agent responds only to consumers on the channel allowlist. Meta says that restricted rollout does not require a payment method. Expanding the audience to EVERYONE does.
| Test route | Best use | What it does not prove alone |
|---|---|---|
| Agent Test | Repeatable answer, knowledge and connector checks | Real consumer delivery, webhook routing and staff takeover |
| Allowlisted conversation | End to end behavior with a controlled real consumer | Performance and safety across every customer type |
| Public rollout | Real operating outcomes under normal traffic | That an untested failure will be harmless |
The first route is a lab bench. The second is a dress rehearsal. Public rollout is the live service.
Start with Agent Test for repeatable checks
Begin with a small test set that anyone on the team can rerun after a knowledge, skill or connector change. Keep the inputs and expected outcomes in version control or another reviewed record. A useful set covers four types of behavior.
- Answer evidenceRun repeatable prompts against approved facts, unsupported questions, action requests and handoff triggers.
- Conversation evidenceContinue a test conversation and check whether context, corrections and escalation remain coherent.
- Operational evidenceUse an allowlisted consumer to prove delivery, ownership, handoff and the receiving team's view.
- Release evidenceRequire named owners for failures, a rollback condition and a deliberate decision before expanding to everyone.
First, ask ordinary questions whose answers appear clearly in an approved source. Second, ask questions that the business has not answered and confirm that the agent does not invent a policy. Third, request actions with different authority levels, including one action the agent must refuse or hand over. Fourth, trigger a human handoff deliberately.
Do not score only tone and fluency. Record the source used, fields collected, action attempted, owner selected and reason for any stop. The DripTell AI workspace uses the same practical idea: an answer is useful only when approved knowledge, customer context and the next accountable action stay connected.
The current API schema also accepts a conversation_id from a previous test response. That means you can continue a multi turn test instead of assuming every call must be isolated. Keep isolated cases as well because they are easier to compare after each change.
Use an allowlist for real conversation behavior
Move to the allowlist when the answer layer is stable. Use actual team members as controlled consumers and rehearse from the devices, hours and languages the service will encounter. This stage is not just another content check. It tests the boundaries around the agent.
Confirm that an incoming message reaches the expected owner, that the agent responds only for allowlisted consumers, and that staff can see the whole exchange after a handoff. In a shared inbox, the receiving person should see the customer, prior messages, handoff reason and next task without asking the customer to repeat everything.
Test a downstream failure on purpose. Make one connector unavailable in a safe environment or use a test record that cannot complete. The agent should stop clearly, preserve what it knows and route the case according to policy. Then verify that workflow automation does not keep sending after a person takes ownership.
Run one evidence based test plan
A release plan should name the evidence, owner and stop condition for every critical journey. Pick real tasks such as checking availability, changing an appointment, requesting a refund or qualifying a sales enquiry. Avoid polished demo questions that never challenge policy.
For each journey, record:
- the approved source for the answer;
- the fields the agent may collect;
- the action it may read or write;
- the event that requires a person;
- the team that receives the handoff;
- the result that blocks public rollout.
Check the resulting identity and history in the customer record. A test should fail if the answer lands on the wrong customer, if duplicate records are created, or if an unresolved case loses its owner.
Do not hide failed cases in an average score. A single unauthorized action or lost handoff may be more important than twenty correct opening hour answers. Classify failures by consequence, fix the highest risk path, and rerun the same case through Agent Test and the allowlisted conversation.
Know what free testing does not prove
No charge testing reduces the cost of learning. It does not remove the need for release control. The test endpoint cannot by itself prove real delivery, mobile behavior, webhook processing, human workload or customer understanding. An allowlist cannot represent every accent, writing style, product exception or bad actor.
Before expanding the audience to everyone, require a named decision maker, a visible way to disable the agent, a human takeover path, and monitoring for unsupported answers, failed actions and unowned conversations. Meta notes that disabling the agent stops it responding on all threads, while enabling it again applies to new threads. Include that behavior in the rollback plan.
DripTell can help a team place AI responses beside automation, the inbox and customer context, but the release standard should remain independent of any vendor. If you want to talk through the operating model, bring one real journey, its failure cases and the evidence collected from both test routes.
Frequently Asked Questions
Is Agent Test free to use
Meta says tokens consumed through the Agent Test endpoint are not billed. That does not mean production Meta Business Agent traffic is free, and it does not cover costs in other systems your test may call.
Can Agent Test handle a multi turn conversation
Yes. The current response includes a conversation identifier, and the next request may supply it to continue the test. Keep separate isolated cases as well so regressions remain easy to compare.
Do I need a payment method for allowlisted testing
Meta says an agent limited to ALLOWLISTED_ONLY can be turned on without a payment method. A payment method is required when the audience expands to EVERYONE.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy