An operator's network platform team onboards connectors the way every platform does: one at a time, each with its own review. The performance-management connector reads cell-level KPIs through the element manager's northbound interface — throughput, drop rates, handover success, PRB utilisation. The alarm-feed connector reads correlated fault events. The configuration-management connector pushes parameter changes through the orchestration API: antenna tilt, power, neighbour lists, load-balancing thresholds. The ITSM connector creates change tickets and closes them. The subscriber-messaging connector sends outbound notifications through the campaign gateway. Five connectors, five reviews, five defensible conclusions. The security review looked at transport and token handling. The network architecture review confirmed the orchestration API enforced parameter bounds. The vendor assessment checked the element manager's API contract. Nobody was careless.
Then the automation team builds a fault-remediation agent and enables all five.
This whole trace is a constructed illustration — the five connectors, their reviews, the agent and everything it does below. It is not a client engagement, not a disclosed incident, and not a description of any named operator's deployment; the connectors and the reviews are invented. I have assembled it from mechanisms that are documented in public network-management architectures and in the operators' own published descriptions of their agent programmes, because the argument needs a concrete trace and I will not manufacture one out of somebody's outage.
The agent's job is written in one sentence: when a cell degrades, diagnose the cause, remediate what is remediable, and open a ticket for what is not. It is a good job. It is the job the sector's own announcements describe, and it is the job that turns hours of a network operations centre shift into a minute of machine time. Nobody who has sat in a NOC at three in the morning thinks this is automation for its own sake.
Now trace what was composed, rather than what was asked for.
The performance connector's credential is not scoped to the degraded cell, because no element manager issues credentials per cell. It is scoped to the domain the EMS manages — every cell in the region, every KPI stream the northbound interface exports. The configuration connector is the same shape: the orchestration API's service account can write parameters across the domain, because that is what an orchestration account is. The review approved a connector for configuration management, and configuration management is what it got. That part of the story is the standard composition problem, and I have made the general argument elsewhere: the unit of grant is a connector, the unit of authority is the enabled set, and nothing in the pipeline records the distance between them.
What is specific to this sector — and the reason this piece exists separately — is the third connector. The ITSM grant looks like the safest thing in the set. It writes tickets. It touches no network element. And it is the connector that dissolves the operator's most important compensating control, because the change record is the artefact the whole discipline of network change management is built on, and the agent now writes it. When the agent pushes a parameter change and then opens and closes the change ticket that describes it, the record of the change was authored by the actor of the change, in the same process, on the same plan, with no second party anywhere in the loop. The control still exists. It fires on every change. It has simply stopped being a control, because the thing it was checking and the thing doing the checking have been composed into one capability.
And this is the sector where the stakes of that composition are not like the others. When a mis-scoped agent in an insurer reads too many rows, the damage is measured in records: disclosure, remediation, notification. When a mis-scoped agent holds write access to a live radio network, the blast radius is the service itself. A bad neighbour-list change does not leak data; it drops calls for every subscriber the cell serves, for as long as the change stands, including whoever in that coverage area is trying to reach an emergency service. Availability failures are shared, physical and immediate, and they do not wait for a breach-notification clock. The composition problem is general. The units it is denominated in here — service availability and subscriber reach — are not.
The objection that has to be answered first
The strongest response to everything above comes from inside network operations, and it deserves its full weight, because the people making it are describing something real and they are usually right about their own discipline.
Network change management is one of the most mature control regimes in the enterprise, and it got that way the hard way. Every material change to the production network travels as a change request with a method of procedure attached — the exact commands, the exact order, the verification steps, the rollback plan. A change advisory board reviews it. A maintenance window is assigned, usually in the small hours, sized to the risk. Golden configurations exist, and configuration-audit tooling diffs the live network against them and screams about drift. High-risk changes get a second pair of hands on the bridge. The whole apparatus exists because the sector learned, over decades of outages with regulators and front pages attached, that the network is changed carefully or it is changed catastrophically. Telling a change manager at a tier-one operator that changes to their network go unreviewed is not just wrong; it is insulting to the specific institutional memory their process is built out of.
So concede all of it, because all of it is true. And then look at where each of those controls attaches.
Every control in that list attaches to a change. The composition was never a change. A change request describes an intended action: this parameter, this cell, this window, this rollback. The agent's capability is not an intended action — it is a standing ability to take a class of actions, assembled by enabling connectors on a platform. No change request was raised when the fifth connector was enabled, because enabling a connector is a configuration act on an IT platform, not a change to the production network. The change discipline is not being bypassed. It is aimed at a different object, and the object it is aimed at — the individual change — is precisely the thing the agent will generate hundreds of, each one small, each one plausibly within bounds, under a capability that was never itself the subject of anything.
The compensating record is written by the actor. The honest answer to a standing capability has always been the record: we cannot pre-approve everything, so we evidence everything and review after. That answer assumed the record-keeper and the actor were different parties. Give the agent the ITSM connector and the assumption silently fails — not because anyone decided the agent should self-certify, but because ticket creation is an API and the API is a connector and the connector was harmless on its own. A reviewer of the ITSM connector saw a tool that writes tickets. Only the composition makes it self-attestation, and no review's input was the composition.
Configuration audit detects drift, not authority. The config-audit tooling will faithfully diff the live network against the golden configuration and flag the agent's change — as it flags every change, including the legitimate ones, which the agent's mostly are. The audit answers: does the network match the intended state. The question the composition raises is: who was entitled to move the intended state, on what scope, inside which window, and the audit has no representation of that question. A drift detector pointed at an agent that files its own tickets converges to a detector that confirms the agent's paperwork. This is the telecom instance of a general fact — logs and diffs are posterior and per-event, while capability is prior and set-shaped — and the general version is argued in the connector-catalogue piece. What is local to this sector is that the posterior record was the load-bearing control.
There is a second objection, quieter, which I will hold until the end: that the agent came from the vendor — the RAN vendor, the cloud partner, the platform — and was reviewed by the vendor, so the composition is the vendor's problem. It has the most commercial weight behind it and the least architectural support, and it deserves its own section rather than a paragraph.
Two pipelines, and the object between them
State the structural fact flatly, because everything else in this piece hangs on it. The operator runs two mature review pipelines. Platform onboarding reviews connectors: it runs once per connector, before any agent exists, and its output is a standing platform-level grant. Change management reviews changes: it runs once per change, and its input is a specific intended action. The composed agent is neither a connector nor a change. It is a standing capability assembled after onboarding ended and before any change begins, and there is no queue whose input shape matches it. The gap is not a missing step in either pipeline. It is an object with no pipeline, and organisations do not review objects that never arrive in a queue.
This is why the finding survives the maturity of everyone involved. The platform review was competent. The change discipline is excellent. The agent teams are careful. The composition still went unreviewed, because reviewing it was nobody's input. If the argument sounds familiar, it should — it is the review-unit-versus-consumption-unit argument from the platform teardown, transposed. What transposition adds is the second pipeline: a bank or an insurer has one review apparatus that misses the set, while an operator has two, and the existence of the second one — the change discipline — is exactly what makes the miss invisible, because everyone can point at a control regime that is genuinely strong and genuinely aimed somewhere else.
Adoption is production-real, on the record
None of this would matter much if network agents were a lab exercise. The reason it matters now is that the sector's own announcements put them in production, and the honest way to use those announcements is to attribute them and keep the vendor arithmetic at arm's length.
Deutsche Telekom announced its RAN Guardian agent with Google Cloud on 25 February 2025 — a multi-agent system, built on Gemini models, described by the companies as analysing RAN behaviour in real time, detecting anomalies and performing self-healing actions, unveiled as the first agent of its kind introduced by an operator. Deutsche Telekom's subsequent press material on its network agents describes event volumes in the hundreds of thousands and diagnosis workflows compressed from hours to around a minute. Those are the companies' own accounts of their own deployment — I am citing them as evidence of intent and direction, not as audited measurements, and the figures should be read the way all vendor-announced figures should be read.
Two more data points, held at the same arm's length — and held at different lengths from each other, which is the point. The 56 percent in-production figure does have a primary: Google Cloud's second-edition ROI of AI in telecommunications research, conducted by National Research Group and published in October 2025. That is a vendor-commissioned survey of executives' self-reports, published by a company selling the thing being adopted, and 'in production' was defined by the respondents rather than audited — so it is attributable but not authoritative. The companion figure circulating alongside it in 2026 trade coverage, 71 percent deploying during 2026, I could not trace to any primary publication with a stated methodology and sample frame; it appears here as a temperature reading and not as a measurement, and anyone quoting it harder than that should be asked for the source. And press coverage of Bharti Airtel's network-operations AI programme has reported mean-time-to-repair reductions in the range of 30 to 50 percent — again the operator's reported number, again not independently verified here. The direction of all of it is consistent and is the only claim I need: this is not a pilot story. The sector that runs physical infrastructure for entire populations is the sector furthest into production with agents that touch it.
Notice what the headline value actually is. Hours to a minute is not a story about better analysis — analysis was never the bottleneck at three in the morning. It is a story about removing the human gate between diagnosis and action. The latency compression that justifies the programme is precisely the deletion of the step where a person looked at the plan before it ran. I am not arguing that gate should always exist; there are classes of action where autonomy is the right engineering call. I am arguing that its deletion is the single most consequential authority decision in the deployment, and in the shipping pattern it is made implicitly, by composition, rather than anywhere a decision could be recorded.
The rulebook, read honestly
Now set the adoption curve against the instruments that exist, because this sector's regulatory position is the inverse of the one the governance conversation usually assumes, and getting it wrong in either direction costs credibility.
In India — the market with some of the fastest operator adoption — there is, as of June 2026, no AI-specific telecom regulation in force. That is a verified absence, not a rhetorical one, and it should be stated carefully: the instruments that exist in the telecom space govern commercial communication to subscribers, and the general obligations of licence conditions, quality-of-service regulations and outage reporting continue to attach to the operator regardless of what operated the network. But there is no instrument whose subject is machine operation of the network, and no consultation I could verify that has one in draft. In the United States, the Federal Communications Commission's declaratory ruling of 8 February 2024 confirmed that AI-generated voices fall within the TCPA's definition of an artificial or prerecorded voice, bringing calls that use them inside the existing consent regime. Read its scope precisely: it governs what an AI voice may say into a subscriber's ear. It says nothing about what an AI system may do to a cell site, and it was never meant to.
The temptation is to read this as clearance — no instrument, no problem, build. The reading I would defend is the one this argument's banking cousin earned the hard way when the US banking agencies put generative and agentic systems expressly outside their revised model-risk guidance in April 2026: an absence of specification is a deferral, not an exemption. Every obligation attached to the underlying action — the licence, the QoS floor, the outage report, the consumer-protection regime — is untouched. What is missing is the document that would have told an operator which controls discharge those obligations for an agent, which means each operator is deciding for itself, and whatever instrument eventually arrives will be drafted by people looking at what operators built in the interval. The thinness of the rulebook does not lower the stakes of the composition question. It relocates the question to the operator, and it starts the clock on who answers it first.
And there is one flank where a named instrument binds today, and it binds by composition, which is why it belongs in this piece rather than in a compliance memo. The fifth connector in the opening trace — the subscriber messaging gateway — looks like an operational courtesy: tell affected customers the network is degraded, tell them it is fixed. The moment an agent holds it, the agent is a sender of commercial communication in a jurisdiction that regulates exactly that. India's TCCCPR 2018 built a full machinery for it — registered senders, registered headers, subscriber consent and preference categories, complaint handling — and TRAI's Second Amendment of February 2025 tightened that machinery, with a draft Third Amendment in consultation as of mid-2026. Whether a given outbound message is a service notification or a commercial communication under those categories is precisely the kind of judgement that was made, historically, by a campaign team that owned the gateway and answered for it. An agent that composes network observation with subscriber outreach makes that judgement at run time, under a connector grant that was reviewed as a messaging integration. The one place the rulebook is not thin is the place the composition crosses into it without a review whose input was the crossing.
What specifically fails
Five mechanisms. Each one is a compositional failure — a property that exists only because grants are held together — and each is stated with the control it defeats, because the interesting failures here are not absences of control but controls aimed at the wrong object.
1. The review unit does not match the consumption unit, twice. Platform onboarding reviews connectors and terminates at publication. Change management reviews changes and begins at a change request. The composed capability is assembled between the two, by configuration, and neither pipeline's input shape can hold it. This is the structural finding, and everything below is a consequence of it.
2. The record-keeper is inside the toolbelt. The change ticket is the operator's canonical evidence object, and the ITSM connector turns its authorship over to the actor. Self-authored records still satisfy every downstream consumer — the audit sampler, the post-incident review, the regulator's outage enquiry — because nothing in those consumers checks who wrote the record against who performed the act. The control degrades silently: it keeps producing artefacts, and the artefacts stop being evidence.
3. The grant does not know what a maintenance window is. The operator's entire risk calculus for network change is windowed: the same parameter push is routine at 02:00 and reckless at 17:00 on a match day. The connector credential is a standing grant with no temporal shape — nothing in the token, the scope or the platform configuration distinguishes the window from the peak. The most important variable in the sector's own change discipline is simply not representable in the grant vocabulary the agent runs on, so the agent's authority at the worst moment is identical to its authority at the safest one.
4. Read and execute are priced the same, and the asymmetry is the whole risk. In the enabled set, the KPI read and the config push are peers — two connectors, two checkboxes. In the network they are different orders of consequence: the read can at worst leak topology and performance data; the write can degrade service for everyone a cell serves. A capability vocabulary that cannot express the difference between observing the network and acting on it will keep producing enabled sets where the marginal checkbox quietly crossed the only line that mattered. The line has a name in every NOC — read-only access versus change access — and the platform grant surface does not carry it.
5. The subscriber-outreach flank crosses a regulated boundary at run time. An agent holding both network observation and the messaging gateway decides, per event, whether and what to tell subscribers. That decision instantiates TCCCPR consent-and-preference judgements — made historically by an accountable campaign owner — inside a plan no human wrote, under a grant reviewed as an integration. When the complaint arrives, the operator must reconstruct why the message was sent and under which category, from a record the same agent wrote. Every element of that sentence was separately reasonable; the sentence was reviewed by no one.
Where this argument runs out
Architectural claims are cheap unless the person making them states what would show them wrong. Four things, at full strength.
The adoption figures are weaker than the adoption. The 56 percent figure is attributable — a vendor-commissioned survey of executive self-reports, which is a measurement of what leaders say rather than of what is running. The 71 percent figure is unpinned: I could not trace it to a primary publication with a methodology, and I have said so where it appears. The operator announcements are primary but promotional: an announced agent is not a measured deployment, and hours-to-a-minute is the companies' own framing of their own system. If the true state of the sector is pilots wearing production language, the urgency claim weakens — though the composition claim does not, because the composition exists the day the connectors are enabled, at any scale.
The strongest genuine counter is that the write path is gated in practice. It may be that shipping network agents are, overwhelmingly, read-and-recommend systems — that every config push still travels through a human-approved change request, and the autonomy in the announcements is autonomy of diagnosis, not of action. Under that reading the composed capability I have described is rare, the ITSM connector files tickets a human still owns, and this essay describes a failure mode the sector has quietly declined to build. I cannot rule that in or out from public documentation, and I would rather name it as the live alternative than argue past it. The test is simple to state: for each production agent, does any credential it holds allow a parameter change without a human decision in the loop, and can the operator show which. An operator that can answer that from an object rather than from tribal knowledge has most of what the companion piece proposes.
The measurement that would settle it has not been taken. The decisive distribution is unpublished and probably uncomputed: across an operator's production agents, how many sit at each rung — read-only, recommend, execute with a gate, autonomous within a window — and on what network scope. No operator, vendor or regulator publishes it; I have seen no evidence it is internally tracked as an object rather than as scattered configuration. Every claim in this piece about invisible composition is, in the end, a claim about what that distribution would show, and it is computable today from configuration the operator already holds.
Three things would falsify the argument as stated. First, an operator whose agent grants are minted per intent — scoped to cells, parameters and windows at the moment of dispatch — would make the standing-capability premise locally false, and I would want to study that deployment rather than defend the thesis against it. Second, evidence that ITSM connectors in shipping agent platforms enforce a distinct-party rule — the closing actor cannot be the executing actor — would remove the self-attestation mechanism. Third, an instrument or published operator framework whose subject is the composed capability of a network agent would collapse the thin-rulebook claim, and I would cite it with relief in the next revision.
One limit on the remedy space, stated here so the companion cannot be read as ignoring it. The value proposition of these systems is latency — hours to a minute is the announcement's own arithmetic — and every gate inserted between diagnosis and action spends the value the programme was funded on. Any construction that answers this teardown has to preserve legitimate autonomy where it was deliberately chosen, or it will be routed around by the same rational pressure that assembled the composition in the first place.
The vendor objection, and the decision nobody framed
Now the deferred objection: the agent came from the vendor. The RAN vendor ships it, the cloud partner co-built it, the platform reviewed it. Composition assurance is their product problem.
As a statement about contracts it may even be true, and it does not survive contact with the question. When the outage enquiry, the licence-condition review or the TCCCPR complaint arrives, it arrives at the operator — the licensee, the sender of record, the party whose network degraded. The operator's answer must be assembled from the primitives it actually holds, and if the only primitives are connector grants and self-authored tickets, the answer is a list of integrations and a stack of paperwork written by the machine under discussion. The vendor is upstream of the capability and downstream of none of the obligations. Every question lands on the party that did not choose the grant vocabulary, which is the same inversion the platform teardown found, with a licence attached.
The reframe worth leaving with is that the operator already knows how to do this — better than any sector now deploying agents. The maintenance window, the method of procedure, the two-party change, the rollback plan: these are composition controls, invented by this industry, for exactly the reason this piece exists — because the network is changed carefully or catastrophically. What has not happened is their transposition from the change pipeline, where they bind actions, to the capability layer, where the agents now live. That transposition — capability manifests per agent, blast-radius classes ordered from read to autonomous-in-window, window-scoped grants, and the audit object that shows which class every production agent sits in — is a construction, and it is the companion to this piece: Blast-radius classes for network agents. A teardown that hands you the ladder in its last section has not made you feel the drop.
For now, the smallest useful action costs an afternoon. Take one production agent. Put its credentials on one page. For each, mark read or write, network or record or subscriber, and whether any write path executes without a human decision. Then ask who, if anyone, ever saw that page as one thing. The page is the object this piece says is missing, and the silence after the question is the finding.