What Is the I2ICF Framework? The Beginner's Guide to Agentic AI That Manages Networks, Security, and AI Services

CodexFuse Team · 2026-11-05T12:14:16.433Z · 26 min read min read

What Is the I2ICF Framework? The Beginner's Guide to Agentic AI That Manages Networks, Security, and AI Services

In short, the answer to "what is I2ICF framework" is this: I2ICF is a November 2026 Internet-Draft that describes how AI agents can manage networks, security, and AI services from a plain-language intent. A network administrator states what the network should do in ordinary English, and a chain of AI agents translates that intent into a policy and enforces it on routers, firewalls, robots, and vehicles. The draft was published on 2 November 2026, so it is only three days old as this article goes live, and no independent explainer of it existed before this one.

What Is the I2ICF Framework?

The I2ICF framework is an Intent-Based System (IBS) for managing networks, security, and AI services with agentic AI. Its full title is "An Agentic AI Framework for the Management of Networks, Security, and AI Services," and it is published as Internet-Draft draft-jeong-nmrg-agentic-ai-framework-00. The framework consists of four components — a User System, a Cloud System, an Edge System, and a Device — and the components communicate through AI agents that use the Agent-to-Agent (A2A) protocol.

Here is the idea in one sentence: a human writes an intent such as "keep the guest network isolated from the office network," and the framework turns it into a concrete policy and applies it to the right devices. The draft calls this an Intent-Based System because the human states the outcome, not the steps. The agents handle the translation, the device selection, and the enforcement.

Two details matter from the start. First, the draft is a work in progress, not a standard: it is a first-version (-00) Internet-Draft with intended status Informational, and it expires on 6 May 2027.

Second, it aims at managed networks — data centers, corporate networks, campus networks, and home networks — rather than public networks like the Internet. That scope sentence comes straight from the draft itself.

The framework is aimed at network, security, and infrastructure engineers who want to understand where agentic AI meets network management. It is also useful for anyone following the wave of new IETF drafts that give AI agents a defined role in running infrastructure. This guide covers the four components, the intent-to-policy pipeline, the two protocols inside the framework, the devices it can manage, and the limits the draft itself states.

A SHA-256 hash generator shows the same fingerprint idea the framework relies on: agents identify each other with signed, verifiable cards before they cooperate. And if you run the kind of network I2ICF targets, the place to start is VPS hosting, the hosting lane this article feeds into.

The Problem: Networks Still Run on Per-Device Commands

Today, changing a network usually means changing devices one at a time. An administrator logs into a router, edits an access list, then logs into a firewall and edits a rule, then checks that a switch port matches.

Each device speaks its own configuration language, and the intent behind the change lives only in the administrator's head. A small mistake in one device can quietly undo the change in another.

Intent-based networking was defined to fix exactly that gap. RFC 9315, published in October 2022, defines an intent as a set of operational goals and outcomes stated declaratively, without specifying how they are achieved.

The operator says what the network should deliver, and the system works out how. That definition is about four years and one month older than the I2ICF draft, and I2ICF builds directly on it.

What I2ICF adds is the agent layer. Instead of a single controller translating intents, it uses a chain of AI agents, each powered by a large language model, to carry an intent from the user to the device.

The draft names GPT-3, Flan-T5, and BERT as the kind of models involved. The agents also consult a knowledge base of policy schemas and valid examples, so the translation is grounded in the network's own rules rather than guessed from scratch.

The result is meant to feel like talking to the network. The human states an outcome in natural language, and the framework returns reports about what happened.

Monitoring feeds back into the system, so rules can be adjusted and new rules generated when conditions change. The loop is closed: intent in, enforcement out, reports back.

I2ICF Explained: The Framework at a Glance

The I2ICF framework explained in one table looks like this: four components, four agent types, seven device categories, two protocols, three policy types, and three serialization formats. Everything else in the draft is detail around that skeleton. The table below is built entirely from the draft's own numbers, so it is a faithful summary rather than an interpretation.

The draft itself is 16 pages long with seven numbered sections and two figures. It was written by five authors — Jaehoon Paul Jeong (editor), Mose Gu, and Yoseop Ahn of Sungkyunkwan University, Jung-Soo Park of ETRI, and Byoungman Robert An of KETI — all based in the Republic of Korea.

The work was supported by an IITP grant from the Korea Ministry of Science and ICT, grant number RS-2024-00398199. It sits in the IRTF Network Management Research Group (NMRG), the same group behind RFC 9315.

One more number frames the whole article. Internet-Drafts are valid for a maximum of six months, and this one runs from 2 November 2026 to 6 May 2027 — 185 days in total.

From the publication date of this article, 5 November 2026, 182 days remain before the draft expires. Anything in it may be updated, replaced, or obsoleted before then, so treat every detail here as a snapshot of a three-day-old draft, not as settled fact.

What Is an Intent-Based System?

An Intent-Based System (IBS) is a system that takes an intent from a user or administrator and enforces it on a target system. The intent can be expressed in natural language, such as English, and translated into a policy using natural language processing. In I2ICF, that translation is done by an AI agent called the Intent Translator, which converts the plain-language intent into a structured policy in a domain-specific language.

The key word is "declarative." An intent states what should be true, not how to make it true. "The guest network must not reach the finance servers" is an intent. "Add deny rule 47 to the firewall ACL" is a command.

The first can survive a hardware swap; the second cannot. The I2ICF intent based system keeps the human at the level of outcomes and lets the agents work out the commands.

An intent in I2ICF can become one of three kinds of policy: a network policy, a security policy, or an AI service policy. A network policy might govern routing or bandwidth. A security policy might govern firewall rules or filtering.

An AI service policy might govern which AI service runs where, or which model serves a request. The draft treats all three as the same kind of object: a structured representation of a goal.

The system also watches itself. Monitoring of AI agents feeds back into the framework, and if needed, the rules of a specific intent or a high-level policy are augmented, or new rules are generated and delivered for reconfiguration. That feedback loop is what makes the system "intent-based" rather than merely "intent-translated": the intent stays alive and enforced, not just issued once and forgotten.

How a Human-Language Intent Becomes an Enforced Policy

The heart of the draft is a six-step pipeline that carries an intent from a phone screen to a router, a firewall, or a robot. Every step is named in the draft, and the sequence is the same whether the target is a single switch or a fleet of vehicles. Here is the pipeline, exactly as the draft describes it.

1. The User Agent generates the intent in plain language and sends it to the Cloud Agent or the Edge Agent.
2. The Cloud Agent or Edge Agent translates the intent into a high-level policy with its Intent Translator, consulting the Knowledge Base for policy schemas, valid examples, and semantic constraints, and the Agent Catalog for candidate Worker Agent cards.
3. The Edge Agent refines the high-level policy into one or more specific intents, one per Worker Agent, each serializable as XML, JSON, or YAML for its target model.
4. The Edge Agent sends the specific intents to the selected Worker Agents, and each Worker Agent performs its service using internal resources and external resources through MCP.
5. Operation results — success, failure, alarm, or event — are delivered as reports back up the chain, from Worker Agent to Edge Agent to Cloud Agent to User Agent.
6. Monitoring analyzes agent activity and performance, and rules are augmented or new rules generated and sent for reconfiguration when needed.

Two points in that sequence deserve attention. First, the User Agent must contact the Cloud Agent for authentication and authorization before it can interact with an Edge Agent.

The framework does not let a phone talk straight to the edge without checking in first. Second, refinement preserves the goals and constraints of the original intent: a specific intent is a worker-sized version of the same goal, not a new goal invented by the Edge Agent.

The Knowledge Base is the quiet hero of the pipeline. It is a logical repository that holds domain-specific policy knowledge — target schemas, valid policy examples, and semantic constraints — plus agent metadata in the form of the Agent Catalog. The Agent Catalog is a collection of Agent Cards, the A2A documents that describe an agent's skills and interaction requirements.

The draft notes that the two parts of the Knowledge Base may live in separate physical repositories, and that a graph-based representation is an option. Storage and access are implementation-specific and out of scope.

Agent discovery, interestingly, is also out of scope. The draft names two approaches — reactive discovery through DNS or mDNS, and proactive capability registration in the style of I2NSF — but specifies neither. That is a deliberate gap: the draft defines what the agents do once they know each other, not how they find each other.

Readers who want to learn how to use Claude Code, a real agent that works with tools and files today, can start with the hands-on guide and compare its concrete workflow with the framework's abstract one.

The Four Components: User, Cloud, Edge, Device

The I2ICF user cloud edge device chain is the framework's anatomy. Each component hosts one kind of agent, and each agent has one job in the pipeline. The table below lists them as the draft defines them.

The User System is the simplest component: a person and a screen. The draft lists three example users — a network administrator, a building manager, and a home user — which shows the intended range from enterprise to living room. The User Agent is the software on that screen that turns the person's words into an intent and sends it onward.

The Cloud System is the manager of managers. Its Cloud Agent holds an Intent Translator and oversees multiple Edge Systems.

It is also the gatekeeper: authentication and authorization happen here before a User Agent may interact with an Edge Agent. That ordering matters for security, and the draft's Security Considerations section returns to it explicitly.

The Edge System is where a high-level policy becomes device-sized work. Its Edge Agent refines the policy into specific intents, one per Worker Agent, and manages multiple Devices.

It can also accept a natural-language intent directly from the User Agent, in which case its own Intent Translator generates the high-level policy first and then refines it the same way. The edge is the framework's workshop floor.

The Device is the endpoint, and the draft gives it a name of its own: a Physical AI Object (PAO). A PAO is an object that can move with an AI agent, a power source, and a wireless communication capability, such as 5G Vehicle-to-Everything (V2X).

The draft's Figure 2 shows three example Worker Agents: one for a router or switch, one for a firewall or web filter, and one for a robot, an SDV, or an IoT device. The same pattern covers all seven device categories.

The Seven Kinds of Devices I2ICF Can Manage

The draft's target list is deliberately broad. It spans the network closet, the security stack, and the physical world, because the framework is meant to manage anything an agent can reach. The seven categories below come verbatim from the draft's abstract and first section.

The last three categories surprise most readers, and they are the point. A software-defined vehicle decouples its functions from its hardware and exposes them as software-driven, continuously updatable services.

That makes a car a natural participant in an agentic control plane, just as a router is. The same logic extends to drones and urban air mobility: if a device can receive a policy and report back, the framework can manage it.

The third column of the table is the writer's own illustration of what an intent might govern in each category, not a list from the draft. The draft contains no worked example intents or example policies at all, and that absence is worth stating plainly.

Nobody should quote an example intent as if it came from the draft. The one verified example intent in the whole I2ICF story comes from the July 2026 hackathon demo, not the draft, and it appears in the history section below.

What the breadth does show is ambition. The framework is not a router-configuration tool with a chatbot attached.

It is an attempt to describe one management plane for networks, security, and AI services together, across fixed infrastructure and moving machines. Whether that ambition survives contact with real deployments is an open question the draft does not answer, because it names no vendor, product, deployment, or adoption anywhere in its text.

A2A and MCP: The Two Protocols Inside I2ICF

I2ICF uses two protocols, and confusing them is the easiest mistake a reader can make. A2A is the protocol between agents.

MCP is the protocol between an agent and its own modules and tools. The draft assigns each one a distinct job, and the framework only works if both are in place.

A2A, the Agent-to-Agent protocol, is how the User Agent, Cloud Agent, Edge Agent, and Worker Agents talk to each other. It is an open standard whose latest released version is 1.0.0.

It gives agents a common language built from Agent Cards (JSON documents advertising an agent's identity, capabilities, skills, endpoint, and authentication requirements), Tasks (the stateful unit of work), Messages (turns between agents), and Artifacts (outputs such as documents or structured data). In I2ICF, every inter-agent interface runs over A2A, including Worker Agents talking to each other.

MCP, the Model Context Protocol, is how an agent reaches its own resources. An AI agent in the draft uses computing, storage, and network resources through MCP, which accesses data and file systems, development tools, productivity tools, and physical AI tools.

When a Worker Agent needs to act on its device, it does so through MCP with predefined APIs. The distinction is clean: A2A is agent to agent, MCP is agent to tools.

The draft's own description of an AI agent makes the split explicit. An AI agent is "the software module that can translate a human-language intent into a structured policy in a Domain-Specific Language (DSL)." It communicates with other AI agents via A2A and uses resources via MCP.

If you are learning how these protocols fit together in practice, the explainer on what MCP over MOQT is shows how MCP messages can ride a modern transport, a related but separate piece of the agent-protocol puzzle. And when agents need a sandbox to run code safely, the guide on how to use E2B covers the execution environment that complements the framework's design.

What I2ICF Is NOT: Scope, Limits, and the C-ITS Sibling

The draft is careful about what it does not cover, and those limits are as informative as its features. The most important limit is scope: the framework aims at intent-based systems in data centers, corporate networks, campus networks, and home networks, rather than public networks like the Internet.

I2ICF does not manage the Internet. It manages networks somebody owns and controls.

Security is handled as requirements, not as a solved problem. The draft says authentication and authorization mechanisms "should be used" to check the validity of User Agents. For trustworthy cooperation, mutual authentication "should be performed beforehand" among the Cloud Agent, Edge Agents, and Worker Agents.

An intent from a User Agent "should be evaluated" by the Cloud or Edge Agent to determine whether it is harmful; if it is harmful, it should be logged and the harmfulness reported back to the User Agent that issued it. Finally, the framework "should perform governance by monitoring and auditing" all AI agents, and the auditing system "may operate as an independent entity" so it can audit without bias.

There is also a sibling draft that readers must not confuse with this one. Draft-an-nmrg-i2icf-cits-03, also dated 2 November 2026 and also expiring 6 May 2027, is titled "An Agentic AI Framework for Software-Defined Vehicles in Cooperative Intelligent Transportation Systems." It covers only SDVs in C-ITS — vehicles, roadside infrastructure, and mobile networks — and its unit of work is the AI Computing Function (ACF), such as perception inference or traffic prediction. It defines ten numbered interfaces, I1 through I10, between agents co-located with C-ITS entities like roadside units and vulnerable road users.

None of that belongs to the general framework draft: the general draft has no numbered interfaces and no ACFs. The C-ITS draft cites the general draft as prior work and aligns with it, but it is a narrower application, not the same document.

The C-ITS draft also states its own limit plainly: its use cases describe intended behaviors, not measured performance or deployment results. The general draft contains no performance numbers, benchmarks, latency figures, adoption figures, or pricing either. Any article that quotes I2ICF performance figures is inventing them, because the draft contains none to quote.

The Name History: Why I2ICF Used to Mean Something Else

The letters I2ICF have a history, and the November draft reuses them for something broader than they used to mean. Until July 2026, I2ICF stood for "Interface to In-Network Computing Functions." It was the name of a research program and hackathon project in the IRTF Network Management Research Group, championed by Jaehoon (Paul) Jeong, that built an intent-driven management framework for moving objects such as robot cars.

The proof of concept ran at the IETF 126 Hackathon in Vienna, 18–24 July 2026. The demo stack was Ubuntu 20.04, MicroK8s v1.32.2, YOLO 11n for object detection, Ollama running Llama 3.1 8B as the language model, and ROS 2 Humble driving an AgileX LIMO robot car with a camera and LiDAR.

A user typed a natural-language intent into a web interface — the verified example was "move forward and detour" — and the I2ICF Controller passed it to the language model, which returned a structured command of {action, speed, duration} as a high-level policy. The LIMO then classified the intent, selected an action, and executed it through a rosbridge WebSocket, detecting objects at 10 Hz with YOLO 11n and picking a detour path around obstacles.

The gap between that demo and the November draft is 101 days, from the hackathon's end on 24 July 2026 to the draft's publication on 2 November 2026. In those three and a half months, the I2ICF name grew from a moving-object demo into a general framework for networks, security, and AI services.

The old program is the origin story; the new draft is the generalization. The LIMO demo is not a demo of the November draft, and it should never be presented as one.

An earlier version of the same line of work appeared at IETF 125, where an intent translation server converted natural-language intents into a machine-readable policy document in YAML for the LIMO. IETF 126 added natural intent inference and full-duplex WebSocket communication.

A related 2025 paper, "An Intent-Based Management System for In-Network Computing Functions in Intelligent Moving Objects," presented at ICMU 2025, implemented I2ICF on a Kubernetes-based testbed for intelligent moving objects. The thread from the 2025 paper through the July 2026 hackathon to the November 2026 draft is continuous, and it is also a story of a name outgrowing its first expansion.

Worked Example: A Network Intent, Traced End to End

The draft contains no example intents, so the example below is the writer's own illustration, built from the draft's pipeline and clearly labeled as such. It is not quoted from the draft, and no part of it should be cited as draft content. The intent is deliberately ordinary, because the framework's promise is to make ordinary network administration conversational.

Imagine a building manager who types: "Keep the guest Wi-Fi isolated from the office network after 6pm." The User Agent on the manager's phone generates that intent and sends it to the Cloud Agent. The Cloud Agent authenticates the manager first, then its Intent Translator consults the Knowledge Base — the policy schemas for the building's network, valid examples of isolation policies, and the semantic constraints that say what "isolated" means here — and the Agent Catalog for the Worker Agents that can act on the guest access points and the office firewall. It produces a high-level security policy: guest traffic must not reach office addresses between 18:00 and the next morning.

The Edge Agent receives the high-level policy and refines it into specific intents, one per Worker Agent. The firewall's Worker Agent gets a specific intent to enforce a deny rule for guest-to-office traffic in the evening window. The access points' Worker Agents get a specific intent to tag and separate guest traffic.

Each specific intent is serialized in the format its target model expects — JSON for one, YAML for another — and each Worker Agent performs its service through MCP with its predefined APIs. The results come back as reports: the firewall confirms the rule is active, the access points confirm the tags are applied, and the User Agent shows the manager a single confirmation.

Now compare that with the one verified example intent in the I2ICF story. At the IETF 126 hackathon, a user typed "move forward and detour," and the system returned {action, speed, duration} and drove a robot car around an obstacle it detected at 10 Hz.

The network example and the robot example are the same shape: plain words in, structured policy out, a device acting, a report coming back. The difference is scale — one manages a building's evening traffic, the other steers a moving machine — and that shared shape is the framework's central claim.

The monitoring loop closes both examples. If the firewall reports a failed rule, or the robot reports a blocked path, the framework can augment the rules or generate new ones and send them for reconfiguration.

The intent does not expire when it is first enforced. It stays alive as a goal the system keeps meeting, which is the difference between a command and an intent.

Who Should Care About I2ICF — and What Happens Next

Network and security engineers should care first, because the draft speaks their language: routers, firewalls, DDoS mitigators, and the policies that bind them. If intent-based networking ever moves from conference slides into daily operations, it will look something like this — a chain of agents carrying a plain-language goal down to the device that enforces it. The draft gives that idea a concrete shape: four components, four agent types, two protocols, and a six-step pipeline.

AI platform engineers should care second, because this agentic AI network management framework is also a statement about where agents belong. It places agents inside infrastructure management, not just inside chat windows, and it gives them defined interfaces — A2A between agents, MCP to tools — rather than ad-hoc integrations. The agent protocol work happening across the IETF right now, from schema interfaces to action confirmation, is converging on a world where agents are first-class participants in systems, and I2ICF is the network-management entry in that series.

What happens next for the I2ICF agentic AI framework is genuinely uncertain, and the draft's own status says so. It is a -00 Internet-Draft, the first version, with 182 days left before it expires on 6 May 2027. It may be revised, replaced, or abandoned.

The C-ITS sibling is already at -03, three revisions ahead, because it started earlier — its -00 appeared in January 2026 and its -02 in June. The general draft's authors may revise it after feedback from the NMRG, or the work may fold into other drafts. There is no roadmap in the text, no implementation, and no vendor backing named anywhere.

The honest way to watch it is to watch the drafts. The datatracker page for draft-jeong-nmrg-agentic-ai-framework will show a -01 the moment one appears, and the referenced-by page already shows the C-ITS draft as the only document citing it.

For now, the framework is a three-day-old proposal with a clear idea: let people manage networks, security, and AI services by stating what they want, and let agents work out the rest. That idea is worth understanding before the field fills up with implementations that claim to do it.

Sources

IETF Datatracker — draft-jeong-nmrg-agentic-ai-framework-00, "An Agentic AI Framework for the Management of Networks, Security, and AI Services" (2 November 2026)

IETF — draft-jeong-nmrg-agentic-ai-framework-00.txt, full draft text (2 November 2026)

IETF Datatracker — draft-an-nmrg-i2icf-cits-03, "An Agentic AI Framework for Software-Defined Vehicles in Cooperative Intelligent Transportation Systems" (2 November 2026)

IETF 126 Hackathon — Interface to In-Network Computing Functions (I2ICF) Project slides (Vienna, 18–24 July 2026)

RFC Editor — RFC 9315, "Intent-Based Networking — Concepts and Definitions" (October 2022)

A2A Protocol — Agent-to-Agent Protocol Specification, version 1.0.0

SKKU IoT Lab — "An Intent-Based Management System for In-Network Computing Functions in Intelligent Moving Objects" (ICMU 2025)

IETF Datatracker — documents referencing draft-jeong-nmrg-agentic-ai-framework

Frequently Asked Questions

What is the I2ICF framework?

The I2ICF framework is a November 2026 Internet-Draft that describes how AI agents manage networks, security, and AI services from a plain-language intent. A human states what the network should do in ordinary English, and a chain of AI agents — User, Cloud, Edge, and Worker agents — translates that intent into a policy and enforces it on devices such as routers, firewalls, IoT devices, robots, software-defined vehicles, drones, and urban air mobility craft. It is an Intent-Based System, which means the human states the outcome and the system works out the steps.

Is the I2ICF framework an official IETF standard?

No. It is a first-version (-00) Internet-Draft with intended status Informational in the IRTF Network Management Research Group, published on 2 November 2026 and expiring on 6 May 2027.

Internet-Drafts are works in progress that may be updated, replaced, or obsoleted at any time. The draft itself says it is inappropriate to cite Internet-Drafts other than as work in progress, so it should never be called a standard, an RFC, or a protocol.

What is the difference between the I2ICF framework and the C-ITS draft?

The general I2ICF framework draft covers networks, security, and AI services across data centers, corporate networks, campus networks, and home networks. The C-ITS draft, draft-an-nmrg-i2icf-cits-03, covers only software-defined vehicles in Cooperative Intelligent Transportation Systems, with AI Computing Functions (ACFs) and ten numbered interfaces, I1 through I10. The C-ITS draft cites the general draft as prior work, but the two are separate documents with different scopes, and the ACFs and numbered interfaces belong only to the C-ITS draft.

What devices can the I2ICF framework manage?

The draft lists seven categories: network forwarding elements such as routers and switches; network security functions such as firewalls, web filters, and DDoS-attack mitigators; Internet-of-Things devices; physical AI robots; software-defined vehicles; unmanned aerial vehicles; and urban air mobility craft. Each device hosts at least one Worker Agent, and the framework treats a device as a Physical AI Object — an object that can move with an AI agent, a power source, and wireless communication capability.

How are A2A and MCP different inside I2ICF?

A2A, the Agent-to-Agent protocol, is how agents talk to each other: the User Agent, Cloud Agent, Edge Agent, and Worker Agents all communicate over A2A. MCP, the Model Context Protocol, is how an agent reaches its own modules and tools, such as data and file systems, development tools, and physical AI tools. In short, A2A is agent to agent and MCP is agent to tools, and the framework needs both: A2A carries the intent down the chain, and MCP lets each Worker Agent act on its device.