From AGENTS.md to Enterprise Deployment

Enterprise deployment means accommodating regulated and sometimes air-gapped environments: some customers physically carry materials into data centers, while requirements may include PCI, SOX, HIPAA, and FIPS. Nick described Tanzu Platform as supporting private-cloud deployments on data-center bare metal or in a hyperscaler’s private VPC. Its purpose is to provide a repeatable, compliant route to production so developers can focus on business logic, while the platform handles container builds, certificates, ingress, load balancing, health monitoring, isolation, scaling, and service bindings. A certified, shared platform can reduce repeated recertification and team-specific deployment “snowflakes,” making applications easier to audit and secure.

The proposed agent workflow extends the familiar “cf push” model: describe an agent in a human-readable AGENTS.md file, push it to the platform, and have the platform start and scale it, with startup said to take about a minute. Nick argued that established application-platform principles may apply to agents, but the discussion did not resolve whether agents and applications should be treated identically. A build pack supplies boilerplate for an agent’s role and behavior, while a memory service can provide team-specific context such as architecture, prior work, and roadmap. Because traditional 12-factor platforms separate application state from storage, agents that rely on local Markdown files for memory need persistent storage when deployed into ephemeral cloud environments.

Enterprises increasingly want agents available on demand and running continuously, rather than stopping when a laptop shuts down. Agents can use local models on customer GPUs or connect to an approved cloud LLM, although some customers are air-gapped and others lack GPUs. Nick said agents are already being used in CI/CD pipelines and alongside applications; locating agents and LLMs near applications and data can reduce latency and networking problems at scale. He cautioned that SaaS providers may not meet traditional enterprise reliability expectations. Agents can also bind to shared memory, an MCP gateway, an approved LLM, and a runtime.

The MCP gateway registers servers and governs which servers and tools agents can access; it can also expose approved tools to local agents such as Cursor or Claude Code. Access can use individual user identities and credentials rather than a generic organization-wide service account. Nick estimated that his organization runs around 30 or 40 MCP servers. In a demo, a repository webhook triggered an agent to fetch code, conduct a security review, and post results to a GitHub issue; Nick saw potential for running similar reviews on each commit. Container isolation can prevent agents from communicating with one another, accessing the internet, escalating privileges, or reaching the host unless permitted. The gateway also makes agent-to-MCP calls and events visible, enabling alerts for anomalous activity, such as 200,000 calls to delete a repository.

Nick recommended introducing agents gradually, beginning with a simple agent and adding approved MCP tools over time. Getting access to an approved LLM can be an initial hurdle, with AI councils or committees reviewing proposed use. Guardrails can make approved tools available without depending on arbitrary internet downloads. The agent build pack is intended to help organizations approve deployments, and existing platform customers can deploy an agent like another application. The speakers stressed that adoption also depends on collaboration: new technology teams should draw on experienced colleagues instead of attempting enterprise-wide goals alone, while established teams should remain open-minded and share their knowledge. Outreach, weekly office hours, and lunch-and-learns can help teams learn from one another.

Discussing the Hugging Face incident, a speaker said monitoring, agent controls, hardened sandboxes, and locked-down network zones could have limited some exposure, while monitoring failures and an internet-connected artifact repository were cited as weaknesses. Organizations also need to prevent agents from acquiring unauthorized tools and keep dependencies, containers, operating systems, and platforms patched and reliable. The speaker cautioned that the incident does not prove their organization or AI labs are better protected, and that controls cannot prevent every failure; the host said security, legal, and communications teams are considering how they would respond to a similar incident. The guest predicted significant changes to enterprise roles, including development and product management, and said agent capabilities could change substantially over the next six months. Claims on social media that AI could take out humanity “over the weekend” or “by Friday,” with a greater-than-10% chance, were not presented as an established event or finding.