I returned from DTW Ignite in Copenhagen with one conviction: the interface between enterprise applications and network infrastructure is about to change in a way the industry has not yet designed for.
Network APIs were never really about autonomous networks. That framing conflates two separate problems. APIs — CAMARA, GSMA Open Gateway, the decades of network exposure work that preceded them — were designed to let developers discover and consume network resources from outside the operator domain. Quality on Demand, location services, device status, number verification: clean REST interfaces exposed through a developer portal so that a programmer writing a B2B application could request a network capability and pay for it. Real progress on a real problem. But the problem was developer access, not network autonomy.
What is coming next is different in kind, not degree.
Enterprise AI agents are beginning to consume network infrastructure directly — not through a developer writing an integration, but autonomously, in real time, as part of executing a business objective. An industrial automation agent that needs guaranteed low-latency connectivity for a robotics fleet. A financial services agent that needs to provision a secure, isolated network path for a time-sensitive transaction. A logistics agent that needs to dynamically reserve bandwidth across multiple carrier domains as a shipment moves between jurisdictions. In none of these cases is there a developer in the loop. The agent has an intent, it needs network resources to fulfil it, and it needs to negotiate those resources with the network — now, at machine speed, without human mediation.
That negotiation cannot happen through a developer portal. It cannot happen through a static API catalogue with a PDF explaining what each endpoint does. The enterprise agent and the network need to speak to each other, and neither CAMARA nor MCP — whatever their respective merits — were designed for that conversation.
The network side of this exchange needs to be represented by network AI agents of its own: agents that can expose available capacity in real time, understand the constraints and commitments already in place, reason over competing demands, and negotiate resource allocation in a way that respects the network's operating boundaries. That is not a developer API. That is an autonomous counterparty.
And for those network agents to function — to negotiate reliably, to be governed, to be audited, to avoid conflicting with each other across RAN, transport, core, and the operational layers of OSS and BSS — they need something the industry is not yet building: a meta-model of the agentic plane itself.
Operators building autonomous networks are doing the right foundational work. Network topology models. Data ontologies. Decision layers. Closed-loop control architectures. These give the automation layer a complete and current picture of the environment it is operating in. But agents operating on that network need an equivalent model of themselves. Every agent with an identity, a capability scope, an authority boundary, a state, a dependency graph, and an audit trail. An abstract topology and ontology of agents, sitting alongside the topology and ontology of the network.
Without that model, what looks like autonomous negotiation between enterprise AI and network AI is actually uncontrolled interaction between systems that cannot see each other. An enterprise agent requesting bandwidth does not know what the network agent is authorised to commit. The network agent does not know what other network agents have already promised. No shared representation, no conflict detection, no governance.
The developer exposure problem is largely solved, or at least well understood. The agent-to-agent negotiation problem has barely been framed. That is the conversation the industry needs to have, and Copenhagen convinced me we are not having it yet.
No comments:
Post a Comment