Putting an AI layer in front of live telecom infrastructure is genuinely useful — and genuinely risky if you skip a few guardrails. We've been running Carrier MCP in production with early-access operators for several months. Here's what we've learned about doing it safely.
1. Start read-only, earn write access
The Free tier's 57 read-only tools are not a restriction — they're a forcing function. Before you give an AI agent write access to your fleet, you should have run it in read-only mode long enough to trust its outputs.
A practical ramp:
- Week 1–2: run
fleet_health_reportandsubscriber_deep_divedaily. Compare outputs to your existing dashboard. Build confidence in the data layer. - Week 3: enable write scope on a non-production reseller account. Run activations against test ICCIDs. Observe the audit log.
- Week 4+: cut over to production write scope with confirmation gates in place (see below).
Operators who skipped this ramp and went straight to write scope on production data all regretted it — not because Carrier did the wrong thing, but because they hadn't validated their prompts against real data shapes first.
2. Always use confirmation gates for write operations
Every well-designed AI workflow for fleet ops has two phases: a read phase that describes what will happen, and a write phase that does it. Never collapse them.
In practice this means structuring your prompts as:
"Show me which subscribers have less than 100MB remaining on their current package,
then tell me what it would cost to top them up — but don't do anything yet."The AI uses read tools to build the list and cost estimate. You review it. Then:
"Do it for all of them."This two-prompt pattern catches the cases where the read phase reveals something unexpected — a subscriber on a custom rate plan, an ICCID that belongs to a different reseller, a package that's been deprecated. The AI would have executed correctly, but you wouldn't have known what "correctly" meant until you saw the preview.
3. Size batches conservatively
The OCS has rate limits, and Carrier's rate-limit governor (visible via rate_limit_status) tracks bucket fill levels per endpoint. When you ask an AI to activate 500 ICCIDs in a single prompt, it will try to do exactly that — and it will hit the rate limiter partway through, leaving your fleet in a partially-activated state.
Better approach: ask the AI to activate in batches of 50, with a status check between each batch. The bulk_operations_planner prompt does this automatically — it inspects the current rate-limit state, divides the work into safe chunks, and runs them sequentially.
For operations above 200 ICCIDs, always use the planner. For operations above 1,000, talk to us first — we can provision a dedicated rate-limit bucket for your reseller account.
4. Scope your agent, not your prompts
If you're running a multi-agent system — one agent for ops, one for analytics, one for customer support — give each a separate Carrier OAuth token with the minimum scope it needs. Don't use a single admin-scoped token for everything.
This matters for two reasons:
- Blast radius: if a prompt-injection attack causes your analytics agent to attempt a write operation, a read-only token stops it at the Carrier layer before it reaches the OCS.
- Audit clarity:the audit log tags every tool call with the token that made it. When something goes wrong, you want to know which agent did it — not just that "the system" did.
5. Read the audit log, not just the AI's summary
AI summaries are useful. Audit logs are the ground truth. Carrier's Analytics Engine dataset (carrier_mcp_audit) captures every tool call: the tool name, the input parameters, the OCS response code, and the latency. Pro tier retains 90 days; Enterprise retains indefinitely.
Set up a daily review of the audit log for any tool calls that returned OCS error codes. Carrier maps OCS errors to human-readable descriptions, but the raw code tells you whether the issue is a data problem (wrong ICCID format), a scope problem (write tool called without write scope), or an OCS-side problem (carrier timeout, package unavailable in region).
The fleet_health_report prompt already surfaces error-rate anomalies — run it at the start of each ops shift as a baseline check.
6. Test intelligence composites before relying on them
Carrier's eight intelligence composites (fleet_health_report, subscriber_deep_dive, revenue_optimization, coverage_analysis, churn_risk_score, and others) chain multiple OCS calls into single-query answers. They're convenient — but they make assumptions about your data shape.
revenue_optimization, for example, assumes your packages are priced in a single currency and that your margin data is in the package_metadatafield. If you've got multi-currency pricing or a custom metadata schema, the composite will still run — it just won't give you the output you expect.
Run each composite against a known-good subscriber account first. Compare the output to what you know to be true. Only after that should you use the composite as input to a write operation.
These patterns aren't Carrier-specific — they apply to any AI system operating on live infrastructure. The telecom context makes the stakes higher: an incorrectly activated ICCID or an erroneous balance deduction has a real subscriber on the other end. The guardrails are worth the overhead.
Questions or edge cases we haven't covered: support@carrier.llc. We're happy to review your workflow before you go live.