September brought three infrastructure releases that address the same problem from different angles: how to run AI workloads across distributed locations without tripping over your own network, your own model duplication, or your own deployment pipeline.
Equinix launched Fabric One, Broadcom made VMware Cloud Foundation 9.1.1 available with shared AI models, and Akamai published a walkthrough for building serverless AI agents with Spin. Each treats a different bottleneck, and together they show where enterprise infrastructure is spending its attention right now.
Equinix Fabric One and the network as a control plane
Equinix Fabric One, announced on September 2, tries to turn enterprise networking into a policy expression layer. Instead of configuring overlapping tunnels between each data center, cloud region, and AI cluster, customers state what they want, such as "connect my European headquarters to this AWS workload with encrypted low-latency paths," and the platform translates that intent into routing and circuit configurations.
The technical details matter. Fabric One operates at Layer 2 and Layer 3 at the same time, which allows organizations to pick the abstraction level per connection rather than being locked into one. Every virtual circuit goes through zero-trust validation continuously, and traffic is encrypted by default. Equinix claims sub-millisecond latency increments between parties in the same metro area, with predictable performance across continents.
Equinix built this on its footprint of more than 250 data centers and interconnection points. Microsoft's cloud won't be a walled garden neighbor here. AWS and Google Cloud collaborated on open interconnect specifications that Fabric One supports, so traffic can move between on-premises systems and hyperscale clouds without proprietary overlay formats.
The distinction from SD-WAN is what I find instructive. SD-WAN appliances solve the last-mile problem for remote offices. Fabric One addresses the high-bandwidth, low-latency paths between enterprise cores, cloud regions, and AI compute clusters. Those are different problems with different physical constraints. An SD-WAN box at a branch office isn't going to carry petabyte-scale model training data between a colocation facility and a cloud region. Fabric One is not trying to replace the branch router. Treating them as complementary is correct, and Equinix says as much in its own materials.
For distributed AI applications, the network is the performance ceiling. Training large language models can require access to petabytes of data across multiple storage systems, and inference services need consistent response times even when models are updated dynamically. Equinix Fabric One allows dynamic bandwidth allocation and automatic path rerouting based on real-time telemetry. If a link congests, the system redirects flows while preserving the original intent parameters.
I am somewhat skeptical about intent-based networking claims, because the phrase gets used loosely. But Fabric One has one detail that suggests it is not vapor: it reduces setup time from days (provisioning cross connects and VLANs) to minutes once an intent is expressed through the management portal. That kind of operational change matters more than the marketing language.
VMware Cloud Foundation 9.1.1: shared models with isolated tenants
Broadcom released VMware Cloud Foundation 9.1.1 on September 3. The headline capability is Multi-Tenant Model Sharing, which lets different lines of business or teams access shared AI models from the same private AI infrastructure without giving them visibility into one another's data.
The design uses a shared service layer for model serving while keeping each tenant's data isolated in its own namespace. This matters for compliance-heavy industries, where data sovereignty and auditability are non-negotiable. Instead of spinning up separate model runtimes and GPU pools for each business silo, an enterprise offers one set of models to many teams. Broadcom claims this reduces redundant model copies and idle GPU allocation, though it has not published independent metrics to prove the cost savings.
The release also adds an AI Assistant for VCF Operations. Administrators interact with operational data in natural language, and the assistant can connect either to models running through Private AI Services or to a private Google Gemini instance. This avoids sending operational telemetry to an external SaaS service, which is a genuine requirement for many regulated enterprises.
What worries me about VCF 9.1.1 is the gap between what is generally available and what is still pending. The GitOps Service and native S3-compatible vSAN Object Storage remain Tech Preview features. The AI Gateway, Secure Agent Framework, and Model Autoscaling are listed as future capabilities.
That split creates a real planning problem. You can share models today, but you cannot yet manage prompt routing centrally, sandbox agents with fine-grained control, or autoscale model replicas to control GPU cost. If your enterprise roadmap depends on any of those controls, you need to treat them as dependencies on future releases, not components of this one.
Broadcom's documentation around multi-tenant model sharing is inconsistent, which is another reason to validate the actual software versions and licensing terms before committing. The GA announcement does not guarantee that every feature works with every supported version of Private AI Services. I would recommend testing in a non-production environment first.
Serverless agents from Spin and Akamai Functions
Akamai published a tutorial on building serverless AI agents using Spin, the WebAssembly toolchain. The sample is a gaming agent that rolls multi-sided dice and flips coins through a small HTTP endpoint. The interesting part is how little infrastructure is involved.
You define a Spin application manifest that sets variables for the LLM base URL, API key, and model name. The agent code uses Hono as the HTTP router and the AI SDK's ToolLoopAgent to handle the agentic loop. Two tools are defined, each with a description and a Zod schema that the model uses to decide when to invoke them. The agent generates a response and the server returns JSON. Running it locally takes one command with the configuration variables passed on the CLI, and then you can deploy the compiled WebAssembly module to Akamai Functions.
The tutorial includes this snippet:
const gamingAgent = new ToolLoopAgent({
model: ollama.chat(config.modelName),
instructions: "You're a gaming assistant. You can play only games that are defined as tools.",
tools: { roll_a_dice: rollDiceTool, flip_a_coin: flipCoinTool },
stopWhen: stepCountIs(4),
});
I like this approach because it compiles to WebAssembly, which means the cold start behavior is far more predictable than a container in a serverless function. The trade-off is that the sample relies on Ollama as the model provider, which is fine for local development but not necessarily what you want for a production-grade multi-tenant service. The same architecture would work with a hosted model endpoint, though, since the provider layer is pluggable through the AI SDK.
The downside of the tutorial is that it demonstrates a single-agent pattern with no persistence, no observability beyond console logging, and no authentication on the endpoint. For a blog post that is acceptable, but teams adopting this pattern will need to add those pieces themselves.
What to make of all three
These releases are independent but complementary. Equinix Fabric One addresses the network fabric that connects distributed compute and storage. VMware Cloud Foundation 9.1.1 attacks the problem of model sharing and governance inside a private cloud. Spin on Akamai shows a lightweight path for running agentic workloads at the edge.
For enterprises evaluating their infrastructure, I would ask three practical questions. First, do you need Equinix Fabric One, or would existing SD-WAN plus direct colocation meet your requirements? The answer depends on whether your AI workloads actually move large volumes of data across metro and continental distances. Second, can you live with VMware's current release boundaries, where model sharing is available but governance is not? If you need autoscaling or centralized prompt control today, VCF 9.1.1 will not fully solve your problem. Third, is WebAssembly-based serverless mature enough for your AI agents? The Spin model is elegant, but it depends on your willingness to adopt a relatively new deployment surface.
One concern cuts across all three: performance claims vary in verification quality. Equinix provides latency numbers but no published third-party benchmarks. Broadcom offers no independent cost analysis. Akamai does not discuss load or concurrency limits for agent traffic on its platform. Treat these claims as directional, and measure against your own workloads before you commit to a multi-year architecture.