Industry
Phone checks for an AI voice agent
An AI voice agent that dials a bad number wastes a call, a minute of speech and text-to-speech spend, and a slot in your queue. A small gate in front of the dialer can stop most of that. This post lays out which checks belong in the gate, which LookValid product answers each one, and what the agent should do with the answer.
Check the number before the agent speaks
Every number your agent handles should be stored in E.164, the ITU-T numbering plan format of a plus sign, a country code and the national number 1. The first gate question is whether the number can exist at all in that plan. If it cannot, nothing downstream matters, and the agent should never place the call.
The phone check answers that question against the numbering plan. It returns the E.164, national and international formats, the country and a number type taken from the plan. A number the plan rejects comes back as found: false with the reason, and it is not charged. The same product also accepts a two-letter country hint for numbers written without a country code, and assumes US when you give none.
What it does not do is contact a carrier. It cannot tell you that a line is switched on, reachable or ported, and its carrier field is always null. Treat it as a format and plan gate, nothing more.
The pre-dial gate
Four questions cover most of what a team can learn about a number before dialing or answering, using data that is public and cheap to read. The table maps each one to a product.
| Check | LookValid product | What the result means | What the agent should do |
|---|---|---|---|
| Format and numbering-plan validity | Phone, 1 credit | found: true means the number is valid in its country plan. found: false means it is not, with a reason. | Store e164. On found: false, drop the number and do not dial. |
| Line type | Phone, number_type in the same result | The type the plan assigns: mobile, fixed_line, fixed_line_or_mobile, voip, toll_free, premium_rate and others. It comes from the plan, not from a carrier. | Route by type: skip premium_rate and shared_cost numbers, and tag fixed_line_or_mobile as unknown for scheduling. |
| Original carrier (US numbers) | Carrier lookup, 1 credit | The carrier the number block was first assigned to, from public NANPA reports. ported is always unknown, so a moved number still shows its first carrier. | Use it as a hint for routing and reporting. Never treat it as the current carrier. |
| Complaint history of a caller ID | Phone spam check, 1 credit | A 0 to 100 score from public FCC consumer complaints, with a risk level of low, medium or high. A number nobody reported is found: false. | Run it on the numbers your agent calls from. If the risk is medium or high, look into the complaints on your own campaigns and fix the cause. |
Pre-dial gate: check, product, meaning, action
Run together on one number, the gate costs 3 credits: 1 credit for the phone check, 1 credit for carrier lookup and 1 credit for the complaint check. In practice the phone check goes first and the other two only run on numbers that pass it, so a rejected number costs nothing.
Check your own caller ID too
Most teams gate the numbers they call and forget the one they call from. The phone spam check takes any number and reports how often it has appeared in FCC consumer complaints, along with the first and last report dates, the issue types and a score. The score is the sum of three parts: how many complaints exist, how recent the newest one is, and how serious the reported issue types are. More and newer complaints never lower it.
Read the score as a count of reports, not as a verdict. Complaints are unverified consumer reports, and a number can be spoofed, so a high score on a number that is not yours may describe someone else. A high score on a number you do own is a reason to investigate the complaints on your own campaigns.
curl -X POST https://YOUR_API_HOST/v1/phone-spam \
-H "Authorization: Bearer $LOOKVALID_API_KEY" \
-H "Content-Type: application/json" \
-d '{"phone":"+12025550143"}'
Check the caller ID your agent dials from
When the agent answers instead of dials
An agent that picks up inbound calls sees a caller number it cannot trust on its own. STIR/SHAKEN is the standards work for this: RFC 8224 defines a SIP header field carrying a signature that identifies the originator of a request 2, and RFC 8225 defines the token whose claims hold the originating telephone number 3. Whether a call carries a valid signature is decided in the carrier network, so your agent only sees it if your telephony provider passes it along.
The checks above still help on the inbound side, within their limits. Run the phone check on the caller number to confirm it is well formed and see its plan type, and run the complaint check to see whether the number has a reporting history. Neither proves who is calling.
Wire the gate into your dialer
- Normalise the number to E.164 and call the phone check. Stop on
found: false. - Read
number_typeand drop the types your campaign cannot use. - For US numbers, call carrier lookup if your routing or reporting uses the original carrier. Outside North America it answers not found.
- Check your outbound caller ID with the phone spam check on a schedule, not per call.
- Cache the results. A repeated lookup of the same number inside the cache window is served without a new charge.
- The gate is stateless, so it sits in front of any dialer or voice agent framework.
- Every result carries the credits charged, so you can log the per-call cost of the gate.
- The same checks are available over the MCP server if the agent itself decides when to run them.
The wider data-quality picture for outbound automation is covered in how AI SDR data quality goes wrong.