A read on Cisco's new Multicloud Fabric from someone who helped bring ACI and Tetration to market, and who recently tried to build this from scratch.
I'll start where I don't usually start a competitive post: I'm genuinely excited about this.
I spent fourteen years at Cisco. I led solutions architecture for its worldwide cloud networking software, and earlier I helped bring Cisco ACI and Cisco Tetration to market. I have real affection for that company and the people in it. So when Cisco unveiled Multicloud Fabric at Cisco Live, I read every line. And my first reaction was not "here's what's wrong with it." It was: good. When the largest networking company on earth stands up at its flagship event and says multicloud networking and security is the problem of the AI era, that's not a threat to what we do. It's validation of a problem space we've been living in for years. More serious entrants make the whole category better.
So let me do two things. Give Cisco credit for the half of the problem they got right. Then offer a builder's read on the half they half-baked, and the questions I'd be asking if I ran a heavy-Cisco shop.
Cisco got Half the Problem Right
Applications now span clouds. Traffic funnels through centralized hubs that add latency, failure points, and scale limits. Bolted-on security can increase risk. And agentic AI is multiplying cross-cloud traffic. Cisco's own data puts agentic workflows at roughly 450% more network traffic than the same tasks done manually, most of it inference chaining across clouds. I agree with every word of that. I've been making the same argument for three years.
But that diagnosis is really two problems, and Cisco mostly addressed one of them. Connectivity is half the problem. Security is the bigger half, and it's the half the AI era actually punishes you for getting wrong. Multicloud Fabric is, at its core, a connectivity answer with security stapled to the side. I'll come back to that, because it's the crux.
I'll go further on the connectivity half, because I take it seriously. A few weeks ago I decided to remind myself, hands-on, just how hard this really is. I sat down and built a large multicloud network, with security, using only the cloud providers' first-party components — and I built it with AI coding tools, the exact approach everyone now says makes this easy. The honest result: assembling the connectivity was fast. Troubleshooting it was not. The moment something behaved differently than I expected, I was knee-deep in a fragmented, cross-cloud mess, and the sheer volume of config the tools generated just to make it work was its own proof of how complex the underlying design really is. And that was before I added security.
I do this for a living — I'm about as expert as it gets in this space. If it was that hard for me, with the best tooling available, it is brutal for a stretched enterprise team holding it together across three clouds at 2 a.m. So when Cisco says connectivity has to get simpler, they're right, and I'm glad they're saying it loudly. I'd only add one thing: the AI didn't make the architecture simple. It made a complicated architecture faster to stand up — and that is not the same thing.
Now Read What They Shipped
The on-ramp is the Cisco SD-WAN installed base, starting with Meraki MX. The fabric routes through virtual points of presence that Cisco deploys and operates inside the clouds. Security is firewall service chaining, enforceable per connection.
Those aren't footnotes. They're the architecture, and they're worth holding against the problem Cisco just described.
Cisco warned that centralized connectivity hubs add latency, failure points, and scale limits, then built a fabric that routes through points of presence Cisco runs. To be precise and fair: those vPoPs live in the cloud, so this isn't the old hairpin out to a physical edge. But a centralized fabric you don't operate is still a centralized fabric. It's a chokepoint and a single large failure domain, run by someone else, sitting in the path of your most latency-sensitive AI traffic. That is the thing Cisco itself flagged as the risk.
Now the security half, which is where I think they fell short. Cisco warned, correctly, that bolted-on security increases risk. Then they secured the fabric with firewall service chaining. Read what that actually is: the fabric optionally steers your traffic to a firewall, in most cases a legacy appliance you bring along, chained onto the connection. That is the definition of bolted-on. They named the anti-pattern in their own problem statement and then shipped it. Security here isn't a property of the network; it's an appliance the network is configured to detour through. That's the half-baked part, and it's the more important half.
And the way in is to already be a Cisco SD-WAN customer. There's nothing wrong with serving your installed base. But it tells you what question the architecture was built to answer.
Why I Can Say That
I can say it because I helped build the predecessors. ACI was a data center fabric. Tetration put an agent on every workload. Both were excellent at what they were designed for. Neither was designed for a workload that is a serverless function living for nine hundred milliseconds, on a cloud where you run no Cisco gear.
That realization is, honestly, the a-ha moment that brought me to Aviatrix. I'd spent years building the best versions of the old model, and I kept running into the same wall: the cloud doesn't want an appliance in the path or an agent on every workload. It wants the network itself to enforce policy. Once I saw that clearly, I couldn't unsee it, and I wanted to go build the thing the cloud actually requires rather than keep extending the thing it doesn't. So I have a lot of empathy for the team that shipped Cisco Multicloud Fabric. I've been in that exact seat.
The architecture a company ships tells you what it can build. Cisco shipped the answer to one question: what can we extend from what we already sell, and operate as a service. That's a reasonable question. It's just a different question from what the cloud actually requires.
What the Cloud Actually Requires, and Where We've Spent Our Years
What the cloud ultimately requires is enforcement that lives in the network itself, distributed across the data plane, not in a box that traffic gets steered toward. Policy that follows workload identity, so it holds when the workload scales, moves, or is replaced. Coverage that doesn't care whether the workload is a VM, a container, a serverless function, or an AI agent, and doesn't need an agent on each one. A data plane the customer owns and can see into, on any cloud, with no vendor hardware as the price of entry. And when a compromise lands, and with most intrusions now riding valid credentials it will, the thing that decides whether it stays small is how far the compromised workload can reach. You build containment into the fabric, or you don't have it. Built in, not bolted on. That's the destination, and it's the line Aviatrix has been on for years.
But here's the lesson the years actually taught us, and it's the part purists get wrong. Being right about the destination is not the same as helping a customer get there. The long-term vision is security embedded into the fabric of the architecture. The near-term reality is that improving an enterprise's security posture fast matters more than being architecturally pure about it. If getting better security means a multi-quarter network transformation project, most teams will simply stay exposed. So you have to meet customers where they are. That conviction is exactly why we built what we built:
Add deep security without touching your network. This spring we shipped Transparent Inspection for AWS Transit Gateway. It inserts full, stateful, deep network inspection into existing inter-VPC traffic while preserving native TGW routing, symmetrically, with no overlay and no SNAT. You don't redesign anything. There is no architectural transformation project required. You keep the network you have and get the security you need, in place, today. Then, when you're ready, you graduate that same estate onto the full Aviatrix multicloud fabric where enforcement is built in. That's the difference between optionally chaining a legacy firewall onto a connection and actually moving a customer's posture forward without making them rebuild first.
A managed service that doesn't take your data plane hostage. With Aviatrix PaaS, we run and operate the control and management plane, the upgrades, the availability, the toil. But the data plane stays private, in your cloud accounts, under your control. You get as-a-service simplicity without handing your traffic to a fabric someone else operates, and without the multitenancy questions that come with shared infrastructure.
Built for automation, not just a button. "One button in the console" demos well. But the enterprises running the world's largest cloud networks live in Terraform and pipelines. Everything we do is API-first and codified through a mature Terraform provider, because at real scale the network is infrastructure-as-code, not a click.
The Questions I'd Actually Ask
I'd want answers to a few things, and I say this as someone rooting for the category, not against Cisco:
Where's the convergence? Cisco has spent years telling the market that networking and security are converging, and they have a genuinely interesting distributed, workload-level security story in Hypershield. So the surprise isn't that Cisco can't do distributed enforcement. It's that Cisco Multicloud Fabric ships with firewall *service chaining* rather than that converged, in-network enforcement out of the box. Why isn't the security Cisco already believes in built into the fabric on day one?
How does this sit with the rest of the Cisco stack? There's a SASE story (Secure Access), a data-center security story (Hypershield), and now a multicloud fabric. Which one enforces policy for a cross-cloud AI agent, and do they share a policy model, or is integration left to the customer?
Will they commit? This is the one I'd press hardest, with affection. Cisco has been in cloud networking before. Cloud ACI / the Cloud Network Controller went end-of-sale and end-of-life in 2024. Multicloud is hard, and it takes sustained, multi-year investment through the unglamorous middle. The architecture you ship tells you what you can build today. Whether you stay is a different test.
The Bottom Line
So here's the question I'd put to anyone in a heavy-Cisco shop being told the network is now part of the intelligence stack: can it contain a compromised agent on a cloud where you run zero Cisco hardware, without steering the traffic through a fabric someone else operates? If the answer needs a vPoP, a service chain, or your installed base, then operationally it's close to the architecture you already had, with a new name on it.
But don't read that as a knock. Cisco validated the category last week, and that's good for everyone building in it, us included. Validating a category and delivering its hard parts are different milestones, and the hard parts took us years of real-world scale to get right, serving some of the largest companies in the world. Their products will mature. I want them to. The problem is big enough, and important enough, that the more serious people working on it, the better.
I'd know the difference between the two milestones. I helped build both sides of it. And I'm glad to have the company.
