From AGENTS.md to Enterprise Deployment: The Real-World Challenges of AI Agents

AI Agents are rapidly moving from developers' laptops and prototype validation stages into enterprise production environments. But enterprise-grade deployment means security, compliance, scalability, and reliability become hard requirements—precisely the dimensions most easily overlooked during the prototype phase. Nick Kuhn from VMware Tanzu Platform joined the Practical AI podcast to discuss with Daniel Whitenack and Chris Benson what changes and what stays the same once Agents enter the enterprise.

From Text Specs to Platform Engineering

Files like AGENTS.md represent a simple approach to Agent configuration: using natural language to describe an Agent's capability boundaries and behavioral norms. This works well enough for personal projects or small teams, but it falls far short in an enterprise environment.

Nick Kuhn's core point is that enterprises don't need to invent an entirely new infrastructure paradigm for Agents. The experience accumulated in platform engineering over the past decade—build packs, service mesh, identity management, sandbox isolation—can largely be reused directly. The difference is that Agents introduce new interaction patterns: they need to call tools, access external data sources, and collaborate with other Agents, all of which impose new requirements on traditional platform capabilities.

Platform Engineering is a major evolution in the DevOps space in recent years. The core idea is to abstract build, deployment, and operations capabilities into an Internal Developer Platform (IDP), allowing application teams to consume infrastructure through self-service interfaces rather than directly manipulating underlying resources. Typical outputs include Buildpacks, Service Mesh, and unified identity management. Service meshes like Istio take over inter-service communication through sidecar proxies, providing service discovery, mTLS encryption, traffic governance, and observability without requiring business code awareness; Buildpacks standardize and encapsulate the process from "source code to runnable image." For Agents, reusing these capabilities means they naturally gain rate limiting, circuit breaking, canary releases, and distributed tracing without reinventing the wheel for AI workloads. This is also the technical foundation for Nick Kuhn's emphasis on "incremental evolution" rather than "starting from scratch."

Agent Build Pack, MCP Gateway, and Shared Memory

The podcast discussed several specific enterprise-grade components:

Agent Build Pack: Similar to the build pack concept for traditional applications, it provides a standardized packaging and deployment method for Agents. This allows Agents to be managed and orchestrated by the platform like ordinary microservices, rather than existing as a special case outside the operations system.

MCP Gateway: Model Context Protocol is becoming the universal protocol for Agents to connect to external tools and data. But enterprises cannot allow every Agent to connect directly to various external services—they need a gateway layer to centrally manage authentication, rate limiting, auditing, and policy enforcement. This follows the same logic as API gateways.

Shared Memory: When multiple Agents collaborate, they need to share context, but the design of shared memory must account for isolation and consistency. Nick pointed out that this area is still evolving rapidly, with no silver bullet solution.

Model Context Protocol (MCP) was open-sourced by Anthropic in late 2024 to standardize how large model applications connect to external tools and data sources. It uses a client-server architecture: the Agent side acts as an MCP client, tools or data sources expose capabilities as MCP servers, and the two sides exchange structured data like "tool lists," "resource reads," and "prompt templates" via JSON-RPC. MCP solves the fragmentation problem of "every Agent writing its own tool integration code," enabling tool vendors to implement once and be called by any compatible Agent. However, in enterprises, directly connecting every Agent to all MCP servers leads to credential sprawl, unauditable calls, and inconsistent policies. This is why an MCP gateway is needed as an intermediary layer to centrally handle identity authentication, access policies, rate limiting, and call logging—positioned similarly to an API gateway for REST services.

Identity, Sandboxing, and Security Boundaries

When deploying Agents in the enterprise, identity management is one of the most challenging issues. In traditional applications, service identity and user identity are relatively clear. But an Agent may perform operations on behalf of a user, or may call tools after autonomous decision-making, which complicates the permission model.

Sandboxing is another key topic. Code executed or tools called by an Agent may introduce security risks and needs to run in an isolated environment. Nick emphasized that enterprises have very little margin for error here—an Agent's unauthorized operation could lead to data leakage or compliance violations.

These challenges are not unsolvable. Technologies already established in platform engineering—zero trust architecture, least privilege principles, runtime isolation—can cover most Agent scenarios after adaptation.

Zero Trust architecture's core principle is "never trust, always verify," meaning the internal network is no longer trusted by default and every access request must undergo authentication and authorization. In Agent scenarios, zero trust is especially important because Agents may initiate calls on behalf of users or trigger tool execution after autonomous decisions. The Least Privilege principle requires Agents to receive only the minimum permissions necessary to complete the current task, with their capability scope limited through short-lived tokens (such as OAuth 2.0 token exchange or SPIFFE identities). Runtime sandboxing uses technologies like gVisor, Kata Containers, and Firecracker microVMs to confine Agent-executed code to isolated environments, making it difficult to move laterally or steal host data even if exploited through prompt injection attacks. Together, these three form the technical foundation for enterprise Agent security boundaries.

Practical Advice for Enterprise Agent Adoption

For enterprises evaluating or already adopting Agents, Nick offered several practical recommendations.

Start with specific scenarios rather than pursuing a general-purpose Agent platform. First find one or two use cases with clear boundaries and manageable risk, validate the technology stack and operational processes, then expand gradually.

Manage Agents as applications. Don't give them special treatment just because they're "AI." Version control, CI/CD, monitoring and alerting, log auditing—these standard practices apply equally to Agents, if not more so.

Value the human-machine collaboration interface design. In enterprise scenarios, Agents rarely run fully autonomously; they usually require human approval or intervention at key decision points. The design quality of this collaboration interface directly affects whether Agents can truly be accepted by business teams.

Long-Term Impact on Software Development Teams

The podcast concluded by looking ahead at the long-term impact of Agents on enterprise R&D teams. One possible trend is that developers' roles shift from "writing code" to "defining Agent behavioral boundaries and orchestrating multi-Agent collaboration." Spec files like AGENTS.md may evolve into more formal interface definitions, becoming one of the core artifacts of team collaboration.

Platform teams need to think ahead: when Agents become a standard component of enterprise applications, what gaps remain in existing platform capabilities? Security policies, observability, cost control—demand in these dimensions will amplify as the number of Agents grows.

Nick's insights convey a clear signal: Agent enterprise adoption is not about starting from scratch, but about incremental evolution on top of existing platform engineering. Organizations with deep experience in microservices, containerization, and DevOps actually have an advantage in the Agent era.

One-line Summary

Enterprise AI Agent deployment doesn't require starting from scratch—platform engineering experience can be reused directly, with focus on identity, sandboxing, and MCP gateways.

Paragraph Summary

Nick Kuhn from VMware Tanzu Platform pointed out on the Practical AI podcast that AI Agents are moving from prototype stages into enterprise production environments, where security, compliance, scalability, and reliability become hard requirements. He argues that enterprises don't need to invent entirely new infrastructure for Agents—capabilities accumulated in platform engineering such as build packs, service mesh, identity management, and sandbox isolation can largely be reused directly. The difference is that Agents introduce new interaction patterns like tool calling, external data access, and multi-Agent collaboration. The podcast discussed enterprise-grade components including Agent Build Pack, MCP Gateway, and shared memory, with MCP Gateway handling authentication, rate limiting, auditing, and policy enforcement. Identity management and sandbox isolation are the most challenging security issues. Nick recommends starting with specific scenarios with clear boundaries, managing Agents as standard applications, valuing human-machine collaboration interface design, and notes that developer roles may shift toward defining Agent behavioral boundaries and orchestrating multi-Agent collaboration.