The AI control plane for next-generation communication infrastructure — evaluating carriers, compute, and storage in real time and routing to whatever combination actually performs best.
v1.2 · July 2026Communication infrastructure is entering the same shift computing already went through: from fixed, manually-managed systems toward continuously optimized intelligence layers. The category we think is emerging isn't another carrier, CPaaS provider, or infrastructure network — it's an AI control plane for communication infrastructure, the same way Kubernetes is a control plane for compute or SDN controllers are a control plane for networking: a decision layer that continuously evaluates available connectivity, compute, storage, and trust systems, and selects the optimal path for each interaction. Create Telecom's long-term goal is to become that layer.
Create Telecom began from a simple belief: communication infrastructure should be dramatically cheaper and more universally accessible than the carrier-dominated model allows today — affordability and access pushed as far as the underlying economics genuinely allow, not a flat promise that ignores who pays for PSTN termination on calls that touch the legacy network.
Rather than try to build that all at once, we started with a real, sellable product — Ready Freddy by Create Telecom, an AI voice agent that helps local service businesses stop losing jobs to missed calls. That product is live, generating revenue, and handling real call volume today. This document lays out where the larger vision goes from here.
We're deliberately not presenting this as one flat roadmap. Confusing "what we're building next" with "what we ultimately want to exist" is how vision documents lose credibility the moment someone checks. So: three horizons, clearly labeled, and we'll keep referring back to them throughout this document.
An AI voice and chat agent that answers, qualifies, and books jobs for local service businesses. Real customers, real call volume, real revenue. This is the proof that we can build and sell something people pay for — and it's the engine funding everything below.
An intelligence layer that continuously evaluates cost, latency, and call quality across existing telecom carriers, and routes every call to whichever performs best in that moment — instead of relying on a static, manually-configured route. Reduces Ready Freddy's own costs and is a sellable product on its own.
The same routing intelligence from Horizon 2, extended across the emerging decentralized infrastructure landscape — connectivity, compute, and storage — dynamically choosing the best available combination for a given task, decentralized or traditional. This is the long-term direction, not a near-term deliverable.
A vision like this could have been proposed a decade ago and gone nowhere, because the underlying pieces didn't exist yet. What's different now:
None of these trends individually would justify this vision. Together, they're why we think this is worth pursuing now rather than five years ago or five years from now.
The long-term vision is not for Create Telecom — the company behind Ready Freddy — to build a competing physical network from scratch — our own hotspots, our own spectrum, our own hardware supply chain. It's to become the AI-driven orchestration layer that sits above the decentralized infrastructure networks other people and projects are already building, routing every call, byte, and compute job to whichever combination delivers the best cost, quality, and reliability at that moment.
Concretely, that means dynamically drawing on categories like these — named here as the kinds of networks the orchestration layer is meant to evaluate and route across, not as current partners or integrations:
None of this requires Create Telecom to own the physical layer. It requires Create Telecom to own the decision — the continuously-updated intelligence about which of these, in combination, is the right answer for a given call or job, right now.
Simplified for this document. A separate technical architecture paper — data flow, APIs, security model — is planned as a later, developer-facing publication.
This is the most important strategic decision in this document, so we want to show our reasoning rather than just assert it.
Helium is the clearest real-world example of the network-ownership path, and it's genuinely working: independent reporting puts its mobile network revenue above $2 million a month as of early 2026, with major carriers now routing meaningful traffic through it as an offload partner. That's a real, working proof that decentralized physical telecom infrastructure isn't just a theory.
It's also useful for calibration. That result took roughly seven years, institutional venture backing, a hardware manufacturing arm, and at least one major strategic pivot — the network started as IoT infrastructure and became a mobile offload network over time. And even now, at its most successful, Helium describes itself as a supplemental layer working alongside incumbent carriers, not a replacement for them.
That's the realistic shape of what "winning" looks like in physical decentralized infrastructure, even for a well-funded, well-connected team. It's not the fight we think Create Telecom (Ready Freddy's parent company) should pick right now.
Here's what doesn't exist yet, as far as we can tell: none of these decentralized networks — connectivity, compute, or storage — are dynamically chosen against each other, or against traditional infrastructure, by an intelligence layer that's optimizing purely for the outcome. A caller doesn't care whether their call rode on a Helium Mobile offload path, a traditional carrier, or something else entirely — they care whether it connected quickly, sounded clear, and didn't cost more than it needed to. That coordination layer — the thing that watches all of these markets simultaneously and picks the best combination in real time — is the opportunity we think is actually open, and it doesn't require manufacturing hardware or acquiring spectrum to build.
We want to be precise about this, because it's easy to slide into treating decentralized infrastructure as the point rather than a means to it. It isn't. The system should choose AWS when AWS wins, a traditional carrier when a traditional carrier wins, and a decentralized network when a decentralized network wins. Being infrastructure-neutral — with no ideological preference for "decentralized" over "centralized" — is what actually makes the optimization honest. The commitment is to the best outcome, not to any particular category of infrastructure.
This is worth answering directly rather than assuming: CPaaS platforms like Twilio, Telnyx, Bandwidth, and SignalWire already do real-time multi-carrier routing and failover as their core product — Horizon 2 is explicitly built on top of their APIs, not around them. So why would a layer above them add anything? "Twilio has huge engineering teams and already optimizes routing" is a fair objection, and we don't think the honest answer is that they can't do this.
The more precise answer: Twilio optimizes within Twilio. Telnyx optimizes within Telnyx. Each platform is, reasonably, trying to be the best version of itself — none of them is trying to be the best version of the entire market, because that would mean routing traffic and revenue to a competitor. The opportunity isn't "do routing better than Twilio does routing." It's cross-ecosystem optimization: evaluating Twilio against Telnyx against Bandwidth against a decentralized network, simultaneously, from a position with no stake in which one wins. That's structurally not something any single CPaaS platform can honestly offer, no matter how good their engineering is — it's not a capability gap, it's a conflict-of-interest gap. The fragmentation between platforms is the opportunity, not the platforms themselves.
Everything so far explains why the opportunity exists. It doesn't explain why Create Telecom is positioned to build it rather than anyone else — that's a different question, and worth answering directly rather than leaving a reader to infer it.
The honest answer is a mechanism, not a boast: Ready Freddy already generates real calls. Every call is a routing decision waiting to be made well. Every completed booking is outcome data about which infrastructure choices actually worked. Feeding that back into routing decisions is what the AI routing layer described in Section 06 is for. Better routing decisions lower Ready Freddy's own costs and improve call quality, which strengthens the product driving the calls in the first place.
That loop is the actual structural advantage, stated plainly rather than left implicit: unlike a network of towers or hotspots, which scales by spending more capital, this scales by accumulating more operational knowledge from ordinary usage. We want to be equally plain about where this stands today — the loop above describes the intended mechanism, and it only becomes a real advantage once call volume is large enough for the feedback to matter. Section 07 says more about why that's a thesis to build toward, not a claim about current scale.
"An AI layer that evaluates cost, latency, and quality" is directionally correct but not precise enough for a technical reader. Here's the more exact version, kept conceptual on purpose — the actual weighting and scoring logic is exactly the kind of implementation detail that should stay internal once it exists, the same way we've kept the Freddy Score's hidden test set private while publishing its category structure.
Conceptually, a route is scored across several dimensions at once — cost, latency, call quality, fraud risk, likelihood of a successful outcome, provider availability, and caller ID attestation integrity — combined into a single score used to pick the best option in that moment. The important insight isn't the formula, it's what falls out of it: the best route is not always the cheapest route.
Two smaller but real technical parameters worth naming alongside these: every call to a ported number requires an LRN (Location Routing Number) lookup to route correctly, and CNAM (caller ID name) data can be dropped or duplicated-and-billed-twice if multiple carriers each perform their own lookup independently during a routing handoff. A control plane coordinating across carriers has to manage these centrally rather than letting each hop repeat the work — a real, if unglamorous, engineering requirement of doing multi-carrier routing correctly rather than naively.
Everything above describes a coordination layer. Coordination layers are valuable, but the actual defensible asset underneath one is usually something else: what it learns by doing the coordinating — and for Ready Freddy by Create Telecom, that learning starts with every real call the product already handles today.
Here's the thesis, stated as a thesis rather than a claim about where things stand today: if this works at scale, the durable advantage isn't owning infrastructure or even owning the routing software — it's the accumulated intelligence about which infrastructure produces the best outcome, for which kind of call, for which kind of customer, at which time and place. That's a fundamentally different kind of asset than a network of towers or hotspots, and it's one a small team can plausibly build, because it comes from usage, not capital expenditure.
The broader pattern this fits: as connectivity, compute, and storage become more abundant and increasingly interchangeable, the scarce resource shifts from owning infrastructure to knowing which combination of it produces the best outcome for a given interaction. It's the same shape as Google not owning the web, Uber not owning cars, or Airbnb not owning hotels — the valuable layer sits above the commodity, not inside it. Traditional telecom optimizes networks. What we're describing here is optimizing outcomes — infrastructure chosen for what it actually produces, not for what it costs on a rate sheet.
Stated as a mechanism rather than left implicit: every interaction makes the system more accurate. Every completed booking is a data point about which routing decision actually worked. Every routing decision that gets made feeds the next one. Unlike physical infrastructure, which scales by spending more capital, this scales by accumulating more operational knowledge from ordinary use — which is also why Section 05 frames this as a real structural advantage rather than just a nice-to-have property.
Made concrete rather than left abstract: this means capturing operational telemetry across every call — audio quality, latency, completion outcomes — and connecting it to actual business results rather than treating it as disconnected logging data. We're intentionally not enumerating the full list of signals this involves; the categories matter for understanding the thesis, the specifics are closer to the kind of operational detail that belongs in execution, not in a document meant to explain why this should exist.
To be clear about where this stands right now: Ready Freddy's current call volume is nowhere near "one of the world's largest datasets of communication outcomes," and it would be dishonest to claim otherwise. That's the aspiration the routing layer is being built toward, not a description of today. The thesis only becomes true if usage genuinely scales — but it's worth stating clearly now, because it changes what the company is actually building toward: not a bigger network, but a better-informed decision engine.
One way to picture this concretely is as a graph rather than a table: carriers, networks, agents, customers, locations, and devices as nodes; call quality, latency, trust, cost, and conversion as the edges between them. The system's job is to learn which paths through that graph tend to work — "this route performs best for this kind of customer, at this time, in this location" — and that graph gets more useful the more real interactions run through it. This is also the natural extension of the Freddy Score work already published: today it measures Ready Freddy's own performance; the same measurement discipline, applied outward, is what eventually scores carriers, compute providers, and storage providers on the same honest, outcomes-first basis instead of their own marketing claims.
Decentralized network coverage, token-based reward economics, and provider pricing all shift constantly and in ways that make a static, manually-configured routing table go stale quickly. Traditional telecom has managed this with periodic manual rate-table updates because the underlying options changed slowly. That assumption breaks down against a landscape with this many independent, fast-moving, decentralized participants.
Continuous, automated evaluation isn't a feature added on top of this vision — it's a requirement of it. This is the same principle behind the Freddy Score framework we use to evaluate Ready Freddy's own performance, applied one layer down: measuring real outcomes across infrastructure providers instead of relying on their own marketing claims about coverage or price.
Worth defining precisely, since "AI routing" gets used loosely enough that it's fair to ask what it actually means here: the goal is a system that learns from observed outcomes rather than one that only ever executes rules someone wrote in advance. That's a real distinction, and we're not going to pretend it's already fully true — the honest starting point is a rules-based system with sensible defaults, because there isn't yet enough outcome data for anything else to be honest, and learned optimization gets layered in as real usage accumulates rather than assumed from day one. Calling day-one a "rules engine" is fair; the point is that it's designed to stop being only that as data comes in, not to stay that way indefinitely.
A vision document is incomplete without an honest pass at the business model, even a directional one. Mapped to the same three horizons, without inventing revenue figures we can't support:
| Horizon | Revenue Shape |
|---|---|
| Horizon 1 | Subscription and usage-based fees for Ready Freddy — the live model today |
| Horizon 2 | A share of the telecom cost savings the routing layer generates, plus direct API/licensing fees for businesses that want the routing intelligence without the full agent product |
| Horizon 3 | Marketplace-style fees for coordinating across infrastructure providers, plus data-driven intelligence products — benchmarking and outcome reporting built on the same measurement discipline as the Freddy Score |
We're deliberately not attaching dollar projections to any of this. A specific revenue number for a system that doesn't exist yet would be a guess wearing the costume of a forecast, and that's exactly the kind of unsupported precision this document has tried to avoid everywhere else.
We said in the last draft that this section needed real research rather than assumed knowledge, since positioning in this space shifts fast and getting a competitor's status wrong would undercut the credibility this document is trying to earn. Here's where things actually stand as of mid-2026, category by category.
Helium Mobile is the clearest proof this category works: independent reporting put its monthly revenue above $2.5M by March 2026, with carrier-offload deals now signed with major U.S. carriers. World Mobile is a real second player — sources report figures ranging from roughly 500,000 to as high as 3 million users depending on the report and date, with 100,000–145,000 AirNodes deployed and expansion into 60+ countries via a hybrid model that includes real phone plans, not just token speculation. Both are genuine, working networks, not vaporware — and both, notably, position themselves as working alongside traditional carriers rather than replacing them, which lines up with what we argued in Section 3.
Akash is the most independently verifiable of the decentralized compute networks — Q1 2026 figures put quarterly lease revenue in the low hundreds of thousands, with compute spend reported around $6.4M as of June 2026 and real, named enterprise customers. io.net claims stronger revenue growth but with a real verification gap — its numbers are self-reported rather than independently audited. Bittensor is a different, adjacent category (a decentralized AI model/inference marketplace rather than raw compute), with over 100 active subnets and real revenue in some of them, alongside real volatility and at least one high-profile operator exit that shook the token's price. All three are legitimate and improving, but none are yet at a scale or reliability that makes them a default choice over traditional cloud for mission-critical workloads.
Filecoin is the largest decentralized storage network by capacity and is explicitly shifting its 2026 strategy from growing supply to proving paid demand — a sign the category is still maturing past the "we have the space" stage into "people are actually paying for it." Arweave serves a different need (permanent, pay-once storage) and remains comparatively small in absolute data volume. Both are real and usable today for the kinds of workloads they're suited to; neither is a general-purpose replacement for traditional storage yet.
This is the most useful thing the research turned up. Sophisticated builders are already manually doing a version of what the AI routing layer proposes to automate: routing a cheaper carrier's pricing (commonly Telnyx, at roughly $0.007/minute) through a more developer-friendly platform's tooling (commonly Twilio, at roughly $0.014/minute) via a setup called BYOC — "bring your own carrier." It's a real, current, widely-documented practice, and it's manual, static, and set up once rather than continuously re-evaluated. That's precisely the gap Horizon 2 is built to close: the arbitrage opportunity is already proven to exist and be worth pursuing by real builders; nobody is running it as a continuously-optimizing, AI-evaluated system yet.
None of these categories are competitors to what Horizon 2 or Horizon 3 propose to build — they're the inventory. Create Telecom's position, if the orchestration thesis holds, is as the layer that watches all of them — connectivity, compute, storage, and traditional CPaaS pricing — simultaneously, and routes to whichever wins for a given task at a given moment. That's a genuinely different position from being one more entrant in any single category above, and it's also why getting each category's actual maturity right matters: the pitch depends on these being real, working, but still-immature markets that benefit from a coordination layer — not on any one of them being either a fraud or a finished, unbeatable incumbent.
The more accessible comparison, for a reader who doesn't know any of the companies above: this is closer in shape to what Cloudflare did for internet traffic than to any telecom company by name. Cloudflare became valuable by intelligently routing traffic across infrastructure it didn't own, not by building its own internet. We're not claiming to be Cloudflare — the comparison is useful for the pattern, not the specifics — but the underlying idea that intelligent routing above infrastructure can be the valuable layer, rather than the infrastructure itself, is a well-understood one outside of telecom specifically.
A vision document is more useful with its weak points named than with them smoothed over. These are the parts we don't have answers to yet.
| Phase | Focus | Status |
|---|---|---|
| Phase 1 | Ready Freddy by Create Telecom live, generating revenue and real call data | Live |
| Phase 1.5 | Telecom Intelligence Engine — carrier abstraction layer, real-time pricing ingestion, call-quality telemetry, route scoring, automated failover, outcome feedback loop, analytics dashboard. The concrete, solo-buildable bridge between Ready Freddy and the full routing layer. Sensible to trigger once Ready Freddy's own call volume is high enough that routing savings would be material — a usage threshold, not a calendar date. | Built (Phase 1.5 Engine Live) |
| Phase 2 | Build and validate the AI routing layer across traditional carriers; offer standalone | Planned |
| Phase 3 | Evaluate early decentralized connectivity networks as cost/quality options inside the routing layer | Planned |
| Phase 4 | Extend orchestration to decentralized compute and storage as those markets mature | Planned |
| Phase 5 | Unified AI-managed orchestration across connectivity, compute, and storage — decentralized and traditional | North star |
Worth stating plainly: the first version — Phase 1.5 — does not require any decentralized infrastructure to exist or mature. It proves the intelligence layer works across infrastructure that already exists today, before expanding the universe of infrastructure it evaluates. That sequencing is deliberate, not a placeholder for "we'll get to the interesting part later."
Ready Freddy by Create Telecom is live proof of execution today, and the Phase 1.5 core Telecom Intelligence Engine is built and verified — handling carrier abstraction, real-time route scoring, STIR/SHAKEN attestation preservation, and outcome-driven telemetry feedback. The AI control plane for communication infrastructure broadly is the destination everything else is in service of.
If you're a partner, developer, or investor who wants to look closer at any part of this, reach out through the Ready Freddy by Create Telecom contact line.