How a Tier-1 Telecom Is Building
Multi-Domain Service Orchestration, Agent-Based Provisioning, and Spec-Driven Development Across SD-WAN, IP/MPLS, & Branch Connectivity Domains
Challenge
Manual, multi-domain service provisioning across SD-WAN platforms, IP/MPLS orchestration, and branch connectivity required deep per-controller expertise, slowed activation timelines, and couldn’t be safely opened to AI-driven execution without governance, audit, and human-in-the-loop controls.
Solution
Itential FlowAI and the Itential Platform provided a unified orchestration layer where the architecture team could build goal-based agents, deterministic workflows, and end-to-end multi-domain service flows – with the same enterprise governance applied to both AI and human-initiated actions.
Why Itential
Selected for the deterministic-plus-agentic execution model, native multi-controller integration, Spec-Driven Development capability, and platform-level governance that allowed agents to take action on real infrastructure with auditability, approval gates, and policy controls built in.
When Service Complexity Outpaces Manual Integration
A Tier-1 communications service provider operates across consumer, enterprise, and wholesale markets, delivering connectivity, SD-WAN, and managed services across multiple countries and customer segments.
As enterprise demand for hybrid connectivity grew, the architecture team faced a familiar problem: every new service required orchestration across multiple controller domains, each with its own API surface, service model, and operational pattern. Provisioning a single customer service often meant coordinating actions across multiple SD-WAN platforms, an IP/MPLS service orchestrator, and branch connectivity infrastructure – with manual handoffs, custom integration code, and engineer-intensive validation between each step.
The team had built strong internal automation. But scaling that automation across new services, new controllers, and new customer segments meant rebuilding integration logic each time. And as AI entered the conversation, leadership needed a way to introduce agent-driven execution without giving up the governance, traceability, and control their enterprise customers required.
The speed at which my team was able to build this – and how much they learned in the process – was a shock. This was one of the best POCs we’ve ever run.
Enterprise Connectivity Architecture Lead
As agents scale, you have to think about which ones stay agents and which ones become deterministic workflows. The cost-and-control tradeoff is the next conversation.
Enterprise Connectivity Architecture Lead
Multi-Domain Provisioning Was Already Hard, AI Made It Harder to Reason About
Service activation across SD-WAN, IP/MPLS, and branch connectivity domains required deep familiarity with each controller’s service models, API conventions, and execution patterns. Engineers had built integrations that worked – but maintaining them, extending them, and onboarding new domains required engineering bandwidth the team did not have.
Adding agentic AI to that mix raised harder questions. How would agents know which tools to use? How would the team prevent runaway execution? How would they audit what an agent did, who approved it, and what it changed?
The team needed a way to introduce AI reasoning into operations without losing the governance and predictability that made automation safe in the first place.
Tool Selection and Cost Were Strategic Concerns from Day One
The team was thinking past the demo. They wanted to understand how agents would behave at scale – token consumption per run, which agents could be safely converted to deterministic workflows once their patterns stabilized, and how to govern what tools agents could access at build time versus runtime.
This was not a curiosity question. It was a deployment readiness question.
We need to know what an agent costs to run, what it has access to, and how to evolve it over time. That’s how we operate at scale.
Service Orchestration Architect
The Team Wanted to Build It Themselves
Rather than watch a vendor demo, the architecture team wanted hands-on experience. They wanted their own engineers building agents, hitting errors, iterating, and proving – to themselves – what was actually possible in their environment.
They asked for four working days, access to the platform, and Itential’s team in a support role. Not leading. Supporting.
Why They Chose Itential
The architecture team evaluated what it would take to make agentic operations real in their environment.
Several criteria shaped the decision.
1 An Orchestration Foundation That Makes AI Action Safe
AI agents can only act responsibly when they have a governed, deterministic execution layer beneath them. Itential provides exactly that – well-defined, auditable workflow execution that AI can invoke reliably, with policy enforcement and access controls built in. For the team, this wasn’t just an automation requirement. It was the prerequisite for agentic operations.
2 Native Multi-Controller Integration
The Itential Platform integrated with multiple SD-WAN controllers, the IP/MPLS service orchestrator, and branch connectivity infrastructure through native API ingestion, with the same integration model exposed as tools to FlowAI agents. This meant agents could reason across multiple controller domains, including across competing controllers in the same domain, without custom integration code per service.
3 Spec-Driven Development for Domain Experts
Itential’s published Claude skills allowed architects to define agent intent in plain language, then watch the system check feasibility, design the solution, build the agent, self-test it against the live environment, and document what it learned – including its own deviations and corrections.
4 Platform-Level Governance Applied to Agents
Enterprise governance – RBAC, audit logging, secrets management, approval workflows, SSO – applied natively to agent execution, not bolted on after the fact. Every agent action was traceable, every change auditable, every approval recorded.
5 Token Consumption Visibility
The platform exposed per-step token consumption for each agent execution, giving the team the foundation to track agent cost over time, identify high-cost agents, and convert stabilized patterns to deterministic workflows when appropriate.
6 Human-in-the-Loop by Default
Approval gates could be inserted at any point in agent execution, with the option to route approvals through change management systems the team already used. Agents could draft, validate, and stage changes, but humans approved them.
Itential is the vendor agnostic abstraction layer. Everything is just an API. Everything looks the same, regardless of what’s underneath – and that’s exactly the foundation you need before AI can act on your infrastructure.
Infrastructure Automation Lead
Together, these capabilities allowed the team to introduce agentic operations into a production-grade telecommunications environment without trading off the governance that enterprise operations require.
Building Agent-Driven Multi-Domain Service Orchestration in Days
In four working days, the architecture team – supported, not led, by the Itential team – built a working proof of concept that crossed multiple controller domains and demonstrated agent-based, deterministic, and hybrid execution patterns.
The team built:
Five working FlowAgents spanning SD-WAN customer creation, branch site provisioning, multi-domain L3VPN service activation, configuration compliance, and day-two operations
Multiple deterministic workflows stitching agents into end-to-end service flows, with human-in-the-loop approvals routed through their existing change management process
A full Spec-Driven Development build where one architect defined agent intent in plain language and watched the system design, build, and self-test the agent against the live environment
An end-to-end orchestration flow that crossed three controller domains in a single deterministic execution – combining IP/MPLS service activation, branch site provisioning, and SD-WAN customer creation into one customer service
Workflows the Team Built During the Engagement
Agent-Based SD-WAN Customer Creation
A goal-based FlowAgent that creates a new customer in the SD-WAN controller, selects the appropriate gateway pool from a live API query, and validates configuration before provisioning – with a human approval gate before any change reaches the controller.
Agent-Based Multi-Domain L3VPN Activation
A FlowAgent that reads service model schemas from the IP/MPLS service orchestrator, maps incoming service characteristics to the correct model, performs a dry-run validation, presents the proposed configuration for human approval, and commits the service to the controller.
Spec-Driven Agent Generation
Using Itential’s published skills, architects stated their intent in plain language. The system asked clarifying questions, generated a specification document, validated feasibility against the live environment, designed the solution, built the agent, self-tested against the API, encountered a permissions error, self-corrected, and delivered a working agent – fully documented – in under fifteen minutes.
Configuration Compliance and Day-Two Operations
Direct integration with lab devices via Itential Automation Gateway, enabling configuration compliance checks, command execution, and pre/post-validation as part of standard operational workflows.
Multi-Domain Service Orchestration
A deterministic end-to-end workflow that bundled L3VPN provisioning, branch site creation, and SD-WAN customer activation into a single service flow – exposing existing agent-built capabilities as composable building blocks for higher-level service products.
Outcomes the Architecture Team Validated
PROVEN VELOCITY
Five Agents & Multiple Workflows Built in Four Working Days
The architecture team built working agents across multiple controller domains in a single working week, validating that agentic operations could be deployed without the months-long integration cycles required by traditional approaches.
DOMAIN EXPERTISE WITHOUT PLATFORM EXPERTISE
Spec-Driven Development Closed the Gap Between Intent & Execution
Architects without deep platform-build experience were able to describe agent intent in plain language and have a working, self-tested agent generated against their live environment – shifting the role of the domain expert from builder to author.
GOVERNED AGENT EXECUTION
Every Agent Action Was Auditable, Approvable, & Reversible
Human-in-the-loop approvals, RBAC, audit logging, and explicit build-time tool selection were applied to every agent – demonstrating that agentic operations could meet enterprise governance requirements without compromise.
TEAM CAPABILITY
Two Architects Walked Out Able to Demo the Platform Themselves
By the end of the week, the team had not just seen agentic operations work – they had built it. Both lead architects on the engagement could demonstrate FlowAI to their own leadership and extend the work without further support.
What’s Next
With agent-based service provisioning, deterministic multi-domain orchestration, and Spec-Driven Development validated against the live environment, the team is evaluating expansion across additional service domains, including security service insertion, transport-layer provisioning, and managed service activation. Areas of continued focus include agent memory architecture for cross-service context, FinOps-style consumption tracking to support long-term cost optimization, and broader integration of Spec-Driven Development into the team’s standard build process.
