| Internet-Draft | AIN Deployment | April 2026 |
| Feng | Expires 21 October 2026 | [Page] |
The Agentic Intent Network (AIN) architecture defines a routing-based coordination substrate for open, heterogeneous, Internet-scale multi-agent systems. This document describes applicability and deployment scenarios for AIN, targeting decision-makers in carrier networks, enterprises, and network equipment vendors. It maps the technical mechanisms defined in [AIN-ARCH] to concrete operational contexts, describes migration paths from existing infrastructure, and discusses the cold-start bootstrapping challenge inherent to network-effect-dependent systems. This document does not define new protocol mechanisms; it is intended to inform deployment planning and expand the AIN reader community beyond protocol engineers.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 October 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The AIN architecture, defined in [AIN-ARCH], is written primarily for protocol engineers and researchers. That text defines problem drivers, architectural components, design invariants, and a research agenda with the rigor required for interoperable implementations. Deployment decisions, however, are often made by a different audience: operators, CTO organizations, enterprise architects, and product managers.¶
These stakeholders usually ask a different first question. They do not ask, "What is the exact on-wire encoding?" They ask, "Why should we do this now in our environment, and what is the lowest-risk first step?" This document answers that question. It maps mechanisms from [AIN-ARCH] to concrete operational contexts and migration paths that begin from current infrastructure.¶
This style has precedent in IETF/IRTF Informational publications. [RFC7454] and [RFC8799] translate protocol concepts into deployment and operational guidance for decision-makers. AIN benefits from the same approach because adoption is shaped by migration cost, role incentives, sequencing, and governance timing, not only by protocol design.¶
The scenarios therefore use narrative language intentionally. Decision makers evaluate trajectories, not just mechanisms. They need to compare before/after positions, identify where value appears in Months 1-6, and understand where unresolved research still exists. This format makes those trade-offs explicit without changing protocol semantics.¶
This document does not define new AIN packet fields, new capability advertisement semantics, or new management objects. Normative protocol behavior remains in the architecture document [AIN-ARCH]. Normative language here is used only for critical operational constraints where architecture compliance matters directly; the rest is descriptive guidance for planning.¶
Four scenarios are included: carrier operator, enterprise, equipment vendor, and AI-native developer. Together they cover likely early adopters and ecosystem enablers. Final sections address cold-start bootstrapping and clarify compatibility expectations with existing standards, including explicit inter-domain cautions.¶
All AIN-specific terms, including Intent Router, Handler, Originator, IC-OID, CAP, CRT, Agent Domain, Mode A through Mode E, and the Foreman Pattern, are defined in [AIN-ARCH] and are not redefined here.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses SHOULD where architecture compliance is important. Otherwise, it uses descriptive language.¶
The following terms are defined for use in this document. They describe deployment roles, execution modes, and coordination patterns that are relevant to the scenarios presented here. They are consistent with the component model defined in [AIN-ARCH] Section 5.5 and are introduced here to support deployment planning without requiring additional companion documents.¶
Scenario 1 models a carrier operator that already runs large routing infrastructure and seeks monetization beyond commodity transport. This scenario is included because carriers can start AIN at one PoP with incremental operational risk.¶
Scenario 2 models an enterprise that is both Originator and Handler provider. This scenario is included because internal integration simplification can produce immediate value before any external peering.¶
Scenario 3 models a network equipment vendor. This scenario is included because deployment speed depends on software enablement of existing hardware fleets.¶
Scenario 4 models an AI-native developer. This scenario is included because many teams have application protocols but still lack scalable discovery and routing across domains.¶
| Scenario | Primary Role | AIN Entry Point |
| Carrier Operator | RIO / IAP | Single Agent Domain at one PoP |
| Enterprise | Originator + Handler Provider | Internal Intent Router deployment |
| Equipment Vendor | Enabler | Software module on existing HW |
| AI-Native Dev. | CP / Originator | Handler registration via CAP |
Consider a carrier with PoPs in multiple regions, a mature BGP full-mesh underlay, and enterprise customers requesting API integration services. Traffic grows while revenue per user declines.¶
The pain point is that customers increasingly want agent-to-agent collaboration, while the carrier can monetize only bandwidth. The intent layer between enterprise systems remains outside the carrier's service model.¶
The operator upgrades edge routers at one PoP to support CAP as a software module and deploys the first Agent Domain. AIN does not require new hardware categories; Intent Router forwarding and CAP support are implemented as software modules on existing router platforms [AIN-ARCH]. Enterprise Handlers then register to their nearest PoP.¶
| Phase | Plan |
| Phase 1 (Months 1-6) | Single-domain pilot; static CRT; Mode C Gateway Execution for legacy enterprise APIs |
| Phase 2 (Months 6-18) | OSPF-inspired intra-domain CAP propagation; dynamic CRT; multiple PoPs connected |
| Phase 3 (Months 18-36) | Inter-domain CAP exchange with peer carriers (BGP-inspired inter-domain protocol, subject to ongoing research; see Section 7.2 of [AIN-ARCH]) |
| Phase 4 (36+ months) | Handler capability marketplace portal; per-query billing analogous to DNS resolution combined with CDN delivery |
IMPORTANT: Phase 3 is BGP-inspired in structure (capability prefix aggregation, border policy filtering, and per-domain administrative autonomy) but is NOT a literal BGP wire-protocol extension. It requires new protocol design currently under research. Operators SHOULD NOT plan Phase 3 based on [RFC4271] wire compatibility.¶
| Dimension | Before AIN | After P1/P2 | After P3/P4 |
| Revenue model | Bandwidth only | Managed domain fee | Intent routing + marketplace |
| Enterprise value proposition | Connectivity only | Internal discovery and routing | Cross-domain capability exchange |
| Technical complexity | Familiar IP operations | Added CAP and CRT ops | Inter-domain policy and governance |
| Inter-carrier coordination | Transit peering | Optional | Required for ecosystem scale |
Consider a multinational manufacturer in five countries with SAP, Salesforce, ServiceNow, and proprietary MES systems. Each new integration requires custom adapters and bilateral maintenance.¶
A procurement AI assistant may need to trigger supply-chain replanning in another business unit where API documentation is not available. This reproduces the N(N-1)/2 integration pattern. At N=20 systems, that is 190 pairwise integrations.¶
Deploy a lightweight Intent Router on x86 servers running CAP software. Existing SAP and Salesforce interfaces are wrapped as Mode C Handlers using Execution Runtime adapters. Internal AI assistants become Originators.¶
Integration complexity collapses from O(N^2) pairwise links to O(N) registrations.¶
Phase 1: Single Intent Router, internal network only. Existing systems wrapped as Mode C Handlers. Internal AI assistants as Originators. IC-OID namespace governed by internal IT policy.¶
Phase 2: Connect to carrier AIN domain. Cross-BU collaboration. Introduce Mode A Handlers for AI-native services. Adopt Foreman Pattern for dynamic worker pools.¶
Phase 3: Selectively expose Handlers to external partners. Join AIN ecosystem as Capability Provider. Participate in inter-domain routing.¶
| Metric | Before AIN | After Phase1 | After Phase3 |
| Integration complexity | O(N^2) custom links | O(N) inside one domain | O(N) with governed exposure |
| Discovery overhead | Manual docs and contacts | Internal CRT lookup | Cross-domain lookup via policy |
| Cross-BU latency | Human relay and tickets | Programmatic resolution | Routed with external partners |
| Governance overhead | Distributed and opaque | Central IT namespace control | Expanded trust and contracts |
Consider a mid-size vendor with routers deployed in more than 200 carriers. BGP/OSPF business is stable but growth is slow. Carriers now ask about AIN readiness.¶
The pain point is perceived hardware commoditization risk if AIN functionality is treated as software only.¶
| Path A (Defensive) | Path B (Offensive) |
| Implement CAP support as optional software module | Package edge routers as "AIN-ready" line and provide turnkey first Agent Domain deployment |
| Allow existing routers to join AIN control plane | Bundle hardware + software + deployment services |
| Do not proactively market readiness | Proactively market readiness before standards freeze |
| Timeline: 6-12 months software work | Timeline: 12-18 months to first reference deployment |
| Risk: Low, Cost: Low, Upside: preserves current position | Risk: Higher, Cost: Higher; Upside: ecosystem positioning before standards freeze |
| Downside: misses first-mover position | Downside: larger execution and market risk |
Regardless of path, Phase 1 is identical: implement Intent Router forwarding and CAP support as software modules on existing hardware. [AIN-ARCH] confirms no new hardware category is needed; Intent Router forwarding and CAP processing are software functions.¶
A vendor that completes Phase 1 can switch from Path A to Path B at any time.¶
Because [AIN-ARCH] Section 5.6 Invariant 1 separates forwarding from execution, forwarding hardware retains differentiated value and the commodity risk is lower than initially feared.¶
Teams building with LangGraph or A2A often have good in-domain agent collaboration but no shared discovery mechanism across organizations. They still negotiate bilateral APIs and maintain static endpoint files.¶
A2A defines interaction format (analogous to HTTP) but not discovery or routing. Endpoint knowledge must still be known in advance. At scale this reproduces O(N^2) coupling.¶
Existing agents register as Handlers via CAP and become discoverable through IC-OID without requiring callers to know concrete endpoints.¶
A2A agent cards are candidate inputs to AIN CDL. MCP tool integrations can be wrapped as Mode A Handlers.¶
Step 1: Register existing agents as Handlers. Assign IC-OIDs. No change to core agent logic; add CAP registration and Intent Datagram ingestion adapter.¶
Step 2: Replace static endpoint config with Intent Router lookup. Originators emit Intent Datagrams; routing resolves Handler location dynamically.¶
Step 3: Use Foreman Pattern for dynamic worker pools. Worker lifecycle events do not force CRT churn.¶
Step 4: Enable cross-domain discovery when inter-domain routing is available (Phase 3 prerequisite; see Section 4.3).¶
Key insight: AIN is not a replacement for A2A or MCP. A2A defines handshake semantics; AIN provides discovery and routing so handshake can happen without prior endpoint knowledge.¶
AIN value grows with network effects; more Handlers make routing useful to more Originators. First deployers therefore begin with a thin ecosystem.¶
This is not a design flaw. It is the same bootstrap challenge faced by routing infrastructures in their early phases, including the commercial Internet.¶
Mode C is central to cold-start because it turns legacy complexity into routable capability while keeping rewrites out of the critical path.¶
A Mode C Handler presents one AIN-facing interface while it orchestrates many legacy internals. From routing perspective, a large SAP estate with many transaction types can appear as one registered Handler under well-defined IC-OIDs.¶
This is the Foreman Pattern at the integration boundary: worker complexity stays local while routing-state growth remains controlled.¶
AIN reuses protocol structures where semantics transfer exactly. It introduces new mechanisms where IC-OID identifier semantics diverge from topological IP addressing.¶
Operators can use the compatibility table below to plan tool-chain investment and identify low-friction reuse points.¶
| Existing Technology | AIN Usage | Reuse | Notes |
| OSPF Opaque LSA ([RFC5250]) | Intra-domain CAP propagation | Structural analogy | New convergence theory required |
| BGP MP Extensions ([RFC4760]) | Inter-domain CAP exchange | Structural analogy | Not wire-compat.; New protocol |
| NETCONF/YANG ([RFC6241]/[RFC7950]) | AIN management plane | Direct reuse | Management plane |
| SNMP OID format | IC-OID structure | Structural analogy | Different governance model |
| DNS resolution | IC-OID Registry governance | Structural analogy | DA not in forwarding path |
| A2A agent cards ([A2A2025]) | CDL capability description | Candidate reuse | Under evaluation |
| MCP tool spec ([MCP2024]) | Handler execution runtime | Candidate wrapper | Wrappable as Mode A Handler |
| IP TTL / hop limit | Datagram hop count | Exact reuse | Identical semantics |
Operators with existing NETCONF/YANG infrastructure can reuse it directly for AIN management-plane functions. This is likely the lowest-cost integration point for experienced operators.¶
This document does not define new protocol mechanisms and therefore introduces no security considerations beyond those in [AIN-ARCH].¶
Deployment scenarios that use Mode C (Gateway Execution) should account for access-control boundaries when legacy systems are wrapped as AIN Handlers. Existing ACL and authentication controls on wrapped systems remain in effect and are not bypassed by AIN routing.¶
Operators should validate that exposing a legacy capability through a Mode C interface does not unintentionally broaden privilege scope. Least-privilege role mappings, credential hygiene, and auditable logs should be part of initial deployment readiness checks.¶
In multi-tenant deployments, operators should also ensure that tenant boundaries in legacy back-end systems are preserved at the Handler boundary, especially when one Mode C gateway fronts multiple internal services. Admission control, request attribution, and replay-resistant authentication are important companion controls for production rollout. None of these controls are replaced by AIN routing; they remain local obligations of the wrapped execution environment.¶
This document has no IANA actions.¶