From VMware to Agentic AI: Building, Breaking, and Learning

25 years in infrastructure, an AI lab at home, and a new world where agents are becoming part of the technology stack.

I recently joined my longtime friends Nir Shiloni and Tal Doron on the CloudAI podcast for a conversation about agentic AI, my home lab, and how my approach to technology has changed over the years.

The conversation is in Hebrew, but since many of my readers don’t speak Hebrew, I wanted to share some of the stories and ideas we discussed.

We covered everything from my early VMware days to running local AI models, building an organization of agents, enterprise security, and even how AI is helping me build tools for my wife’s trading business.

And, of course, why my agents call me Captain.

Watch the full podcast on YouTube (Hebrew)

From virtualization to Layer 8

The conversation started with a trip down memory lane.

I started working with VMware around 2002–2003, back when virtualization was still relatively new. Over the years, my journey took me through virtualization, performance engineering, networking, security, Kubernetes, service mesh, and product management.

Today, I work with enterprise customers at Broadcom on private AI, Kubernetes, and increasingly, agentic AI.

Looking back, I’ve always been drawn to technologies that change how we interact with infrastructure. And I think agentic AI represents another major shift.

One analogy I shared during the podcast is that agents are becoming Layer 8 of the technology stack.

We all remember the seven layers of the OSI model. Engineers used to joke that Layer 8 was the user, usually when something went wrong.

But now there’s something new above the application: the agent.

Just as Kubernetes gave developers a way to consume infrastructure without managing every underlying component, agents let us interact with applications and infrastructure through intent.

Instead of telling a system exactly how to do something, we describe what we want accomplished.

That changes everything, including how we think about access, security, responsibility, and trust.

My home lab became an agentic company

A big part of the episode focused on my home lab.

It started with an NVIDIA DGX Spark because I wanted to understand what running AI locally really means. Sure, I could call Claude or ChatGPT through an API, but consuming a service isn’t the same as understanding how it works.

I wanted my own token factory.

What started as a DGX running local models grew into an environment with Hermes agents, Cursor workers, Llamagate for routing and observability, and specialized agents responsible for IT, security, marketing, and reporting.

But the biggest improvement didn’t come from a better model or faster hardware.

It came from organizing the agents.

Before I introduced Paperclip, much of my orchestration logic lived in Markdown files. The agents had instructions, but they weren’t particularly effective at coordinating work.

Paperclip introduced structured tasks, responsibilities, and a way for agents to collaborate.

My local model went from processing a few thousand tokens a day to millions.

The point isn’t the token count. It’s that the agents finally started doing meaningful work without me coordinating every step.

The lesson was simple: giving agents intelligence isn’t enough. You need to give them an operating model.

Building agents you can actually trust

Of course, getting agents to work is only half the challenge.

Getting them to work reliably is another story.

I shared a few examples of mistakes I’ve made, including one where I accidentally gave an agent conflicting instructions that prevented it from solving a problem — see the agent pretzel example. I spent two days trying to untangle something I had created myself.

This led me to rethink how I structure agent instructions, responsibilities, and context.

It also reinforced something I’ve been exploring in my writing about MCP and enterprise agent security.

Giving an agent access to a tool is not the same as authorizing it to use that capability.

An agent trying to complete a task might find another route to a system when its intended path is blocked. That’s why instructions and MCP definitions are not sufficient security boundaries.

Authentication, authorization, network controls, and enforceable policy still matter.

In fact, they matter even more when the software interacting with your infrastructure can make decisions independently.

AI is an exoskeleton

One of my favorite parts of the discussion was about the tools I’m building for my wife’s day-trading business.

The objective isn’t to replace her judgment with an AI agent. She has years of experience and a trading methodology that works for her.

My goal is to build tools that help her apply that expertise more effectively.

I like to think of AI as an exoskeleton.

An exoskeleton doesn’t replace the person wearing it. It amplifies what that person can do.

I think this is an important distinction that sometimes gets lost in the excitement around autonomous agents.

Not everything needs to be fully autonomous.

Sometimes the most valuable AI application is one that makes an experienced person significantly more effective.

Learning by building, and breaking

Nir and Tal also asked how my learning process has changed.

A few years ago, I’d start with documentation, tutorials, and architecture diagrams before installing something.

Today, I often do the opposite.

I ask an agent to build a first version. Then I examine what it did, challenge the decisions, break things, and learn from the results.

The cost of experimentation has dropped dramatically.

That doesn’t mean I don’t need to understand the technology. Quite the opposite. It means I can get to the interesting engineering questions much faster.

My advice to anyone starting with agentic AI is to find a problem you genuinely care about and build something around it.

It doesn’t have to be enterprise-grade. It could be a home automation project, something for your business, or even an agent watching your backyard cameras for a fox.

What matters is that you have a real problem to solve.

Why my agents call me Captain

We ended up talking about something a little more personal: how I work with agents and how I write this blog.

Most of my writing starts with voice dictation and development logs that my agents continuously maintain. AI helps me organize the material, but the experiences and arguments are mine.

And yes, my agents call me Captain.

I got tired of the excessive AI politeness, unnecessary compliments, and long explanations when a simple acknowledgment would do.

So I gave the agents an identity inspired by Star Trek. I’m the Captain, and they have their own responsibilities.

It’s fun, but it’s also practical. Clear roles and communication conventions make the interaction more efficient.

And frankly, “Aye, Captain” is a lot better than another paragraph telling me how brilliant my latest idea was.

The most interesting chapter yet

After more than 25 years in infrastructure, I feel like I’m back in the early days of VMware, discovering a technology that will fundamentally change how we work.

There’s still a tremendous amount to figure out, particularly around agent architecture, orchestration, security, and trust.

That’s what makes it interesting.

I’m building, experimenting, making mistakes, and documenting what I learn along the way.

A big thank you to Nir Shiloni and Tal Doron for inviting me. It was especially enjoyable to have this conversation with two people I’ve known for so many years.

If you speak Hebrew, I encourage you to watch the full episode. We went into considerably more detail, including live demonstrations of my agentic environment.

Watch the full CloudAI podcast episode on YouTube

And if you don’t speak Hebrew, I hope this gives you a sense of what we discussed and why I’m so excited about where this technology is heading.