The Infrastructure Problem Nobody Is Talking About in Agentic AI

This article was contributed by Luke Tucker of Outshift by Cisco, a MACH Alliance member and founding contributor to the Agent Ecosystem initiative.

Production deployments are proving that composable architecture is the prerequisite for agentic AI. But there's a deeper infrastructure question most teams hit the moment they scale past a single agent.

The MACH Alliance's 2026 Enterprise Technology Report made the case plainly: organizations with fully composable architecture are six times more likely to achieve ROI on AI investments. The first wave of production agentic deployments – from AmerCareRoyal to General Motors – confirmed it. Composable, API-first infrastructure isn't a nice-to-have. It's the table stakes.

But there's a second-order problem that shows up the moment you move from a single agent to a system of agents operating across distributed infrastructure. It's not about whether your architecture is composable. It's about how your agents reach the things they need to act on – and what that costs you in security, operational complexity, and brittleness.

Most teams solve it the wrong way. And they don't realize it until they're already in production.

The Default Pattern – and Why It Breaks

The instinct when connecting an agent to a remote resource is to reach for familiar tools: expose an API, open a port, distribute credentials, set up a VPN. The agent lives in your cloud, so you bring the remote resource to it.

For Kubernetes this means distributing a kubeconfig and making the API server reachable from wherever the agent runs. For a remote database it means a connection string, firewall rules, and a VPN tunnel. For a legacy system it means an SSH key, an Ansible control machine, and an inventory that needs constant maintenance.

Each connection solves the immediate problem. Each one also widens the attack surface, adds credentials to manage, and creates a hard dependency on a specific network topology. The agent becomes fragile: rotate a key, change the firewall, move the cluster – and something breaks. At scale, across dozens of environments, this compounds fast.

This is the infrastructure debt that doesn't show up in your architecture review until you're operating 20 agents across five platforms. It's what CarParts.com learned through real production experience – you need a shared state layer and coherent coordination, or your agents operate in isolation regardless of how composable your underlying stack is.

A Different Mental Model

The shift is straightforward: instead of opening your infrastructure to the agent, deploy a small agent inside the infrastructure and let your orchestrator talk to it.

The remote agent lives next to the resource. It has whatever local access it needs – a kubeconfig that never leaves the cluster, a shell on the VM, a database connection that stays inside the network. Your orchestrator never needs any of that. It sends an intent to the remote agent over a standard agent-to-agent protocol and receives a result. 

The remote environment only needs one outbound connection to a message broker. No inbound ports. No VPN. No credentials distributed outside the environment.

This isn't a new architectural concept – it's the same principle that makes MACH composability work. You don't drag your data model out to wherever the AI model is. You make the AI accessible to the data where it lives. The same logic applies to agents and the infrastructure they need to act on.

Why This Matters for MACH Organizations Specifically

If you're already operating a composable stack, you're ahead. Your API-first foundations mean agents can plug into existing interfaces without re-platforming. Wyze proved this: adding AI agents as a net-new buyer channel required zero changes to existing fulfillment infrastructure because the orchestration layer was already composable.

But composable architecture at the application layer doesn't automatically solve agent coordination at the infrastructure layer. These are different problems.

The application-layer question is: can my agents access the right systems through clean APIs? The infrastructure-layer question is: can my agents reach the environments where those systems run – securely, without creating a web of credentials and open ports – and coordinate across those environments with a consistent addressing model?

General Motors' AssetIQ deployment is instructive here. Six agent types – Librarian, Planning, Production, Compliance, Critic, Orchestration – working as a system. When a Librarian agent generates metadata, Compliance agents validate it immediately. That coordination requires more than clean APIs. It requires agents that can address each other reliably, pass context without losing it, and operate within enforced permission boundaries. The architecture that makes that possible is what determines whether multi-agent systems produce compound outcomes or just compound failure modes.

The Properties That Actually Matter

When you adopt an agent-native approach to infrastructure access – deploying agents where the resources live rather than pulling resources out to where the agent is – three things change:

What This Means for Teams Building Now

The organizations achieving real outcomes from agentic AI share consistent patterns: they start narrow, measure before expanding, build governance from the start, and treat composable infrastructure as the foundation – not the finish line.

The infrastructure pattern described here is the next layer of that foundation. It's what makes multi-agent systems operationally coherent at scale, not just architecturally sound on a whiteboard.

Three questions are worth pressure-testing before your next agent deployment:

1. How are your agents reaching the systems they need to act on? If the answer involves distributing credentials or opening inbound ports, you're accumulating operational debt that compounds as agent count grows.
2. What does your coordination model look like across agents? Isolated agents that can't share state or address each other reliably don't produce compound outcomes. They produce compound coordination overhead.
3. Where does authorization actually live? A raw API enforces authorization at the API layer. An agent introduces two separate questions: is the caller allowed to make this request, and is the action the agent derives from it something that the caller should be able to trigger? Both need explicit answers before you're in production.

The first wave of agentic AI proved that composable architecture is the prerequisite for AI ROI. The second wave will sort out which organizations built the coordination layer that makes multi-agent systems work – and which ones are still untangling a web of credentials, open ports, and isolated agents that can't think together without digital barbed wire and duct tape holding things together.