Running AI agents in the enterprise starts with whether they drop offline at midnight
An enterprise agent is not a new species — it is another app that has to clear compliance, be auditable, and be uniformly hosted by a platform; the real difficulty is state, identity and network location.
The video won't play here. Listen to the audio instead:
The argument · tap a timestamp to hear it
The first wall in the enterprise is having no internet
Nick spent five years at VMware and fourteen years before that at a large enterprise. He says vendors always assume internet connectivity when they demo, whereas real enterprises often have "limited or no internet access" — some customers are genuinely air-gapped, and things have to be carried into the data center by hand. Beyond being offline, you also face layer upon layer of compliance: PCI, SOX, HIPAA, FIPS. So the enterprise environment is not a home environment scaled up; it is a highly controlled environment where "getting one thing wrong has serious consequences," which is also where many newcomers get most frustrated.
— NickThe platform's value is making the path to production the least effort
Nick explains that the Tanzu platform is based on Cloud Foundry, an open source project older than Kubernetes and Docker, which came out of VMware around 2011. Its core idea: developers just push their code, and the platform builds containers to best practices, handles certificates, load balancing, health monitoring, and even sandboxes applications from each other; if you need a database or an LLM, you bind a service. Once an enterprise has certified this platform, it does not have to re-certify for every sub-team, avoiding a hundred snowflake deployments. What enterprises want is one auditable, reproducible path, so developers write business logic instead of wrestling with infrastructure.
— NickThe agent's biggest trap is that it writes state onto itself
Traditional 12-factor applications cleanly decouple storage and state and can scale to a thousand instances. But early agent harnesses were "I have filesystem access, so I'll write a bunch of MD files as memory" — on the cloud, instances come and go and are ephemeral, so those MD files drift away. Nick considers this the biggest challenge when moving app deployment methodology onto agents. Enterprises also want agents to start on demand, to be embeddable in CI/CD or an e-commerce suite, and to be close enough to the application and data: if the LLM is thirty hops away from the microservice, physical latency becomes a problem at scale, and SaaS vendor reliability does not meet what traditional enterprises require.
— NickTreat the agent as just another app to push
Nick explains what a buildpack is: back when he demoed, he pushed a compiled Java JAR, the platform recognized it as a Java application, and used the Java buildpack to generate a container to best practices, handling JVM memory calculation, the JDK, certificates. Now the same motion becomes pushing an agent, with the only difference being that the input goes from machine-readable code to a human-readable Agents.md — you tell it what to do, it comes up within a minute, and you scale it as much as you want. The platform can also run local models (some customers bought GPUs a few years ago, some regret not buying) or register approved cloud LLMs. The only approved way for developers to use it inside Broadcom is to deploy the MCP server on the Tanzu platform.
— NickThe MCP gateway is a gate bolted onto tool calls
This is the first time the show explains the MCP gateway clearly: an organization may be running thirty or forty MCP servers, which register and bind to specific gateways, and the gateway controls who can access which servers and which tools. It can also inject the gateway into local agents like Cursor and Claude Code, so local agents only use organization-approved tools. Identity must be passed through too — with the GitHub MCP server you carry the end user's credentials all the way through, rather than sharing one service account across the whole organization. Because all traffic goes through the gateway, you get metrics: if some agent fires twenty thousand tool calls at "delete repository," that should trigger an alert.
— NickAgents.md is static; the memory service is live
Nick draws a sharp line between the two: Agents.md is boilerplate, statically telling the agent what to do and how to behave, e.g. "you are a senior software engineer, watch this Jira queue, check incoming tickets for quality, and talk like a pirate." The memory service, by contrast, is mountable and partitioned by team — Team A's agent accesses Team A's memory, which holds this application's architecture, what has been done, the roadmap. That way, every time the agent comes up or goes down it immediately knows what happened before and can make the right security review judgment. Static intent and dynamic history are split into two things, and this is the part most easily conflated when moving a local agent onto a platform.
— NickDon't try to boil the ocean — get one agent running first
Faced with new protocols like A2A constantly popping up, Nick's advice is "take baby steps": enterprises are slow anyway, so there is no need to do it all at once. For most places, the biggest hurdle is still getting secure, approved access to an LLM, then getting through the AI committee — he jokes, "we go propose to the committee and wait six months for the result." Once something is approved, iterate: run a simple agent first, add an MCP server to give it tools when you want it to be better, then send the tools for review. He also warns organizations not to always have the new team do new things while the old team is left on the sidelines; the new team should proactively hold office hours and lunch and learns, and the old team should reach out too, otherwise you get friction and silos.
— NickWhat the Hugging Face runaway lacked was basic security
Discussing the Hugging Face agent swarm incident, Nick first states this is just advice and not a claim that they are better than the AI labs. He points out the problem was that the agent got out of its sandbox, found something it could access, and monitoring was not working. He asks: traditional firewalls, network segmentation, hardened sandboxes, locked-down network controls could probably have blocked a large part of it; the Artifactory piece had internet access and got repeatedly wiped. His conclusion is not "AI will destroy humanity" but "do some basic security." He also mentions that weekend's AI Twitter discussion about "AI has a greater than 10% chance of destroying humanity," and says that is a separate matter from this incident.
— NickIn their own words · checked verbatim
when we had vendors come in, it would always be like they would always assume that we could just go to the Internet. And it was always like, well, try again because that's not gonna work here.
Nick2:30
The traditional harnesses or agents were kinda built originally just to be like, oh, I've got file system access, and I can just write a bunch of MD files, and that's like my memory. Everything's great. And they're like, well, you start to get into a cloud cloud world that things spin up and down and are ephemeral, you're gonna wanna save those MD files somewhere.
Nick11:00
instead of, like, you know, machine readable code, we have a human readable language, the AgentsMD. So, basically, you tell what the agent it's gonna do, and then you just push it to the platform.
Nick22:30
this one agent, you know, made 200,000 tool calls to, you know, delete repo. Like, oh, like, maybe we should alert on that.
Nick29:30
we shall go to the committee and we shall present our idea. We will wait six months and see what has the result been.
Nick36:30
It's like, well, guys, you could've just, you know, I don't know, had some basic controls.
Nick43:00
I am, like, working harder than I ever have because I have all these agents, and they, like, they need stuff from me.
Nick45:30
Figures
| Years Nick worked at a large enterprise | 14 years | 2:30 |
| Years Nick worked at VMware | about 5 years | 2:30 |
| When Cloud Foundry originated | around 2011 | 5:30 |
| Broadcom's internally approved way to deploy MCP servers | only on the Tanzu platform | 22:30 |
| Number of MCP servers running in an organization | about 30 to 40 | 27:30 |
| The figure in the discussion of AI destroying humanity | greater than 10% | 43:00 |
Glossary
- Agents.md
- A file written in human-readable natural language that tells the agent what to do and how to behave.
- buildpack
- A set of commands that automatically builds source code into a best-practice container for a given use case.
- MCP gateway
- A middle layer that uniformly registers, controls and monitors access to multiple MCP servers.
- air gap
- A network completely physically isolated from the outside, where data can only move in and out by hand.
- 12 factor application
- A set of cloud-native application design principles emphasizing clean decoupling of state and storage.
How to listen
Platform engineers, architects and security leads pushing AI agents onto enterprise intranets, especially those stuck on compliance and disconnected environments.
The host's opening small talk and the Midwest AI Summit promotion can be skipped.