When a customer reports that your AI agent’s number looks suspicious, begin with the receiving phone. Was there a warning, a blocked call or an unfamiliar business name? Reproduce that specific complaint on the destination carrier before changing registration or dialing settings. The investigation below connects each symptom to the evidence and review route it needs.
Why an AI agent’s calls can receive a spam label
A warning does not tell you which factor triggered it. Hiya identifies possible influences including recipient reports, calling patterns, a number’s previous ownership and associations with a network or business. Its guidance is a useful investigation list, not a formula that predicts the next label. Hiya’s explanation of mislabeled calls describes these factors and its business registration process.
For an AI calling operation, investigate the behavior around the conversation as carefully as the voice itself. Are recipients expecting the call? Does the opening explain who is calling and why? Are repeat attempts continuing after a refusal? Does the agent produce silence, disconnect early or fail to handle an opt-out? These are practical checks on the experience you control; they do not establish what a carrier’s proprietary system decided.
Also inspect the number’s history and ownership records. A newly assigned number may have been used before. A platform’s tenant may use a caller ID that the originating provider cannot fully authenticate. Those are different problems, requiring different evidence and corrective work.
Avoid inferring that every AI-generated voice is automatically labeled as spam. Establish the observed symptom first: a warning, a blocked call, an unanswered call or a misleading business name. They are not interchangeable.
What STIR/SHAKEN attestation tells you
STIR/SHAKEN carries information about caller-ID authentication. The originating provider’s attestation describes its relationship to the caller and the number being presented.
| Level | What the originating provider asserts | What it does not establish |
|---|---|---|
| A, full attestation | It knows the caller and their authorization to use the number. | That the recipient will see no warning or answer the call. |
| B, partial attestation | It knows the customer but cannot establish their right to use that caller ID. | That the caller is necessarily fraudulent. |
| C, gateway attestation | It can identify the call’s entry into its network, with less knowledge of the originating caller. | That the call is necessarily malicious. |
These distinctions are documented in Twilio’s STIR/SHAKEN guidance. Keep the asserted attestation level separate from the receiving system’s signature-verification result and from a missing or unavailable result.
Twilio’s November 5, 2026 Call resource update exposes per-call STIR/SHAKEN status through stir_verstat. Keep that authentication diagnostic in the investigation record below. Verizon’s feedback form identifies authentication as one factor in call treatment and cautions that a submission may not change future treatment.
Check reputation carrier by carrier
There is no single lookup that proves what every subscriber will see. Build a small controlled test set for the networks that matter to your customers, and preserve the exact label rather than normalizing every warning to “Spam Likely.”
| Destination | Evidence to capture | Current review route |
|---|---|---|
| AT&T | Exact incoming label, screen capture, device settings and call time | AT&T’s call-label review route, which directs users to Hiya |
| T-Mobile | Exact label, whether the phone rang, and Scam Block configuration | T-Mobile’s call reporting service |
| Verizon | Exact label, whether the call arrived, and Call Filter configuration | Verizon’s spam feedback form |
These routes were checked on November 12, 2026. Keep the report destination with your case record so someone can verify where an appeal was actually submitted.
AT&T: document the label before requesting review
Use AT&T’s review route for a business number believed to be mislabeled. Its current destination is Hiya’s support form. The USTelecom call-labeling directory identifies AT&T and Hiya and lists examples such as Spam Risk and Fraud Risk.
For the test, keep the originating number, provider route and receiving device stable. Record whether the warning appears on the incoming screen, in call history, or both. A screenshot should preserve the label and timestamp while avoiding unnecessary recipient information.
Confirm that the business identity and number information submitted for review are accurate. If you update registration, record the change and retest later under comparable conditions. Do not mark the issue resolved merely because a form was accepted.
T-Mobile: separate Scam ID from Scam Block
T-Mobile distinguishes Scam ID labeling from Scam Block, which can stop suspected scam calls before they reach the phone. That difference changes the investigation. A displayed warning gives you a screen to capture; blocking may leave you investigating a missing incoming call instead.
Record Scam Block and other filtering settings before the test. If you compare configurations, identify them as separate test conditions rather than combining their outcomes. Use the official reporting service for a suspected misclassification.
First Orion’s incorrect-label guidance also explains that history, calling patterns and recipient responses can inform review. It cannot override the carrier’s final decision. Treat registration and an appeal as steps in a process, not an instruction that a carrier must clear a number.
Verizon: preserve the exact wording and filter state
Use Verizon’s feedback form to report a business number that appears incorrectly labeled or blocked. Capture the actual wording shown on the test device. Different labels and interfaces should not be collapsed into one assumed Verizon warning.
Include the originating number, test time, receiving environment and a call identifier your provider can investigate. Record whether the warning was visible during ringing or only later in call history. If Call Filter or a device setting changed between attempts, note that explicitly.
Keep the carrier case reference with the test evidence, and compare the next observed label with the original wording.
Registration, review and testing serve different purposes
Registration supplies business and number information. Review challenges a suspected incorrect classification. Testing checks what happened under defined conditions. A team needs to track each separately to avoid closing a ticket before the recipient experience has changed.
On October 16, 2026, Twilio announced that Voice Integrity added Verizon support, extending its registration coverage across the three major US networks. The update concerns registration with their analytics providers. It does not make registration a substitute for observing call arrival or display.
The Free Caller Registry likewise states that registration does not guarantee redress and does not replace monitoring. Repeated submissions add no value. Its form is intended for businesses registering their own numbers; platforms registering numbers on another business’s behalf are directed to contact the providers. That distinction matters for an AI-agent service managing many customer tenants.
A business-name update is another separate task. Telnyx’s CNAM guide explains caller-name lookup. Correcting a name record can address an identity-display issue, but a name lookup is not evidence that a spam warning has disappeared on a particular device.
Run a repeatable diagnosis and retest
Use the same worksheet for each reported number:
- Define the complaint. Record the destination network, exact warning or blocking symptom, and when it occurred. Keep an unverified customer report separate from a reproduced result.
- Reproduce through the real route. Place a controlled call using the production agent’s provider and caller ID. A different test application may use a different path.
- Capture independent observations. Save authentication results, provider call status, receiving-device behavior and the label source. Write “not observed” when a field is unavailable.
- Review identity and calling behavior. Check business registration, authorization to use the number, expected audience, retry rules and opt-out handling. The existing VoIP number warm-up and testing guide provides background for this baseline work.
- Correct a documented issue or submit review. Preserve the case reference, submitted evidence and change date. Avoid changing several variables at once if you need to understand what affected the result.
- Retest comparable conditions. Repeat the same destination, route and device setup. Report a clean observation as a dated observation, not permanent clearance.
Keep one investigation packet
Copy these fields into the incident ticket. Leave unavailable observations explicitly marked “not observed”; do not fill them from a lookup that measures something else.
| Record field | What to enter |
|---|---|
| Calling identity and route | Originating number, customer/business, production provider and route |
| Receiving environment | Destination network, endpoint/device, saved-contact state and filtering settings |
| Attempt and evidence | Timestamp with time zone, provider call ID and screenshot or event reference |
| Observed symptom | Exact warning, no incoming call, or incorrect name; distinguish report from reproduction |
| Authentication | Provider field, returned value and whether it was available |
| Review and change | Carrier/provider case reference, evidence submitted and configuration change date |
| Retest | Same-condition attempt, exact outcome, remaining unknowns and next owner |
Route the next action from the symptom
- A warning appears: preserve its wording and use that destination carrier’s label-review route.
- The call never arrives: investigate delivery and filtering with provider traces and receiving-device settings. Absence alone does not establish a spam classification.
- The name is wrong but the call arrives: investigate caller-name display and local contacts separately from a spam-label case.
These branches select the next investigation; they do not assign a root cause before evidence supports one.
Rotating through numbers to escape warnings does not diagnose their cause. A useful investigation leaves a trail another operator can reproduce.
Give every probe result a clear scope
A report should state which number called which destination, through which route, at what time, and how the outcome was observed. Automated endpoint acceptance, a handset warning and a human answer rate need separate definitions and denominators. Missing label evidence must remain unknown.
For teams building that workflow, Spenza’s Voice Observability starts with controlled delivery testing to a T-Mobile SIP probe. Reputation observations and additional carrier coverage require a validated pilot scope. Arrival at that probe does not establish what every consumer handset displayed, and evaluation does not guarantee warning removal.
Bring the numbers with reported problems, a comparison group and the receiving environments you need to understand. The useful outcome is a defensible answer about where the experience changes, followed by a testable next action.
FAQs
Prepared by Spenza, a connectivity management and telecom platform provider. Contact the Spenza team for product-scope questions.
