The agentic data platform for telecommunications data teams

For a telecom data team, Data Workers, the agentic data platform, keeps usage, roaming and billing data right from the Kafka stream to the revenue assurance dashboard: its agents catch a dropped field, a stalled consumer or a doubled file, trace what it reaches and propose the fix before rating, billing or settlement reads it. The same agents scope access to CPNI tables and record every grant, plan legacy warehouse moves with parity checks, and put every change under a named person's approval with a receipt.

Key takeaways

• •Usage data that reconciles. Volume, uniqueness and null checks on rated usage, lineage from the Kafka topic to the revenue assurance dashboard, and a diagnosed incident before the billing run.
• •Streams you can see. Consumer lag, connector health and new schema versions on every topic, including changes Schema Registry accepts that your models can't read.
• •CPNI access, scoped and recorded. Requests for call detail and account tables are scoped to the columns needed, carry a 90-day default expiry, go to a named owner when they need review, and land in a hash-chained trail.
• •Migrations planned with proof. Teradata or Oracle EDW workloads move to Snowflake in waves, each with its parity checks, and cutover waits for the owner's sign-off.
• •Controls mapped to the rule's text. FCC CPNI rules, NIS2, GDPR and CCPA/CPRA map to controls Data Workers provides; your compliance team decides what satisfies each rule.

The telecom data reality

A carrier's data platform is a ledger as much as an analytics estate: every mediated record is a line on a bill or a partner's settlement, and every row of call detail is customer proprietary network information (CPNI). A typical carrier runs OSS/BSS suites from Amdocs, Netcracker, Ericsson or Nokia, a mediation layer that turns network records (CDRs and xDRs) into rated usage, and network telemetry streaming through Kafka, often Confluent with Schema Registry. Analytics sits on a Hadoop or Cloudera estate moving to Databricks, Snowflake or BigQuery, beside a Teradata or Oracle EDW that still feeds finance. Airflow schedules the batch, dbt models revenue and usage, and Tableau or Power BI carries revenue assurance and churn dashboards.

The data operations that hurt:

• •Volume that never stops. A stalled consumer or a re-delivered file is a gap or a double count by morning.
• •Mediation and billing reconciliation. Revenue assurance has to show every mediated record was rated and billed, and that roaming matches what partners settle.
• •Schema drift in vendor feeds. A mediation release changes a record layout, and the change passes every technical check.
• •CPNI access, migrations and streaming cost. A carrier has to know who was granted call detail, finance wants proof the migrated numbers match, and telemetry compute grows with the network.

Three use cases

1. Usage, roaming and revenue assurance data (worked example below). Data Workers puts volume, uniqueness and null-rate checks on the tables behind rating, billing and settlement (run_quality_check, get_anomalies, set_sla), and its streaming agent watches the topics that feed them for lag, connector failures and new schema versions. A schema change is traced to the models, dashboards and extracts it reaches, the fix arrives as a diff for the model owner to merge, and a ServiceNow incident carries the diagnosis. Run it at L2 propose.

2. CPNI access and the evidence behind it. A marketing analytics team asks for call detail and plan tables for a retention campaign. provision_access scopes the request to the columns the purpose needs and records the grant with a 90-day default expiry in the access ledger and the hash-chained activity log; when the policy verdict is review it grants nothing, and request_governance_review opens a trackable review for the privacy owner. On Unity Catalog the approved grant is applied; on Snowflake, BigQuery and other platforms it is proposed for the table owner to apply. A check_policy rule can send every request on CPNI tables to review, and a freshness SLA on the opt-in and opt-out table makes sure the campaign reads today's answer. When a pull request adds columns named like phone numbers, names, addresses or IP addresses, Data Workers' review flags them for the privacy owner (it reads column names and annotations, not values), and generate_audit_report exports the grants and policy decisions for any period.

3. Moving the EDW without losing the numbers. For a carrier moving revenue and usage marts from Teradata to Snowflake, Data Workers' migration agent translates the SQL from the Teradata dialect, plans each wave with its parity checks and tracks them, flags masking tags on sensitive columns that a rename dropped and proposes the repair, and holds the completion gate for the owner's sign-off. Cutover becomes a decision made on recorded evidence. You're on Teradata and the Hive and Glue to Unity Catalog guide cover both directions of the Hadoop and EDW move.

Worked example: a roaming field that passed Schema Registry

This is an illustrative example. A mobile operator's mediation platform publishes rated usage as Avro to a Confluent topic, rated_usage, with Schema Registry on its default BACKWARD compatibility. Databricks ingests it into a bronze Delta table, an Airflow DAG runs the dbt model fct_roaming_usage_daily at 03:00, and a Tableau revenue assurance dashboard refreshes at 07:30 for the wholesale team that reconciles roaming against partner settlements. The domain is at L2 propose.

On Tuesday evening a mediation release registers version 8 of the value schema: it removes tap_partner_code and adds visited_plmn with a null default. Confluent's documentation says BACKWARD means "consumers using new schema can read data written with old schema" and allows removing fields, so the registry accepts it. Nothing fails, and the roaming model's partner column goes null on every new record.

Without the agents, the gap turns up on Wednesday's dashboard or at settlement. With them, the on-call approves one diff on Tuesday evening, and the receipt holds the diff, the approver, the lineage path and the rollback plan. Kafka, Kafka Connect, Schema Registry, Databricks, dbt, Airflow, ServiceNow, Teams and Tableau (read) are native integrations; the mediation platform and OSS/BSS suites connect over their APIs today. You're on Confluent, you're on Apache Kafka, Data Workers on Databricks, Data Workers + Airflow and you're on Tableau cover the wiring.

Governance and regulation

Data Workers supplies controls and evidence where agents touch data; compliance stays with your controls, people and counsel. Not legal advice.

FCC CPNI rules, 47 CFR 64 Subpart U (eCFR, up to date as of Sep 30, 2026). Section 64.2010(a): "Telecommunications carriers must take reasonable measures to discover and protect against attempts to gain unauthorized access to CPNI." Section 64.2009(a) requires a system by which "the status of a customer's CPNI approval can be clearly established prior to the use of CPNI", and 64.2009(c) a record "of all instances where CPNI was disclosed or provided to third parties, or where third parties were allowed access to CPNI", kept "for a minimum of one year". Data Workers' side: column-scoped grants with an expiry, reviews to a named owner, a freshness SLA and tests on the approval-status table, and a tamper-evident record of every grant that generate_audit_report exports and verify_global_hash_chain checks.

CPNI breach notification. Section 64.2011 currently requires notice to the Secret Service and the FBI "in no event later than seven (7) business days, after reasonable determination of the breach", and a breach record kept "for a minimum of 2 years". The FCC's Data Breach Reporting Requirements order (published Feb 12, 2024, effective Mar 13, 2024) amends that section, but the Federal Register entry says the 64.2011 amendments "are delayed indefinitely" until the Commission announces their effective date; the eCFR as of Sep 30, 2026 still shows the earlier text. Data Workers' side: when your team investigates, get_audit_trail shows which agents acted on which tables and when, and the access report shows who was granted CPNI tables.

NIS2, Directive (EU) 2022/2555. Member States had to transpose it by Oct 17, 2024; it requires cybersecurity risk management and incident reporting from essential and important entities, including electronic communications providers. ENISA's Telecom Security Incidents 2024 report (Jul 15, 2025) counts "188 incidents submitted by national authorities from 26 EU Member States and 2 European Free Trade Association (EFTA) countries", "an increase of 20,5% over the 2023 with 156 incidents". Data Workers' side: agents run in your infrastructure, every action is logged, and the org-wide stop halts all autonomous dispatch.

GDPR and CCPA/CPRA. GDPR Article 5(1)(c) limits personal data to what is "adequate, relevant and limited to what is necessary", and Article 17 gives the right to erasure "without undue delay". The CPPA's updated CCPA regulations took effect on Jan 1, 2026, adding risk assessments, cybersecurity audits and automated decisionmaking rules. Data Workers erases a person from its own context graph with a tombstone in the audit chain; erasure in your warehouse stays your process, and lineage shows which tables hold the person's data.

Where it runs and who approves. The agents run in your infrastructure on every tier; your data stays in your systems, and the hosted Autonomous Data-Conductor sees workflow metadata only (VPC or air-gapped, where does our data go?). Sovereign mode blocks external model calls. Each domain sits on one ladder, L0 manual, L1 observe, L2 propose, L3 act reversibly, L4 autonomous; approvals go to a named person, an unanswered request expires and escalates, and no agent can promote its own work (how approvals work, is it safe?, how Data Workers handles PII, SOX, HIPAA, GDPR and the EU AI Act).

What changes for the telecom data team

Six jobs move onto autopilot at the level each owner sets. People still own the decisions: which domains climb the ladder, who approves, what counts as a billable record, and who may use CPNI for what (who owns the agents, autonomy levels L0 to L4, will Data Workers replace my data team?).

The alternatives telecom teams weigh

Build it yourselves. A strong carrier team can wire a coding agent to MCP servers for Kafka and Databricks. The work is everything around it: approvals, blast radius, rollback and receipts (build it ourselves?).

OSS/BSS suites and revenue assurance tools. Mediation, billing and revenue assurance platforms own their domain and do it well. Data Workers works on the data after it leaves them.

Data observability. Observability tools raise the alarm on a broken table, and many teams keep them. Data Workers takes the alert from there: diagnosis, the proposed fix, the approval and the verified result (Data Workers vs data observability).

Platform-native agents. Snowflake made its managed MCP server and Cortex Agents generally available on Nov 4, 2025, and Databricks made Genie One generally available on Jun 16, 2026. They are excellent inside their platform; a roaming record crosses mediation, Kafka, the lakehouse, dbt and Tableau, and Data Workers works across all of them (Data Workers on Snowflake).

The media and advertising and energy and utilities pages map the same controls to their streams; AI for data infrastructure in telecom covers the category.

The case for your CFO

The outcome is usage that becomes revenue. Every mediated record is billed, settled with a partner or written off, and a dropped field or a stalled consumer moves money into the third column unnoticed until reconciliation.

The risk story: at L2 propose every change waits for a named owner, CPNI grants are scoped and recorded with their expiry, and every change carries a receipt with the diff, the approver and the rollback path. Why now: vendors keep changing layouts, migrations put revenue numbers on two platforms at once, and CPNI rules expect you to know who was granted call detail.

The first win: volume, null and schema checks with incident diagnosis on the usage and roaming tables for one billing cycle, with nothing migrated. What stays the same: Kafka, the lakehouse, dbt, Airflow, Tableau and the OSS/BSS suites. Start with a pilot ($7,500 one-time, credited in full against the first year); Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing, the ROI calculator and the ROI of agentic data operations. The sentence for upstairs: "Our usage and billing data now has a crew that catches breaks before the bill and the settlement read them, and every fix and every CPNI grant has a receipt."

FAQ

Can Data Workers read our Amdocs, Netcracker or Ericsson data? Yes. Data Workers watches the topics and tables their records land in, and connects to the suites over their APIs today. Kafka, Schema Registry, Databricks, Snowflake, BigQuery, dbt, Airflow and Tableau are native among 50+ connectors (integrations, what is an agentic data platform?).

Will an agent fix or delete usage records on its own? No. Model fixes arrive as a diff for the owner to merge, and data cleanups such as dedupes are proposed with dry-run counts for the owner to approve and apply.

How does it handle CPNI? Requests are scoped to the columns needed with a 90-day default expiry, reviews go to a named owner, and every grant lands in a hash-chained record you can export. Grants are applied on Unity Catalog after approval and proposed for the owner to apply elsewhere. Which uses of CPNI are allowed stays your privacy team's call.

Can it run on-premise next to our network data? Yes. The agents run in your infrastructure on every tier; Enterprise runs in your VPC, your cloud or on-premise, with an air-gap bundle and sovereign mode.

How do we measure whether it works? Track incidents caught before billing or settlement, time to diagnosis and approval, and reconciliation breaks per cycle. Savings figures are design targets until your pilot measures them (how to measure AI data agents).

Sources

• •eCFR, 47 CFR Part 64 Subpart U, Customer Proprietary Network Information, sections 64.2009, 64.2010 and 64.2011 (up to date as of Sep 30, 2026): https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B/part-64/subpart-U (checked Oct 2, 2026)
• •Federal Communications Commission, Data Breach Reporting Requirements, 89 FR 9968 (Feb 12, 2024; effective Mar 13, 2024, with the 64.2011 amendments delayed indefinitely; no effective-date notice in the Federal Register as of Oct 2, 2026): https://www.federalregister.gov/documents/2024/02/12/2024-01667/data-breach-reporting-requirements (checked Oct 2, 2026)
• •European Commission, NIS2 Directive: https://digital-strategy.ec.europa.eu/en/policies/nis2-directive (checked Oct 2, 2026)
• •ENISA, Telecom Security Incidents 2024 (Jul 15, 2025): https://www.enisa.europa.eu/publications/telecom-security-incidents-2024 (checked Oct 2, 2026)
• •GDPR, Regulation (EU) 2016/679, Articles 5 and 17, EUR-Lex: https://eur-lex.europa.eu/eli/reg/2016/679/oj (checked Oct 2, 2026)
• •California Privacy Protection Agency, CCPA updates, cybersecurity audits, risk assessments, ADMT and insurance regulations (effective Jan 1, 2026): https://cppa.ca.gov/regulations/ccpa_updates.html (checked Oct 2, 2026)
• •Confluent, Schema Evolution and Compatibility for Schema Registry: https://docs.confluent.io/platform/current/schema-registry/fundamentals/schema-evolution.html (checked Oct 2, 2026)
• •Snowflake, Snowflake-managed MCP server GA release note (Nov 4, 2025; Cortex Agents GA the same day): https://docs.snowflake.com/en/release-notes/2025/other/2025-11-04-cortex-agents-mcp (checked Oct 2, 2026)
• •Databricks, Genie One launch press release (Jun 16, 2026): https://www.databricks.com/company/newsroom/press-releases/databricks-launches-genie-one-all-new-agentic-coworker-every-team (checked Oct 2, 2026)
• •Data Workers security page (last updated Sep 10, 2026): https://dataworkers.io/security/ (checked Oct 2, 2026)
• •Data Workers pricing: https://dataworkers.io/pricing/ (checked Oct 2, 2026)
• •Data Workers open-source repository, tool registrations: https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 2, 2026)