- AI agents should interpret intent and propose network actions, while a deterministic decision layer settles them, because many of these decisions must land in milliseconds while other agents compete for the same resources.
- Across 130 operators studied by TM Forum and IBM’s Institute for Business Value, 72% say they run AI in a trustworthy way, but only 14% have both that confidence and evidence structured for external audit.
- Proving AI is trustworthy is an architecture problem before it is a governance problem. Evidence reconstructed from logs spread across an orchestrator, a policy engine, and a network element is a story, not proof captured at the moment of decision.
- A decision ledger commits the state read, policy version, agent proposal, decision, and action together as one fact, so answering a regulator’s question months later takes a single lookup.
- As intelligence moves to distributed edges, decisions have to move with it. The version that scales runs a local, current, consistent, and recorded decision layer that handles routine cases deterministically and escalates only ambiguous or novel ones to AI.
TL;DR
I spent most of TM Forum Innovate Americas in Dallas on October 6-7, 2026, in back-to-back meetings and missed nearly every keynote. The hallway made up for it. In almost every conversation about autonomous networks, two topics came up: network APIs and agentic AI, often in the same sentence.
Now that I’ve caught up on the stage content, I think the hallway and the keynotes were circling the same unresolved question. Agents can now reach into the network. When they do, who decides what actually happens?
Who should decide when an AI agent reaches into the network?
Not the agent. An agent should interpret intent and propose an action. Something deterministic should settle it, because many of these decisions must land in milliseconds while other agents compete for the same resources.
One pattern stood out in Dallas. Intent-based services already sit on top of network APIs, and the next step is to make them autonomous with agents. The catch is time.
Take any request that consumes a shared network resource, such as an agent asking for guaranteed quality for a session. Before granting it, something must check available capacity, apply the requester’s policy, and protect commitments already made to everyone else on that resource. An agent can reason about all of that. It should not be the component that settles it thousands of times a second.
Agents also should not query the network’s state store directly. Governance starts with what you expose. Give an agent a semantic capability, such as “can this session get guaranteed throughput for the next ten minutes?”, instead of raw capacity tables. That limits how far it can go rogue before any policy runs.
Will AI agents become CAMARA’s main consumers?
I suspect they will, and CAMARA is already heading there. Adoption came up constantly in Dallas, and the project itself has acknowledged that winning developers over is hard. Agents may be the more natural consumers.
CAMARA’s white paper of January 12, 2026 describes an MCP server that turns CAMARA APIs into tools agents can discover and call, and Orange has contributed a working implementation. That is the right direction, with two cautions.
First, a call that goes through an agent and an MCP server will be slower than a direct API integration. Teams serious about automation should combine three modes:
- Direct API calls for known, high-volume paths.
- ML inference where patterns are learned and predictable.
- Agents where intent needs interpreting, or the situation is new.
Second, exposing a tool is not the same as deciding. Behind every tool that changes something in the network sits a decision that must be fast, consistent, and explainable.
Why can only 14% of operators prove their AI is trustworthy?
Because most evidence is reconstructed after the fact rather than captured at the moment of decision.
The number I keep coming back to comes from TM Forum’s research with IBM’s Institute for Business Value, first presented at DTW Ignite in June 2026. Across 130 operators, 72% are confident they run AI in a trustworthy way. Only 18% hold evidence structured for external audit, and only 14% have both the confidence and the evidence. Of the 64% who believe they could document evidence to a regulator, just 17% actually hold externally reviewable evidence. TM Forum and Accenture used Innovate Americas to launch the Trustworthy AI Governance Certification, aimed squarely at that gap.
The report is blunt about why. Functions such as billing and network control need deterministic systems, not the probabilistic outputs LLMs produce. Periodic attestation was built for deterministic systems that change slowly, and it breaks down when agents change constantly. Evidence must become continuous.
That makes proof an architecture problem before it is a governance problem. Reconstructing an agent’s action afterward from logs spread across an orchestrator, a policy engine, and a network element gives you a story, not evidence.
What is a decision ledger?
A decision ledger is a record in which the state read, the policy version applied, what the agent proposed, what was decided, and the action taken all commit together as a single fact at the moment of decision.
When the decision and its record commit together, evidence becomes a byproduct of how the decision was made. Here is what that looks like for one request. An agent managing a live event stream asks whether a session can get guaranteed throughput for the next ten minutes:
- Read: the decision layer reads current capacity on that cell and the guarantees already committed on it.
- Apply: it applies the requester’s policy, at the version in force at that moment.
- Decide: capacity allows it without breaching existing commitments, so the request is granted.
- Record: state, policy version, proposal, decision, and action commit in the same transaction.
- Act: only then is the network instructed.
If a regulator asks months later why that session got priority, the answer is one lookup, not a forensic exercise across three systems. The report notes that no industry consensus exists yet on what evidence should look like. A decision ledger is one concrete answer.
How do you resolve conflicts between AI agents in real time?
Distribute the decisions along with the intelligence.
In his keynote, AT&T’s network CTO Yigal Elbaz described AI agents as an engine for physical AI too, meaning robotaxis, drones and robots whose inference may run in the cloud or at distributed edges. He also raised a hard question: when different agents and rApps conclude different actions, how do you resolve the conflict in real time?
Those two points belong together. If intelligence is distributed, the decisions must be distributed as well. The decision layer that sits beside the agents needs four properties:
- Local: it runs where the event happens, not a round trip away.
- Current: it decides on live state that updates as events arrive.
- Consistent: the same inputs produce the same answer, even when requests compete.
- Recorded: every decision leaves evidence behind.
Should AI make every network decision?
No. AI should be where the hard decisions go, not where every decision starts.
Accenture’s Arnab Chakraborty described agentic AI as a shift “from AI supporting decisions to AI making decisions.”7 I would adjust that. The version that scales does not have AI making every decision. Deterministic logic handles routine cases that policy already covers and escalates to AI when it detects ambiguity or conflicting signals.
That keeps the millisecond path fast, and inference cost proportional, and it turns each AI intervention into a recorded, explainable exception.
To be upfront: this is the layer we build at Volt Active Data, so I am not a neutral observer. Most operational decisions are routine and should be handled deterministically. Volt makes those decisions in real time, against authoritative state, and escalates only the ambiguous or novel cases to ML models, AI agents, and human reviewers. It commits state, decision logic, and the record of each decision in one ACID transaction, and it can export the decision, its context, and the triggering event to a ledger such as an Apache Iceberg table.
Whatever technology you choose, the pattern holds. Let agents propose. Let something deterministic decide, and keep the evidence.
INFOGRAPHIC
See how a deterministic decision layer supports autonomous operations.
What is a decision ledger?
A decision ledger is a record where the state read, the policy version applied, the agent’s proposal, the decision, and the resulting action all commit together as a single fact at the moment of decision. Because the record and the decision commit at once, evidence is a byproduct of how the decision was made rather than something rebuilt later. If a regulator asks why a session got priority, the answer is one lookup.
What is the AI evidence gap in telecom?
The AI evidence gap is the distance between operators’ confidence that their AI is trustworthy and their ability to prove it. TM Forum and IBM’s Institute for Business Value found that 72% of 130 operators are confident they run AI in a trustworthy way, but only 18% hold evidence structured for external audit and only 14% have both. Of the 64% who believe they could document evidence to a regulator, just 17% actually hold externally reviewable evidence.
Should AI agents make network decisions directly?
No. An agent should interpret intent and propose an action, while a deterministic decision layer settles it, because many of these decisions must land in milliseconds while other agents compete for the same resources. Governance also starts with what an agent can see: exposing a semantic capability, such as whether a session can get guaranteed throughput, instead of raw capacity tables limits how far an agent can overreach before any policy runs.
How will AI agents use CAMARA network APIs?
Through MCP servers that turn CAMARA APIs into tools agents can discover and call. CAMARA’s January 2026 white paper describes this approach, and Orange has contributed a working implementation. Two cautions apply: a call routed through an agent and an MCP server is slower than a direct API integration, and behind every tool that changes the network sits a decision that still has to be fast, consistent, and explainable.
When should operators use direct APIs, ML inference, or AI agents for network automation?
Use each for the work it fits. Direct API calls suit known, high-volume paths. ML inference fits patterns that are learned and predictable, and agents belong where intent needs interpreting or the situation is new. Teams serious about automation combine all three rather than routing everything through an agent.
Why can't operators prove AI decisions using logs?
Logs scattered across an orchestrator, a policy engine, and a network element produce a reconstructed narrative, not proof captured when the decision happened. Periodic attestation was built for deterministic systems that change slowly, and it breaks down when agents change constantly. Evidence has to become continuous, which makes it an architecture problem before it is a governance one.
How do you resolve conflicts between AI agents in real time?
Distribute the decisions along with the intelligence. AT&T’s network CTO Yigal Elbaz raised this question at Innovate Americas: when different agents and rApps reach different conclusions, something has to settle the conflict immediately. That requires a decision layer that runs where the event happens, decides on live state, returns the same answer for the same inputs even under competing requests, and records every outcome.
When should a network decision escalate to AI?
When deterministic logic detects ambiguity, conflicting signals, or a situation policy doesn’t already cover. Routine decisions stay on the deterministic path, which keeps the millisecond path fast and inference cost proportional to difficulty rather than volume. Each AI intervention then becomes a recorded, explainable exception.
About Author
Featured Resources
