AI Grid: Fabric vs Location Considerations

The debate about where AI compute belongs in a telecom network has been framed as a location question from the start. Do you put the GPUs at the cell site, the central office, the regional data centre, or the hyperscale campus? I have argued consistently that the honest answer begins at the central office and the mobile switching office, because power, cooling, fibre, physical security and latency sufficiency all favour those sites over the tower. That position has not changed. But two announcements from Asia this week suggest the more consequential question is no longer where the compute sits. It is whether the compute behaves as one pool regardless of where it sits.

NTT Docomo disclosed a nationwide testbed it calls GPU over APN. It pools graphics processing units spread across eight locations in five Japanese cities and presents them to a workload as a single platform, connected over the all-photonics network that NTT Group has been building under its IOWN programme. Docomo describes it as the realisation of its AI-Centric ICT Platform concept, part of what the group now labels AIOWN, its AI-native infrastructure. Strip away the acronyms and the claim is precise and significant: distributed GPUs, addressed as if co-located, over deterministic optical transport.

KT made the point from the other direction. Its new chief executive committed 18 trillion won, roughly 11.7 billion dollars, over three years, including 3.26 billion for one gigawatt of AI data centre capacity and a plan to connect that centralised infrastructure with edge sites serving low-latency workloads such as autonomous vehicles and industrial robotics. One operator is making dispersed compute act centralised. The other is extending centralised compute out to the edge. Both are describing the same thing from opposite ends, which is a compute fabric rather than a compute site.

This matters because it decouples two decisions the industry keeps conflating. Where you place a GPU is a question about power, land and cost. Where you run a workload is a question about latency, data gravity and sovereignty. As long as placement and execution are the same decision, every AI deployment becomes a real estate argument. Once a photonic fabric can make placement invisible to the workload, the two decisions separate. Training and heavy batch inference go where power and space are cheap. Latency-bound inference lands close to the user. The fabric arbitrates between them. This does not contradict the case for the central office, it absorbs it: the central office still wins for latency-bound edge inference, but that win is now a node in a graph rather than an isolated site.

I have some history with this problem. In 2018 I wrote about building at Telefonica what was probably the industry's first fully programmable multi-access edge computing platform, and the hardest part was never the compute. It was making distributed compute addressable, governable and billable as a coherent resource rather than a scatter of isolated sites. The technology around it has moved on considerably, but the unsolved problem is the same one Docomo is now attacking with photonics.

A practitioner's caution is in order. A fabric that makes national-scale GPUs behave as one pool is a testbed today, not a product. Docomo demonstrated it in a lab-grade programme. KT's edge connection is a plan, not a live deployment. Deterministic optical transport carrying commercial service level agreements under contended traffic is a materially harder thing than a controlled demonstration, and I would treat "as if co-located" the way I treat vendor energy savings figures: directionally real, quantitatively unproven at scale. The distance between a testbed that works and a fabric that carries production workloads is precisely the distance Open RAN spent five years crossing.

Still, the framing is the takeaway. The AI Grid conversation needs to move from siting to fabric. The operators that win will be the ones who can treat geographically dispersed compute as a single addressable resource, orchestrate workloads across it against real constraints, and price and settle access to it. That is a transport, orchestration and settlement problem before it is a property problem. The question is no longer which building holds the GPUs. It is who owns the fabric that makes the buildings irrelevant.

The Agent Runtime Is Not the Agent Model

DTW Ignite in Copenhagen made one thing clear: the vendor community has decided that the path to autonomous networks runs through agent runtimes. NVIDIA introduced NemoClaw blueprints and the OpenShell secure runtime to give long-running agents policy guardrails and sandboxed access to telecom systems. AdaptKey is piloting security-hardened agents for self-healing 5G operations. ServiceNow is bringing Project Arc to the NOC, orchestrating incident response from alert to work order. NTT DATA is building anomaly agents that escalate to research agents for telemetry analysis. Synthetic data rounds out the stack, a pragmatic answer to the fact that more than half of operators say their most valuable network data is too sensitive to use.

This is genuine progress and I do not want to minimize it. Containment, auditability and policy enforcement are necessary conditions for letting agents touch production networks. An agent that cannot be sandboxed cannot be trusted, and an agent whose actions cannot be audited cannot be certified. The runtime layer has to be built.

Containment is not coordination

But look carefully at what these announcements govern: individual agents, operating within a single operator's domain, executing workflows that a human has scoped in advance. This is vertical governance. It answers the question of whether an agent is allowed to perform an action. It does not answer the question that autonomous networks will actually pose at scale: when two agents are each permitted to act, and their permitted actions conflict, who decides?

Consider a scenario that is closer than most operators think. An enterprise logistics agent requests guaranteed throughput for a fleet of delivery robots. Simultaneously, a network energy agent, operating under its own perfectly valid mandate, is shutting down capacity in the same cluster to meet a sustainability target. Both agents are sandboxed. Both are auditable. Both are compliant with their policies. The runtime layer sees two well-behaved agents. The network sees a contradiction.

This is the problem I described in my previous post on network APIs. APIs were designed for developer access, not for agent-to-agent negotiation. Runtimes inherit the same blind spot. They secure the execution of each agent without providing any shared representation of the agentic plane itself.

What the meta-model requires

For agents to negotiate rather than collide, the industry needs a meta-model of the agentic plane: a topology of which agents exist and where they sit, an ontology so that an enterprise agent and a network agent mean the same thing by capacity, latency or priority, explicit authority boundaries defining what each agent may commit on behalf of its principal, shared state models so that negotiations reference the same view of the network, and audit trails that span negotiations rather than individual actions. None of the DTW announcements address this layer. They cannot, because it is not a product any single vendor can ship. It is a model the industry must agree on, the way it once agreed on network information models for OSS.

There is a familiar pattern here. The industry built firewalls before it built routing protocols for the internet's trust boundaries, and it spent two decades paying for the sequencing. We are building the firewalls of the agentic era first. The operators and standards bodies that formalize the agentic plane meta-model will define how enterprise AI and network AI transact for the next decade. The ones that stop at the runtime will discover that a network full of safely contained agents is not an autonomous network.