Your AI Agent Just Granted a Full ETF Waiver. What Policy Was It Applying?

The Policy Gap in Mobile Telecom CS

Sixty days into your agentic CS deployment, the retention team flags a pattern. The AI agent has been approving full ETF waivers for customers citing general dissatisfaction. Your policy qualifies that reason code for a partial waiver up to $150, supervisor approval required. The agent has been granting full waivers. Consistently. On every contact where the phrase appeared.

Your CS Director asks the obvious questions. What policy was it applying? What version? When did this start? Has it happened on other issue types?

The answers are all the same. It is in the system prompt. We can share the file.

This is the policy gap in mobile telecom customer support. It is not hypothetical. It is the natural outcome of deploying capable AI agents without the infrastructure layer that governs what they are authorized to decide.

Why Mobile Telecom CS Is a Different Environment

Customer support is policy-intensive everywhere. Mobile telecom is a different order of complexity, and that matters when AI agents are making autonomous decisions at scale. Three things compound to make the environment uniquely exposed.

Policy surface area, all at once.

Most CS verticals have one or two policy-heavy domains. Mobile telecom has all of these simultaneously: billing disputes and credit caps, device upgrades and warranty exceptions, international roaming and bill-shock adjudication, ETF waivers and cancellation tiers, retention offers, plan management, and escalation routing across 12 distinct trigger conditions. Each scenario has its own credit limit, its own approval threshold, its own fault classification. An AI agent is not answering questions in this environment. It is making policy-adjacent decisions on nearly every contact.

Regulatory and legal exposure with named enforcement.

Mobile operators operate under regulators with enforcement authority. The FCC in the US. Ofcom in the UK. The TCP Code in Australia. The EU AI Act's Annex III requirements take effect December 2027 and require demonstrable audit trails for automated decision systems, specifically the ability to show what an AI was authorized to do, for a specific decision, at a specific time. Inconsistent treatment of customers is not just a CX failure here. It is a documentable record of differential treatment that regulators and attorneys are trained to find.

Churn economics that measure errors in dollars per day.

Mobile is a thin-margin, high-churn business. Retention decisions have direct P&L impact. A mobile operator handling 500 CS contacts per day with a 3% policy error rate on retention-class decisions produces 15 wrong decisions every day. Over 90 days, that is 1,350 decisions, each with a dollar value attached. Some are credits that should have required approval. Some are waivers that should have been partial. Some are offers that should have triggered escalation. At agent speed, the loss compounds before anyone notices.

What Your Agents Are Running On Today

Ask your CS operations team how your AI agent knows what it is allowed to do. The answer is almost always the same: the system prompt.

The system prompt is a text document. It contains natural language instructions: What the agent can offer, what it should escalate, how much it can credit. It is edited when something goes wrong. It accumulates rules after every incident. It is not versioned. It has no approval workflow. There is no conflict detection, so contradictory instructions coexist in the same document until someone notices. And when a specific decision is challenged, there is no reliable way to reconstruct which version of the policy was in effect on that date.

In a mobile telecom CS environment with over 50 baseline rules across four domains, five authority tiers, and regulatory obligations for consistent treatment, this is not a minor gap. It is a structural mismatch. Three failure modes follow.

Policy drift, and rogue by drift.

Incremental edits to the system prompt do not check for contradictions. Different agents on different channels run slightly different instructions. The rule governing a refund decision last quarter may not be the rule today, and there is no record of the change. An agent running on outdated policy is rogue not because it was attacked, but because nobody updated the prompt when the rule changed. Consistent, at agent speed, until someone notices.

Unenforceable limits.

A credit limit written in natural language inside a system prompt is a behavioral instruction. An agent optimizing for task completion treats a constraint as an obstacle to navigate. Enforcement from inside the agent's context is not structural enforcement. It is a suggestion.

The audit trail gap.

Observability tools capture what agents did: Which tools were called, at what time, with what parameters. That is a log, not an authorization record. Knowing the agent called the credit API with a $400 parameter at 14:32:07 is a log entry. Knowing the agent was authorized to issue a credit of up to $100 under billing policy version 12, that it exceeded that authorization, and that no policy governed the overage, that is the governance record. The log cannot produce it.

What Polidex Ships With for Mobile Telecom

Polidex is not a configuration project. The mobile telecom CS domain model arrives pre-built. The default ruleset covers the four primary domains: billing disputes and outage credits, device upgrades and warranty, roaming and ETF/cancellation, and retention offers and escalation routing.

Over 50 pre-configured rules across four domains.

The policy baseline a mobile operator would otherwise author from scratch is already there. Credit caps, fault classification, eligibility windows, exception paths. Mobile operators confirm thresholds against their own margin model. They do not build the policy model.

Five agent authority tiers.

Frontline agent, senior agent, supervisor, retention specialist, director. Every decision routes to the correct tier based on context, dollar value, and rule classification. Permanent pricing changes and multi-month free service grants are explicitly excluded from agent and supervisor authority. The tier model is enforced, not advisory.

12 escalation conditions, mapped to target tiers.

Escalation routing is a policy decision, not a judgment call. Each of the 12 conditions has a specific target tier and urgency level. Your agents do not improvise the edge cases. They route them.

What you confirm: dollar thresholds, discount percentages, timing windows, and the specific authority levels for your operation. What you do not build: the policy model itself.

What Changes With a Policy Layer

Polidex sits between your AI agent and the billing, CRM, and network systems it acts on. The agent queries Polidex for a decision. Polidex evaluates the context against the configured ruleset and returns a structured envelope: the decision, the rule version in effect, the authority tier, and a signed authorization token. The agent does not interpret the policy. It acts on the result.

Plain-language authorization records.

Every decision Polidex produces includes a statement of what was authorized and why, in plain English. For example: "The agent was authorized to issue a partial ETF waiver because the customer cited general dissatisfaction without a qualifying condition. Maximum waiver: $150. Supervisor approval required before proceeding." That is the record a CS Director, a compliance reviewer, or a regulator can read.

Consistent decisions at scale.

The same policy query with the same context produces the same decision every time, regardless of channel, time of day, or which agent platform routed it. This is not a training outcome. It is an infrastructure outcome.

Versioned policy.

Every rule is versioned. Every decision envelope references the rule version in effect at the time of the decision. When policy changes, the change propagates immediately to every agent. No system prompt edits. No redeployment. No drift.

Exception handling as infrastructure.

Not every customer situation fits within policy. Polidex routes out-of-policy requests to the appropriate human approver with full context: what was requested, what policy says, what the exception would require. Your agents do not improvise side channels. They escalate cleanly, with a structured record.

Getting to Production

The path from confirmation to active policy enforcement is measured in weeks, not quarters. Four integrations underpin the decisions where live data is required.

Billing system.

Active plan rates, credit history, current balances. Required for outage compensation calculations against actual plan value and for credit cap enforcement against cumulative history.

NOC incident management.

Outage validation. Required to distinguish a documented mass network event from an individual service complaint, and to gate auto-credit eligibility on verified incidents.

Network coverage API.

Coverage verification for relocation-based ETF waivers and coverage misrepresentation claims. Required to validate the qualifying condition before the waiver clears the agent tier.

Device financing system.

Active installment plan balances. Required for early upgrade eligibility, lost and stolen replacement adjudication, and ETF calculations that include device financing components.

These are read-only data queries at decision time. No customer data is stored in Polidex.