Intent-Based Networking Architecture Components

IBN is organized into three interdependent layers. The Business Layer is where stakeholders express desired outcomes in business terms, including availability targets, compliance postures, and application performance thresholds. The Intent Layer converts those high-level directives into specific policies and configurations the network can act on. The Data and Network Layer is the execution and observation plane, where physical and virtual infrastructure acts on those policies and returns telemetry upward.

These are not sequential pipeline stages. They operate as components in a continuous, real-time system, and the failure modes are instructive. A Business Layer that produces ambiguous intent poisons everything downstream. An Intent Layer that can't reach across vendor domains creates blind spots. A Data Layer generating telemetry too slowly to drive corrective action at machine speed breaks the closed loop entirely. When practitioners describe IBN implementations as underdelivering, the failure is almost always traceable to a disconnection between layers, not to a deficiency within any single layer in isolation.

How the Business Layer captures and structures intent

Intent is not a free-form instruction. A stakeholder wanting "sub-10ms latency for application X" is expressing a real operational need, but that sentence, as raw input, is not actionable by a network system. The Business Layer's job is to capture that aspiration and structure it into something the Intent Layer can parse, validate, and act on. The quality of everything below this layer is bounded by what this layer produces.

Inputs span a range of mechanisms. GUI-driven policy templates are the most mature and the most constrained. API calls allow programmatic intent submission, enabling integration with upstream business systems. Natural language interfaces backed by large language models are the newest frontier; a 2025 IEEE BMSB symposium study documented work on enhancing intent-based architectures with LLMs and Retrieval-Augmented Generation as an emerging input mechanism. That work is genuinely promising for accessibility, though LLM-generated intent still requires validation logic before it reaches the translation engine. A semantically plausible but operationally contradictory intent passing downstream is a real risk, not a theoretical one.

SLA-to-intent translation frameworks take a more structured approach, converting service-level agreements directly into machine-readable network intents and automating enforcement of quality, reliability, and compliance targets without requiring manual interpretation. TM Forum's Intent Management API, TMF921 version 5.0.0 published in 2024, defines how intents are expressed and managed in a standardized, machine-readable form across multi-vendor environments. It's the closest thing the industry has to a shared vocabulary for this layer, which matters considerably when evaluating solutions that claim interoperability.

The Business Layer must include validation logic, not merely an intake mechanism. When evaluating IBN solutions, the first question is whether intent validation is an explicit architectural function or an implicit assumption the vendor has quietly left to the operator.

The Intent Layer: translating business goals into network policy

Translation is not one-to-one mapping. A single business intent, "guarantee 99.99% availability for this Carrier Ethernet service," requires coordinated policy changes across transport, core, and access domains simultaneously, involving devices from multiple vendors with different configuration models. The Intent Layer performs that reasoning, and the reasoning is genuinely hard.

Its core functions are intent parsing, conflict detection, policy generation, and path computation. AI and machine learning are embedded here by necessity; the system must reason about network topology, current state, and available resources to generate valid configurations. This is not a lookup table operation.

Conflict detection is the hardest problem the Intent Layer faces. When a stringent security policy requiring traffic traversal through a deep-packet inspection node competes with a latency-sensitive performance policy for the same application, the engine must resolve precedence without human intervention. That resolution logic must be deterministic, auditable, and consistent. If it isn't, operators begin treating the system as advisory rather than authoritative, which defeats the entire purpose of the architecture. I've seen this pattern repeat across enough deployments to recognize it as a structural failure mode, not an edge case.

Policy outputs must be expressed in formats heterogeneous infrastructure can consume. This is where abstraction models and vendor-neutral APIs become structural requirements. 3GPP Release 18, defining 5G-Advanced, embeds AI and ML-driven intent management natively within the network, which signals something important: translation capability is being treated as a core network function, not an overlay. The boundary between intent management and network infrastructure is becoming a design requirement, and implementations that treat it otherwise will find themselves rearchitecting sooner than planned.

Closed-loop automation: how the network verifies and corrects itself

The closed loop is what separates IBN from one-way push automation. Configure-and-forget automation is faster than manual CLI but has no mechanism to determine whether the configuration it pushed produced the intended outcome.

The loop operates in four phases. The network executes a policy. Telemetry is collected. The system compares observed state to intended state. If a gap exists, the system reconfigures or escalates, then observes again. This cycle must run continuously at machine speed, because human operators can't close this loop manually at the timescales modern network conditions demand.

Telemetry quality is a hard dependency. Streaming telemetry collected via gRPC, model-driven observability frameworks, and high-frequency data publication from network devices are prerequisites. SNMP polling intervals measured in minutes are insufficient for a closed loop that must detect and remediate a service degradation before an SLA breach occurs. The observation phase must happen at the speed of the network.

Most telecom operators in 2024 remained at autonomy levels 0 through 2 on a standard 0-to-5 scale, with progress toward Level 3 conditional autonomy expected by 2028. The closed loop is the architectural prerequisite for crossing that threshold. Conditional autonomy requires a system that can observe, reason, and act without human initiation at every step.

Several failure modes deserve plain acknowledgment, because they aren't hypothetical. Telemetry latency introduces lag between a state change and the moment the system knows about it. Incomplete domain coverage creates blind spots where the loop can't observe. AI models that misdiagnose root cause can apply corrective actions that worsen the very state they were meant to improve, which is operationally worse than no automation at all. Human escalation paths added as an afterthought, rather than defined within the loop architecture itself, create dangerous ambiguity about when human judgment should override automated action. The architecture must define escalation triggers explicitly, and those definitions must survive contact with an actual outage, not just a design review.

The policy engine and how it governs what automation is allowed to do

The policy engine is distinct from the Intent Layer's translation function. Translation produces configurations. The policy engine defines the boundaries within which those configurations can be pushed and the conditions under which automated action is authorized. It's the governance plane of the IBN stack, and in practice it's the component most commonly underspecified.

Its functions include access control, which determines which intents can trigger which actions; scope limitation, which defines which network domains are in play for a given operation; change approval thresholds, which specify what level of impact requires human confirmation before proceeding; and rollback triggers, which define conditions under which the system automatically reverses a change. In a well-governed IBN architecture, AI-driven actions operate under the same permission structures as human operators: same APIs, same authorization checks, same audit logs.

Deloitte's State of AI in the Enterprise 2026 found that only one in five companies has a mature model for governing autonomous AI agents. That gap shows up most acutely in network operations through the policy engine. Without it, the automation that IBN promises becomes a liability — actions taken without authorization, changes made without audit trail, rollbacks without documented rationale.

The EU AI Act's Annex III high-risk obligations, effective August 2026, classify AI systems used as safety components in critical digital infrastructure as high-risk. Telecom networks qualify. The policy engine is therefore part of compliance architecture. Decision lineage records, meaning not merely change logs but records of why the system chose to act, must be produced in a form that satisfies a regulatory review conducted years after the fact. That's a categorically different requirement than operational logging, and most implementations haven't yet grappled with it seriously. The operators who discover this gap during a compliance review rather than during architecture review will have a much harder conversation.

Automation operating outside defined permission structures is a liability with a deferred due date.

The Data and Network Layer: infrastructure that receives and reports

The Data and Network Layer encompasses the physical and virtual domains where policy is executed — transport, core, access, radio in mobile contexts, and increasingly IoT endpoints. It's not a passive recipient of instructions. It's an active participant in the IBN architecture, and treating it otherwise leads to implementations that look complete on paper and fall apart in production.

Active participation requires that devices support the abstractions and APIs that allow the Intent Layer to configure them programmatically. NETCONF/YANG, gNMI, and OpenConfig are the relevant standards. A network device configurable only via proprietary CLI can't participate in an intent-based architecture in any meaningful sense, regardless of what the vendor's marketing materials claim. Operators assembling IBN stacks must audit their infrastructure for programmability as a baseline requirement.

Telemetry generation is equally active. Streaming, model-driven telemetry is the architectural requirement for closed-loop operation at speed. It's the Data Layer's primary contribution to the feedback loop — continuous publication of ground truth about what the network is actually doing, against which the Intent Layer can compare what the network should be doing.

Digital twins are emerging as a significant component at this layer. A virtual representation of live network state allows the Intent Layer to simulate policy changes before pushing them to production, reducing the risk of corrective actions that introduce new problems. The capability is still maturing, and its full architectural relevance will depend on how well twin fidelity tracks live network state under dynamic conditions — which is itself an open problem.

The O-RAN RAN Intelligent Controller illustrates something architecturally important: intent-aware intelligence being pushed downward into infrastructure. The RIC's ability to receive and act on near-real-time policy directives within the RAN domain demonstrates that the boundary between the Intent Layer and the Data Layer is not fixed. As intelligence distributes into infrastructure, the layers interact more dynamically, generating capability and complexity in roughly equal measure.

The multi-vendor, multi-domain reality of production networks means the Data Layer must expose a consistent interface upward regardless of what diversity exists beneath it. Homogeneous networks are the exception. Abstracting that heterogeneity upward is a prerequisite for an Intent Layer that can operate across domains without vendor-specific customization for every device type, and it's considerably harder to achieve than most architecture diagrams suggest.

How the components connect in practice: the full data flow from business intent to network state

Consider a representative intent traversing the full stack — "guarantee 99.99% availability for this Carrier Ethernet service."

The Business Layer receives that intent, likely through an API call or an SLA-to-intent translation framework, structures it into machine-readable form conformant with TMF921, and validates it for completeness and consistency. The Intent Layer parses the structured intent, checks it against active policies for conflicts, computes the path and redundancy configurations required to achieve four-nines availability across relevant domains, and generates device-level configurations in YANG-modeled formats. The Data Layer receives those configurations via NETCONF or gNMI, applies them across transport, core, and access infrastructure, and begins streaming telemetry back upward. The closed-loop engine compares observed availability metrics to the 99.99% threshold continuously. When a fault event occurs, the system detects the gap within seconds, applies a pre-authorized remediation, and re-verifies. If the gap persists beyond defined thresholds, the policy engine escalates to a human operator with a complete decision log attached.

The handoff points between layers are where integration breaks most often in real deployments. Mplify Alliance (formerly MEF) Lifecycle Service Orchestration APIs, with more than 160 service providers at various stages of adoption, represent a sustained industry effort to standardize these handoffs in carrier service contexts. The inter-carrier ordering problem illustrates how far there is still to go — current provisioning processes remain highly provider-specific, conducted through spreadsheets or one-off solutions. IBN's promise is only fully realized when these interfaces are standardized end to end, and that's not yet the common case.

The end-to-end view surfaces something operators often discover too late. A sophisticated Intent Layer sitting on top of telemetry-poor infrastructure degrades to expensive single-domain automation. A closed loop that can't reach across vendor domains becomes an alert system with a more complex architecture underneath it. The system is only as strong as its weakest integration point, and the weakest integration point is almost never the one that received the most attention during the procurement process.

Where AI fits in the IBN stack, and what "AI-native" means for this architecture

AI is not a single component in IBN. It's embedded across the stack at multiple points with distinct functions at each. At the Intent Layer, AI performs translation and conflict resolution. Within the policy engine, AI contributes anomaly detection and dynamic threshold adjustment. Within the closed loop, AI drives root cause analysis and corrective action selection. Treating AI as a module to be added to an existing architecture, rather than as a participant in a unified architectural framework, is where most IBN implementation failures originate.

The NVIDIA Annual Telecom AI Study from 2025 found that 97% of telecom organizations were assessing or adopting AI. At that saturation level, adoption is a baseline expectation. Where in the architecture AI is embedded is the differentiating question.

Two patterns characterize current implementations. In AI-augmented legacy OSS, AI tools operate alongside existing systems, processing data extracts and producing recommendations that human operators act on. The underlying architecture remains siloed and event-driven; AI makes the old architecture faster without replacing its structural limitations. In AI-native IBN, AI operates on the same data models, APIs, and permission structures as every other component. It's not an observer producing recommendations. It's a participant executing authorized actions within a governed framework. The distinction is architectural, and it shows up in operational outcomes over time rather than in marketing literature.

The "too much disconnected intelligence" problem is recognizable in large operator environments — every domain has its own AI model, but no unified intent layer coordinates them. Each domain becomes locally smarter while the network as a system does not. The domains optimize against their own objectives, which can conflict with each other or with overarching business intent. Without a shared intent layer to arbitrate, the aggregate result can be worse than a simpler, centrally coordinated system. Local optimization is not systemic optimization, and confusing the two is a costly architectural mistake that compounds quietly before it becomes visible.

AI-native doesn't mean AI-only. Human operators must retain the ability to inspect, override, and escalate at any layer. An architecture that makes human intervention harder in the name of automation has inverted its own value proposition. The goal is that AI handles the volume of decisions that exceed human capacity while humans retain clear authority over the decisions that exceed AI's reliability. That boundary is not static, and any implementation that treats it as fixed will require renegotiation as autonomy levels increase.

Natural language intent capture via generative AI at the Business Layer reduces the technical barrier for expressing intent but introduces a new class of validation requirement — ensuring that semantically coherent intent expressed in natural language maps accurately to the operational outcome the stakeholder actually needs, before it propagates into the translation engine. That validation layer is not optional. It's where the accessibility gain either holds or collapses.

What operators should look for when evaluating IBN implementations against this architecture

The three-layer architecture provides an evaluation framework that cuts through vendor positioning. Apply it directly, and be willing to sit with incomplete answers.

At the Business Layer, the core question is whether the solution provides genuine intent capture with validation logic or a configuration GUI with a modern interface. These are not the same thing. If the "intent" a system accepts is a set of device parameters expressed in business-friendly labels, the Business Layer is cosmetic. Ask what happens when two intents conflict. A manual review queue is not a validation architecture.

At the Intent Layer, the test is whether a single intent can trigger coordinated policy changes across heterogeneous infrastructure. Template matching within a single domain doesn't constitute translation in any sense that RFC 9315 would recognize. This is worth pressing on specifically, because domain scope is where vendors have the most latitude to draw architectural boundaries that favor their installed base.

At the closed loop, the question is whether it actually closes automatically, or stops at alerting. A system that detects gaps and notifies operators without acting is a sophisticated monitoring system. Call it what it is.

Governance questions are non-negotiable. Do AI-driven actions pass through the same authorization and logging pipeline as human actions? Can the system produce a decision audit trail sufficient for an EU AI Act high-risk compliance review? These are operational requirements that become urgent at the worst possible moments.

Data model coherence is easy to overlook during evaluation and expensive to discover afterward. An IBN stack assembled from point solutions, each with its own data model for qualification, design, provisioning, and activation, reproduces the fragmentation problem it was supposed to solve, now at a higher abstraction level. The integration cost and data consistency risk are structurally identical to the problems that prompted the IBN investment in the first place.

Interoperability credentials signal whether an implementation is built to integrate or built to lock in. TMF921 alignment, Mplify LSO API support, and IETF RFC 9315 conformance are meaningful indicators. Their absence tells you more than their presence.

Ask any vendor to state explicitly where their implementation sits on the 0-to-5 autonomy scale and what operational changes are required to move up that scale. A vendor with a real architecture can answer this with specificity — a defined autonomy level, a set of prerequisites, a realistic timeline. Vague answers to that question are their own kind of answer.

The most rigorous test is how the system behaves under failure. Closed-loop systems that escalate incorrectly, roll back blindly, or lose audit trail integrity under load aren't production-ready IBN. Any evaluation that omits stress-testing of failure handling is incomplete, because the system's behavior under abnormal conditions is precisely what justifies the investment. Normal conditions are the easy part.