Run Your AI Agent in a Container, Not in Chaos

I have, on multiple occasions, tried to share an agent setup with someone by sending them a folder of YAML and vibes. It never works. The API keys are wrong, the MCP server paths don't match, something references a directory that only exists on my machine. By the time they get it running, I've lost the thread of whatever I was trying to show them. It's a whole thing.

So when Sally Ann O'Malley from Red Hat got up at AI Engineer and said "the answer is a container image"—yeah, I was listening.

O'Malley, who spent the first seven years of her Red Hat tenure deep in containers, Linux security, and Kubernetes before pivoting full-time into AI, gave a talk that is ostensibly about deployment patterns but is actually about a more interesting problem: how do you make a personal AI agent setup portable without it becoming a nightmare?

A note on the framework: The talk centers on a tool O'Malley calls "OpenClaw." Based on the description—an open-source, MIT-licensed AI agent framework with sub-agents, MCP server support, secret refs, and an SSH sandbox feature—this appears to be a reference to OpenHands (formerly OpenDevin). The talk's title also uses "OpenClaw" as a stand-in. We haven't been able to independently verify this mapping before publication, so treat "OpenClaw" as the name used in the talk and do your own digging if you want to confirm the underlying project.

The problem she's actually solving

Here's the scenario O'Malley is building for: you have a nicely configured AI agent. It has sub-agents, some tools, MCP servers (think: integrations that give the agent access to external data or actions), maybe a custom skill or two. You want your teammate to have the same thing. What do you do?

Currently, the answer is "send them a repo and hope for the best." O'Malley's answer is: build a container image. Same image runs locally via Podman, same image goes to Kubernetes. No config drift, no dependency hell, no "works on my machine."

She runs everything with Podman (not Docker, though she's designed her installer to work with Docker too). Podman has a feature called Podman secrets—you store your API keys there, and they live as contained, encrypted values on your host rather than being exported as plain environment variables. When you run the container, you mount those secrets in. Then, inside the container, the framework's own secret ref feature creates another layer of indirection, so your actual key values aren't floating around in logs.

"That's not perfect, but it gives me some peace of mind that I don't I'm not going to be showing my API keys in the logs and everything," O'Malley said. That's a refreshingly honest framing—not "this is bulletproof security," but "this is meaningfully better than the alternative."

The same pattern extends to Kubernetes: Kubernetes secrets instead of Podman secrets, PVCs (persistent volume claims—basically managed storage) instead of local Podman volumes. Same container image throughout. The local-to-production promotion path becomes: podman run → flip a flag → kubectl apply.

The two-second demo

Okay, I need to tell you what happened during the live demo, because it's the thing that made me actually lean forward.

O'Malley pulled up her custom installer—a little GUI she built for herself, publicly available on GitHub—typed in a name, configured some options, and spun up a new agent instance. The whole thing took maybe two seconds. She even acknowledged she was talking through it the whole time and it still could have been one second.

I've watched a lot of AI demos. I've sat through many, many setups that involved five terminal windows, three pip install commands, and a moment where someone sheepishly says "let me just restart this real quick." The two-second spin-up shouldn't be as shocking as it is, but it kind of is? Like, the friction of getting these tools running is genuinely one of the biggest barriers to people actually using them. Watching it collapse to nothing in a live conference demo is the kind of thing that makes you want to immediately go try it yourself.

She also pre-spun up a couple of instances as backup—"you never know what the demo gods are up to"—which honestly is just good conference hygiene and I respect it.

The Nvidia thing (and what we can actually say about it)

The most-shared claim from this talk will probably be the Nvidia anecdote, and it deserves some careful handling.

O'Malley said she ran into a contact at PyTorchCon who told her his team runs this container-based agent pattern in production for model evaluations—ten engineers, each running their own instance in Kubernetes. The punchline: "He said it was like, you know, doing the job of six engineers uh in with with himself."

I want to be honest about what that claim is and isn't. It's one person's account, relayed secondhand at a conference, with no verification path. We can't check the methodology, we don't know what "six engineers' worth of work" means concretely, and the person who said it presumably has some enthusiasm for the tool they're using. The claim is interesting as a data point about how teams are actually deploying these patterns. It's not a controlled study.

What it does tell you, even hedged appropriately: teams are running this kind of setup in real production contexts for real technical work (model evals), not just hobby projects. That's the part worth noting.

The bigger question the anecdote raises is one I keep bumping into talking to people my age who are either trying to break into tech or are a few years in: where does the productivity gain go? O'Malley's framing is optimistic—"we get to do fun stuff, interesting stuff, creative things"—and I don't think she's wrong that that's what it looks like from where she's sitting. She's a senior engineer with years of domain expertise. The AI is handling the tedious implementation work; she's steering.

But a lot of people I know are trying to get to "steering." They're building the skills that were, until recently, the path in. When O'Malley tells a Red Hat all-hands "AI is 1,000 times better than me at writing code"—and watches the senior engineers raise their eyebrows—that's a real tension. Not a disaster, maybe. But not nothing, either. I genuinely don't know how it resolves at scale, and neither does anyone who's honest about it.

The vision that's actually interesting

The part of this talk I keep thinking about isn't the demo—it's the workplace setup O'Malley sketched out near the end.

Imagine: a company maintains a baseline container image. It has approved MCP servers, company authentication, team-specific skills, whatever integrations your org has standardized on. New hire joins. They pull the image. Day one, they have a fully configured, security-reviewed agent environment that reflects how the team actually works—not a pile of markdown they got from their desk neighbor.

"Team standards, portable environments, reproducible onboarding," O'Malley said. "That's my vision for Open Claw in the workplace in the future."

The thing is, this is just... containerization applied to agents. The pattern is thirty years old. What's new is the thing being containerized. And maybe that's the point—the reason agent deployments are chaotic right now isn't that the problem is new, it's that people are treating agents as a special case when they're just another application that wants the same infrastructure discipline everything else already has.

O'Malley's "forever claw" has sub-agents named Joy (Jyotish astrology readings) and Bruno (daily Boston Bruins updates—she mentioned they're heading into the playoffs). It's backed up every night via a systemd-equivalent service on Mac. It is, in her words, "my forever claw, and I love her."

There's something kind of quietly instructive about that. The person who built the most security-rigorous containerization setup in the room also has an agent whose whole job is telling her Mercury is in retrograde. The infrastructure pattern is serious. What you do with it is yours.

The real question isn't whether containers are the right way to deploy agents—they pretty clearly are, for all the usual reasons. It's whether the tooling and culture catches up fast enough that "containerize your agent setup" becomes the default rather than something you have to give a conference talk to convince people of.

Given the commit velocity O'Malley described—sometimes 10,000 commits between her pulls from main—that might happen faster than any of us expect.

Yuki Okonkwo is Buzzrag's AI & Machine Learning correspondent. She covers the people and systems building tomorrow's algorithms.