The policy layer that takes your agentic CS stack from 30% to 60%+ containment, and makes the deployment defensible from day one.
You have the ROI case for agentic customer support. You are holding back, or moving carefully, because you cannot make the deployment defensible without the right infrastructure in place. And if you deploy without a policy layer, you will stall at 30% contact containment before you reach the contacts worth automating.
Polidex solves both problems. Every decision authorized before the agent acts. Every action gated by a signed credential: the rule version in effect, the authorization that permitted it. No valid token, no action. Every decision on record.
Two reasons you haven't reached 60% containment. One applies to you.
If you have not yet deployed
You are waiting for the deployment to be defensible. That is not caution. That is the right instinct. But waiting does not close the infrastructure gap. Every quarter you hold back is full headcount cost against competitors who have already solved the policy layer problem.
Those who build the policy layer before deployment do not hit the ceiling. They go straight to 60%+ containment.
If you are already deployed
The contacts worth automating, billing disputes, plan changes, retention offers, SLA credits, all require a policy decision the agent cannot make without infrastructure. That is not an AI capability problem. That is a policy infrastructure problem.
When the containment number hasn't moved, when billing disputes and SLA credits are still going to humans at $20 per contact, you are the one who has to explain why at the next QBR. And you are the one who answers if the agent made wrong decisions at scale before anyone noticed: What rule was it applying? Were those decisions consistent?
Competitors who built the policy layer before deployment are already at 60%+ containment. Every quarter you operate at 30%, they compound a cost-per-contact advantage that better models and better prompts cannot close.
See the full economic model →Why 40% of contacts hit the wall
The contacts AI cannot resolve cluster into four categories. These are not edge cases. They are the core of what your agents are deployed to handle.
Billing disputes and credit requests
20-25% of contacts
The agent can verify what happened but cannot determine what the customer is entitled to.
Plan changes and upgrade eligibility
10-12% of contacts
The agent knows what plans exist but cannot determine whether this customer qualifies.
Retention offers
8-10% of contacts
The agent detects the churn signal but cannot determine what offer this customer qualifies for.
SLA and outage compensation
3-5% of contacts
The agent can confirm the outage but cannot determine what the customer is owed.
These are not AI capability problems. They are policy infrastructure problems. The agent does not know the answer because the answer does not exist anywhere the agent can reliably access.
See the full model and ROI →Why system prompts cannot fix it
Operational failure
The system prompt grows to thousands of words through incident edits, each team member updating the rule that burned them most recently. There is no version history. No approval workflow. No conflict detection. When someone edits it, the old policy is gone. When the same rule is described differently across pages, no one knows which version the agent is applying today.
This is policy drift: not the result of a deliberate change, but the inevitable consequence of managing policy as a document.
Architectural failure
Transformer models weight recent context more heavily than static instructions. By turn 20 of a complex billing dispute, the policy guidance at the top of the context has less influence than the last three customer messages. This is not a flaw in any specific model. It is how the architecture works. When conversation history grows, the policy signal weakens. The longer the contact, the more likely the agent makes a wrong call.
A system prompt is not a policy layer. It is a text file someone edited last Tuesday.
Why system prompts fail as policy →Your agent doesn't decide. Your policy does.
Instead of interpreting policy from a system prompt, your agent calls Polidex. Polidex queries your systems for the full picture, evaluates the request against versioned eligibility rules, and issues a decision token: a signed, versioned record the agent and downstream systems require before acting.
No valid token, no action.
1. Agent submits the request
Who the customer is and what they're asking: The minimum the agent knows. Polidex queries your systems for the rest, so the agent can't invent context.
2. Polidex queries context and evaluates policy
Retrieves the full customer record from your connected systems, then applies versioned eligibility rules to determine what's authorized.
3. Decision token issued
A signed, versioned record, authorized, denied, or escalate, with the policy version and authorization path. Downstream systems require the token; the agent can't act without it.
The cost of operating without a policy layer
This is not hypothetical. The model is built from publicly documented industry benchmarks for enterprise customer support operations at mobile operator scale.
| Stage 1: No Policy Layer | Stage 2: With Polidex | |
|---|---|---|
| Contact containment | 30% | 60%+ |
| Effective cost per contact | $12.36 | $7.14 |
| Annual cost (10M-subscriber mobile operator) | $272M | $157M |
| Annual savings vs. baseline | $168M | $283M |
The $115M incremental savings from Stage 1 to Stage 2 are not recoverable by any other means. Better models do not solve a policy infrastructure gap. More training data does not version a refund policy. And every quarter a competitor operates at Stage 2 while you are at Stage 1, the cost-per-contact advantage compounds in their favor.
See the full methodology →What changes when you add a policy layer
| Without Polidex | With Polidex |
|---|---|
| Policy lives in a system prompt | Policy is versioned, queryable infrastructure |
| No audit trail | Every decision has a record with a policy citation |
| Policy updated by whoever has edit access | Policy governed and versioned by business owners |
| Inconsistency compounds at agent speed | Consistent by construction |
| No authorization gate: The agent decides without a check | No valid authorization token, no action |
| 30% contact containment | 60%+ contact containment, $7.14 effective cost per contact |
“78% of executives cannot pass an AI governance audit within 90 days.”
Grant Thornton, April 2026
“The bigger risk becomes delegating authority to AI systems.”
Alessandro Perilli, VP AI Research, IDCWhat delegating authority to AI actually requires →
“AI accountability, security, auditability, traceability, and guardrails, is the #1 purchase factor for AI infrastructure, ahead of cost and vendor reputation.”
Jitterbit survey of 1,500 IT leaders, March 2026
December 2027 is closer than it looks.
EU AI Act enforcement arrives in two waves. Article 50 transparency obligations are already in force: any AI system interacting with customers must disclose that it is an AI. The consequential deadline for your AI agents is December 2027, when Annex III high-risk system requirements take effect with full enforcement authority. Your AI agents are the regulated systems, and the compliance obligations fall on you as their deployer. The requirements, audit trails, explainability, and purpose limitation enforcement, are not satisfied by governance documents or system prompts. They require infrastructure that enforces authorization before the agent acts and produces a tamper-evident record of every decision.
For mobile operators, the obligation is already live. FCC customer protection standards and Ofcom requirements create accountability obligations when AI agents make autonomous decisions affecting billing, contracts, and service commitments. When a regulator asks what rule your agent applied to a specific SLA credit or ETF waiver, and when, “it's in the system prompt” is not a defensible answer.
Enterprise procurement and implementation typically takes 12 to 18 months. The organizations that will be able to demonstrate compliance by December 2027 are the ones building infrastructure now. The question regulators ask is not “does your AI have policies?” It is “what was the agent authorized to do, under which version of policy, at which time?” A Polidex authorization record answers that question. A system prompt does not.
What EU AI Act actually requires of AI agents →Go deeper
The policy layer argument has many dimensions. Here is where to go deeper.
Why 40% of contacts require a policy decision the agent cannot make, and what the full cost model looks like.
The complete index of specific failure modes: from system prompt drift to governance accountability gaps.
The two agentic CS architecture paths and the $173M cost of choosing the wrong one.
Concepts, mechanisms, comparisons: the complete reference for how the policy layer functions.
Over 50 pre-configured rules for mobile CS operations, five authority tiers, 12 escalation conditions.
Policy infrastructure for CS agents across all industries.
For CTOs and Chief AI Officers facing governance accountability pressure from legal and the board.
What it actually means to delegate decision-making authority to an AI system.
Working through how to deploy agentic CS?
If you're at a mobile operator or enterprise evaluating agentic AI for your operation, we'd welcome a conversation about what containment is realistic, what the policy layer needs to look like, and how to make the deployment defensible.
Start a Conversation