Docker AI, what’s new with MCP, Agents, Sandboxes, and more

Welcome to DevOps and Docker Talk, and I am your host, Bret Fisher. In this episode, I've got Michael Irwin from Docker back on the podcast to talk about everything that Docker has been releasing and updating for about the last eight months. Now this show is called DevOps and Docker Talk. We should be talking more about Docker, but I unfortunately, probably like a lot of us have been heads down learning AI tooling for the last four or five, six months.

As the models have gotten better, the harnesses have gotten better, we've gotten fancier with our agents and Subagents, and TUI and GUIs and WUIs. That's my new name for Web UI. TUI, GUI, WUI. I've been playing with OpenCode and I've been very busy on that all year, and everyone else is focused on Claude Code, which is also awesome.

But I haven't been talking a lot about Docker, and I haven't quite frankly been playing a lot with Docker. And that is not because Docker isn't shipping. Docker has been on a steady release cycle of shipping not just updates to their existing tools and adding AI functionality and improvements for those tools, working with AI, but also entirely new product lines and product tools. Just products like lots of products, and we go through that.

That's why this episode's going to be a little long one, but hopefully this will catch you up on everything you've missed since almost this time last year. About this time last year, I had a couple of podcast episodes around Docker's Docker Model Runner, DMR, and some other updates. They were releasing Gordon AI and some stuff. But since then, a lot of those tools have received improvements and they've got all sorts of new things out.

So on this episode, we cover the updates to Gordon, which is the AI built in the Docker Desktop, and it's gotten quite better, and I think it's probably the thing I should be using anytime I'm playing around with containers and I need to either troubleshoot them or I need to improve the Dockerfile. I think this AI, because it's backed by so much of the current and up-to-date data and it can see into your running containers and see what's going on while you're in the middle of Docker Desktop, I think that's the best way to go for asking what's going on in my container right now.

Like, that's better than maybe using Claude locally, which can't maybe see as much as what Docker Desktop can see. So that's pretty cool. Docker hardened images came out almost a year ago, which is one of the new product category in the last five years of not just minimal images, but actually hardened images that are going after locking down things, making new OSes or slimming, even existing OSes down into something that's not just minimal, but also designed with CVE count in mind.

And I have been shouting for the rooftops for probably a decade now about CVEs and images and the techniques and the tactics for how we shrink those things down. And I feel now that we have a hardened image ecosystem basically started by Chainguard. Lots of players in there now, and Docker and Chainguard are the two that I'm paying attention to. So Docker has announced now that a significant portion of that catalog is free, and we talk through the details of what's free, what's not free, how to customize these things, what you get on the paid plan.

And I think every team should be considering hardened images in some fashion for their workloads in production. Next. Docker sandboxes. Arguably a new category for Docker because It's not just images in sandboxes that help you run AI securely.

it's now VMs per project with a container in them running your agents and your harnesses for more security. So Docker is taking it to the next level by creating VMs or micro VMs locally for your sandboxes, and they provide a command line tool that essentially allows you to spin up a VM with a container in it in the current directory you're in to run your Claude Code, to run your OpenCode and your other agent harnesses, and they bundle those all into customizable VMs with containers.

And you can run those locally, you can, I think eventually they're going to probably figure out a way to run that remotely maybe. But today it's really just about local and it's called Docker Sandboxes. So I am definitely interested in that because as, especially as a DevOps and operations person, I tend to have a lot of credentials on my machine as much as I try to work least privilege, I've got a lot of keys. I've got a lot of CLI tools that are logged into systems that I don't want my agent to have.

And when I'm working in Claude Code, as good as the latest state-of-the-art models are, they don't hallucinate that much lately, and they pretty much stay on task all the time. But it still means if I'm running them locally that they have access to command line tools that I don't want them to just run accidentally With a prompt injection or something else that might happen, right? So I really want to figure out a way to get these things locked down, to run them isolation, to give them temporary keys or their own keys or their own pats or whatever.

And I think sandboxing is going to be in a lot of our futures. Once we get past this crazy town time of just rapidly iterating on agents and what harnesses look like with a bunch of agents running inside them and agent orchestration, I think we're going to start caring about security again. And we all are going to need some sandbox tooling to do that. And why?

Why adopt a whole new tool when you can always use the tools that you love like Docker? So that makes sense. They've also announced that they can now support NanoClaw, which is not really an offshoot of OpenClaw as I understand it, but a basically a whole new project that's trying to build a safer, more secure version of OpenClaw. Maybe I would almost call it maybe the business version of OpenClaw.

It's called NanoClaw. I haven't used it yet, but you can now run it in a safe sandbox with Docker sandboxing. Next up, let's do some Model Runner updates. We are going to talk through.

Some of the updates to the Docker Model Runner, and that's about running LLM models locally on your machine, kinda like Ollama. And they've had multiple iterations and improvements over the last couple of years. I've also made videos about them. I've also had podcasts about Docker Model Runner.

But they now have some additions, like finally on Mac, we get MLX support, which is a native Apple, Silicon focused model runner that will allow us through something called VLLM to probably get around 20%, maybe 30% performance improvement on our token output. And that's on the same hardware. So that's great. If you haven't tried DMR, give it a shot.

If you've tried it before, tried again, it might be better. They've also improved DMR to support Open Web UI outta the box. About a year ago I made a video and provided some examples on GitHub for how you could use Docker Model Runner locally with Open Web UI, which is essentially a ChatGPT clone. It looks and acts like ChatGPT.

It's pretty great and that you could run that locally. And then using something like Tailscale, you could essentially have your own private AI chat bot that you could access from anywhere. And so that, plus a couple other things, including the MCP Toolkit, which is something you would probably run with Docker Model runner. But you can also run MCP tools in Docker now, and it's, they've had this toolkit for years.

It's pretty great. And it's to me, really the way that I want to run MCP tools. I just don't run a lot of 'em right now 'cause we're all kind of figuring out how the agents can just run CLI tooling more efficiently than they can actually run MCP tools. But think that's a revolving door, and I think MCP tools still have a place in our toolbox, and Docker is adding more functionality to it, including not just catalog improvements to everything that they have there, which there's tons of stuff in their MCP toolkit.

But they're also adding something called dynamic discovery, which will allow your local chatbots if they're going through Docker to get their MCP tools. It gives you basically this short list of MCP tools for finding other MCP tools in their toolbox. So you don't have to front load a bunch of tools. You can now load them in dynamic and discover the tool you need through your AI agent and your harness.

And then you load those up into your project dynamically during your work, which is really where we're needing to be anyway, because we're finding that too many MCP tools are bad for your context window and bad for hallucinations. So you want to keep that very small. And so you want to be able to dynamically load and unload MCP tools as you go. So that's cool.

Lastly, we talked about cagent, which is not new. That came out sometime last year. It's an open source project. Presumably stands for Container Agent, but it's Docker agent for automating things, and they now have a GitHub action for it.

And then we talked through some examples of PR review. As well as like a nightly docs check that has their cagent, their Docker agent, which runs in Docker, running inside of GitHub action to go and check the documentation sites for Docker docs and to make sure that if anything's outdated, that new PRs show up to suggest improvements or to suggest fixes for things. And it does this every day on a cron job in GitHub Actions. So I thought that was a pretty cool demo that we walked through.

I think they're changing the name of that, by the way. I think they're changing it to Docker Agent, so we're just going to have to start calling it the Docker Agent, which is not confusing at all because we've used the word agent in everything. So it's completely overloaded at this point. But I'm going to definitely be checking that out because, hey, I'm making GitHub Actions courses.

So this is a jam packed episode with Michael Irwin of Docker, and I'm so glad he is back and I'm going to learn stuff with him too. So let's get into it. Michael Irwin. Tell the people who you are and what you do.

hello, everyone. I'm glad to be back here. So my name is Michael Irwin. I'm a longtime friend of Bret's and actually a high fiver as well, too.

So join the High Fiver's Club if you're not as well, too. Hurrah! And yeah, I work at Docker. But even before working at Docker, I was a captain, right?

There with Bret and, we're both in Virginia and, we traveled the world speaking at conferences and having all kinds of fun. I'm excited to get in. we're going to have to jump in quickly because I feel like this is actually like three hours of content that we're going to try to cram into an hour. Michael's going to do all the work here.

So, first on this list since we've really had, like, if you didn't know the history, by the way, Michael and I, we've started to do this yearly, everything in Docker. Because could be like a dedicated Docker podcast with as much stuff as you guys have produced in the last year. We could just do nothing but Docker. And obviously we do more than that on my channel.

So the challenge is, how do we catch up? How do we get people To realize all the releases, all the updates, all the features. we're only going to cover the major bits, I feel like. kind of like that old commercial, if you're old enough in the nineties, there was this guy that would talk really fast on TV commercials about he sounded like a car salesman and he was selling little toys and he was, oh, micromachines.

That's what they were called. Micromachines. And I feel like we're going to have to talk that fast, but people can always slow it down in their podcast that's right. But the first thing up that you gave me on your list, was talking about hardened images.

So can you give me, assuming someone hasn't tried Hard images yet. What is the difference between all the Docker images we know about and then the hardened images that we now, like now the industry has sort of established what this is as an industry thing and Docker is one of the leaders. Yeah, so hardened images is a, I would say, a collection, it's a category of container images are really designed for secure, for folks that are interested in making sure that their supply chain is tight and is secure.

Even in the blog post here, the second paragraph there, why supply chain attacks are exploding. and we see, okay, 60 billion in damage, tripling from 2021. No one is safe. obviously, that's a little bit of hype around that as well, too.

But the idea around a hardened image is that when you use this hardened image, it's going to have much less in it to start with. only the things that are needed to run your application. so for example, if I'm running a node based application, I can use the hardened image that doesn't even have npm and yarn and the package managers installed. It just has the node runtime.

Which does change a little bit of how I build the image. I have to actually install those dependencies, maybe in another stage in my Dockerfile. But then my final image is much more locked down and secure. In fact, it may not even have a shell in it.

and so if that container were to be compromised, the blast radius, the number of things that can be done with that container are quite limited because it doesn't have any ability to install new stuff there. So again, it's this idea of. Trading off a little bit of flexibility and ease of use, but to make it more hardened and more secure, ready for production workloads. Right now, these images can still be used locally, but there is a little bit of onboarding and understanding around what you can do in them and what you can't, especially for development.

Is this of the kind where there's like a dev image or an alternative option that has a little bit more in it, like maybe a shell in it that I can use locally? Yeah, so going back to that Node example, I could use a dev variant that then has a shell, has the npm package manager, etc. So many of our images have a dev variant that have these additional things baked into it. And then I can either use that in development or I can use that to help.

Install the things that would eventually need to be, available in my final production image as well. So, not every image has a dev variant, but especially those that I'm going to be building, you know, the node, the pythons, are going to have these dev variants. Alright, so you announced after that, you announced that they were going free. The headline was free hardened images, which Up until then, in my experience, the challenge with other free hardened images was either they weren't really that usable in production unless I paid for them, or, like Google had this distro less thing, which they were really early on.

That was an early concept. we were at the time we were calling it distro. I think now we have the definition of difference between distro less and hardened. Hardened to me is like an improvement on distro less.

Distro less was a smaller image, but also harder to use. And one of the challenges with distro lists it was harder to get to use them and they were only so many of them that were provided. It wasn't like it was the entire catalog. So can you talk to me a little bit about What's actually free for those engineers that are wanting to adopt it?

And then what's the paid tier and where does that line get drawn? Yeah. Yeah. so our free tier is available.

Anybody can just go to dhi. io. and then that'll redirect to the catalog. and there's several hundred images that are available there, on the free tier.

You're going to, you're going to get all these images and anybody can use them. Now the difference between this and the paid for tier, the enterprise tier, is that the enterprise tier is going to give you SLAs around those images. So when new vulnerabilities come out, you know, they'll get patched, they'll get released, etc. But then there's also guarantees, which a lot of organizations need for audit compliance, That there's SLAs around that.

Additionally, the paid for tier has this really cool customization pipeline. So for example, a lot of organizations may use HTTPS proxy certs at their network boundary. And they want to see everything that's going in and out of their network. With this customization pipeline, organizations can actually customize the image that they get from Docker hardened image, to bake in these proxy certs as part of the actual build pipeline.

So by the time the image ends up in their organization, it's mirrored into their org, it's starting from this DHI base, and then has these other customizations applied to it. all these images are built with Salsa level three build pipelines and everything. You can validate attestations and how things are built and whatnot. there's a lot of really cool aspects to it.

But again, at Docker, we decided access to these hardened images should be available to everybody. And it's been neat to see the open source space really start to take up on it. and Aden has adopted it for their base images and others as well too. So, By making these available, it's helping, slowly anyways, the entire ecosystem just become a little bit more secure.

And we also think about supply chain a little bit more than we have in the past. Yeah. challenge before this was always that the, the difference between using, you know, like slim images or Alpine images from Docker official, and then the, Self created, hardened image was a I always felt like a huge leap and it required. I almost felt like at times it required a 10x level of knowledge and understanding.

AI has probably made that a lot easier for us when we can understand things and troubleshoot a little bit better with AI. But the knowledge that even I had, someone who was deeply invested in the Docker ecosystem and obsessed with Dockerfiles and minification of things and, multi stage, I mean, I'm the guy that's writing the 200 line Dockerfiles when you probably could get away with 80 lines of Dockerfile, but I would take it to the next level and I would be the one on the team that was the only one that understood it, which is part of, that's not a great thing because there was, I was using every trick in my.

Toolbag to make this thing slim. And then that the problem was always that the team would have to maintain that. And I would leave as the consultant, knowing that I've created them this really sophisticated minified image that's good or better for production, less CVEs, but if they have one stumbling block or one dependency gets fails and they need to change a dependency lock. It might be a little tricky for them to figure out how to fix that or, there might be a CVEs that they don't really know how to deal with because of ways that I was copying in certain packages versus installing them and like doing sideloading of stuff from other images into the same image.

there was all these little tricks you can do if you get really deep into Docker, Dockerfile stuff. But I feel like these hardened images are such an easy button now that if I was to start a company. Or if I was to walk into a company today and they pretty much all should have requirements for hardened images at this point. But if they didn't, I would absolutely be pushing for them to lean into a hardened image platform because it to me solves a major supply chain risk area with a problem that someone else has already solved, like a fix that someone else has already done for you.

And it is not easy to fix yourself. I think even with AI, to pre build your own image with everything on top of like an Ubuntu or something and have everything thoroughly checked and thoroughly scanned and I think that's still a really rough area to do because there's still a lot in the regular Ubuntu image. there's still a lot of stuff going on in there. So I'm a huge fan of these in case you couldn't notice it on the, for you podcast listeners.

I've been shouting from the rooftops for at least eight years. I can actually go back to DockerCon, I think 2019 where I did a whole talk on Node. js, and part of that talk was really about locking down the images, never using the default image, always using at least slim, you know, the risks of Alpine and Musel, or maybe a little, not so much as a risk anymore, but they were back in 2019, they were a little dicey at times. And so I felt like I was shouting from the rooftops, but the solution to that was to expect teams to like three X their knowledge and just how a Dockerfile works so that they could even attempt this level of sophistication.

So that's my long way of saying, this is all good stuff. Like people should be looking at these to see if they can fit even the free ones before, even if they can't get budget to figure out if they can use some of the free ones, even if you can't use them all, or you can just find a few of the images to migrate over. Like this is one of those things where it's probably a six month project. you probably have dozens of images, like if you're watching this show, you're probably someone who has dozens of images in production And so you are going to have to go one by one, and you should probably, in my experience, probably start with like your programming images, because if you can get like a Python or a Node.

js image to actually start working on Hardened, and you're a Python shop or a Node shop or a Ruby shop, like if you can get that one image that you use for your programming, then you've probably won a lot, because you've probably got a bunch of apps in production that will suddenly Drop from possibly hundreds or thousands of CVEs down to very few, like maybe even if you're lucky, maybe on a couple of hands between all your dependencies. If you're super lucky, maybe you can get close to zero, but just because the base image is close to zero or at zero doesn't mean that your app will be.

But, uh, so yeah, it's like once you install your dependencies. we can all hope and dream that someday we will all be zero everywhere. But, I feel like that's the strategy if I was to step into a shop today, it's like, okay, let's go see what we can do with your very, what's your most popular image? what's the one you're using everywhere?

Let's go see if we can attempt that. And then you gotta get the developers on board. And then you're going to have this whole process where the developers All of these are going to like, it's not going to work locally, so you're going to have to swap out for the dev images and you're going to have to train people and educate people on how these images work a little differently. And then maybe you can get management buy in when you finally get it to work and they're like, I see the benefits.

Our security team loves it. let's go for paid and let's get a, purchase order together. And then finally you can start rolling out some more of these customized images. I love that you can build them customized on the platform.

That's a pretty cool. feature because we're all like, this is all one on one stuff that we're talking about. But the day you hit the ground running with a new image and you realize that the customization you have to apply to an image is usually significant. Well, and also well, the nice thing about the customization pipeline then is that Every time the base image, okay, if we have a new version of, we'll just use Node again, the next version of Node gets pushed out, that customization is automatically going to be applied.

You don't have to figure out, wait, how are we going to respond to updated base images? Now we need to build our own images and now roll it out and all that kind of stuff. it's just part of the service. So, It's good to hear from people out there in the wild actually using it.

Cause I kind of fired all my consulting clients a couple years ago. back and looking for some new ones that want to do some AI stuff in DevOps. But, I took a break from consulting to just do content and make courses. And what I noticed was that was around the time that chain got really big and then eventually Docker came out with hardened images and I don't yet have production experience with a lot of these hardened images and I am very curious about the challenges to adoption, the edge cases that maybe they don't cover yet.

are there situations where you can't use hardened images? is that a thing or are there scenarios where Hardened images are a utopia. And every single thing you use in your company is hardened. And you make a unilateral decision that only hardened images will ever be used.

I haven't heard a lot of the stories I hear. There's a ton of stuff on the internet about people like day one with hardened images, but I'd love to hear some of the battles from the trenches. So, anyway, Anything else on hardened images? We could talk about this all week.

We could make this a hardened image episode, but we have so much more to talk about. yeah, I think that's good and actually kind of serves as a good segue into what we get next here. So All right. Gordon AI agents just got an update.

Okay. So, I can speak to a little bit. Gordon AI is uniquely in Docker desktop, right? Yes.

Okay. So yeah, this is not a web service. This isn't a website. this is a feature in Docker desktop.

It is a free feature, correct? Correct. and when it first came out, it was actually pretty early. this was at least a couple of years ago, I feel like.

and it was originally designed around helping answer my Docker specific questions in case I didn't have ChatGPT for subscription at the time or whatever, and so we were using it to understand maybe what was going on in a Dockerfile, like you could give it a Compose file and ask it to describe what's in that Compose file. And I remember very specifically one of the early things that we were focused on with the Docker team as captains was improving that AI so that it was actually smarter about Docker specific stuff than the general ChatGPTs of the world, right?

Because they just go on world knowledge, and there's obviously a lot that's happened in Docker, and there's a lot of updated documentation, and things change constantly. So it always felt to me like it was becoming The Docker, I didn't have to tell it, Hey, please go read the documentation because it's changed or, Hey, don't use the version statement and compose anymore because that's six years old. We don't do that anymore. Like it, it started to understand the latest habits.

So that was then, but I haven't tried it lately. So what's going on with the Gordon beta is Gordon back in beta or is Gordon always been in beta? Yeah, it's always been in beta, and yeah, I don't know when it's going I mean, AIs in general are the new Gmail. right?

Like beta, AIs all should be labeled beta at this point. Like they're all beta. It's always changing. yeah, so what we've done with Gordon is, we've actually completely re architected it.

And, we'll talk about CAgent slash DockerAgent, a little bit more in a little bit. But actually, Gordon is backed by DockerAgent now. and so it, it provides opportunities to do multi agent kind of stuff. And so it's much smarter about how it does things.

So, this is through the CLI interface. I'll get it. the prompt was give me a summary of my running containers, and it's pulling up a coding agent and that kind of stuff. and you'll see like coding agent and DHI expert, DHI migration.

so we were just talking about migrating to DHI just a little bit ago. We actually have an agent that's specifically tuned for Migrating images to the DHI, and so I've pulled up node apps and it's, you know, here's a single, stage thing, and it's smart enough to know, okay, I'm going to have to pull a dev variance and install stuff and copy it over into multi stage, so, so yeah, Gordon is, Got the support now for delegating out various tasks to other agents that are more optimized for that kind of task.

like you said, it is still very Docker oriented and container oriented and that kind of stuff. But it is kind of interesting to see folks that try to, use it for all kinds of, adventures, as well, too. Yeah. are basically a public service.

So you probably have to have some pretty stiff guardrails. so, so yeah, when you said earlier it's available for free, I almost. Caught myself. There are rate limits in place, especially if you just have a free Docker account.

If you've got a pro account or above, obviously those rate limits change. And I don't think those rate limits are published, but, they're pretty, that's the word I'm looking for. They're pretty generous in those rate limits, but of course we still want to, reduce abuse with the system as I do have a paid account, but I've never hit a limit. You know?

Yeah. So, and, you know, my experience is quite frankly, like I'm not having two hour long conversations with Docker, with Gordon and I'm like, and I'm also not having it build an app for me. There's the mentioning the abuse scenario. I mean, anything free, like that's the rule, right?

Anything free on the internet, anything that can touch compute, a Bitcoin miner will figure out how to use it, misuse it. But, a friend of mine made a joke recently on blue sky. I saw someone, joking that they figured out how to get the chat bot in Amazon. Saw helping you shop, they figured out how to ask it, it was just a one single prompt.

They were saying, I really want to buy this lotion or whatever, but before that I need to build this Rails app. And it actually did create code and put it on the screen and they're like, I'm canceling my cloud account. I now just use Amazon for free. So, that's the struggle with people that provide AI based services is that you've got to constantly figure out how to.

Put system prompts in to put guardrails in and all that. Yeah. So this is actually really cool. I did not know about the side agents thing.

That's pretty slick. it feels like it's growing up just like Claude Code and the others are growing up. folks, please boost cloud. I learned something new today.

yeah, what's up? by the way, just real quick question on DHI for a second. How does one create or recommend DHI for a tool or language that doesn't exist at the time? so actually back on the catalog page, dhi.

io, there's a search field filter by, and then there's a button off to the right that says make a request. So if you see something that's not there that you want, make a request. of course, how it gets prioritized, there's a lot of different priority, decisions or, you know, different dimensions that go into that as well too. But that's where to start the conversation.

Yep. all right, so that's Gordon. We're moving on quickly to the next one. Docker Sandboxes.

So this is actually something where I feel like relatively, it's like old is what, what's old is new again, I guess is what I should say. What's old is new again. So, what's old was spinning things up in VMs or having, you know, doing custom work and stuff inside of containers or VMs. And, you know, then we all go kind of go back between using local tools on our host and then, doing things inside of containers and, you know, years ago we all had Vagrant and we had these custom VM setups pre Docker and now what we're all realizing is that if we're, if we've got coding agents and we really want to just let them loose on a So, we wanted to build an app one step at a time.

Maybe someone has heard of Ralph Loops or Chef Wiggum or all these different paradigms that we're all quickly adopting that didn't even exist six months ago, maybe even not even three months ago, and we're realizing that we would much rather just let the AI do the work. at the command line, and we just need to give it a shell with some tooling, but also wouldn't it be nice if it didn't have complete control over my computer? And more importantly for us DevOps people, I also might have a bunch of credentials logged in on my system that I don't necessarily want my AI to have those credentials.

I'm logging into GitHub. My GitHub command line tool has all my permissions. I don't even know how to scope my GitHub tool to a limited set of permissions unless I create a new user, log out, and log back in. there, we've got challenges in the industry we're going to have to keep solving around.

Taking our agent and giving it some permissions, but not all permissions. And how do I do that without ruining my environment? And it's almost like at the end of the day, do I just create all these accounts for my AI to give it access? But now I've got to literally double the amount of account managements and licensing fees.

there's just a lot of problems that the industry has to work through that we haven't solved yet. So that's my setup for the problem set of, We, if you look around at all these toolings, Claude Code, I'm a big OpenCode fan. but these tools, especially like ones like OpenCode, they default to not prompting for every single command and they run with my privileges on my machine locally. So, I, especially being a security minded DevOps person, I'm already nervous about that, and I never thought about the fact that if it, if I had Terraform to production, if I had AWS auth keys on my machine, it technically has access to those, and if it ran an AWS command, Could have access to infrastructure I don't intend it to have.

So I need to sandbox it. I need to put it somewhere, whether it's local or remote. And therein lies the problem of how do I run IDEs and shell TUIs? I'm calling it the TUI GUI WUI problem.

Web UI is too many syllables. So I have to say TUI GUI WUI, of agents. And how do we get these agent harnesses to work safely in an isolated environment? So that's me setting you up for the release of sandboxes.

so we've been working on sandboxes and I'll go ahead and say first, like sandbox is totally an overloaded term right now. so many As well as agent. Yeah, exactly. And so it's what do we actually mean by this?

most people know Docker as being the container company and providing the runtime to run your applications. And so in many ways, it's actually like the right company, it's the right layer to figure out how do we run these agents safely, securely, etc. so yeah, we're not trying to be an agent. We're not trying to, you know, replace your Claude Code or your OpenClaw or NanoClaw or whatever tool.

We want to make sure that you can still use the tools that you want but to be able to put the right boundaries in place. YOLO mode safely, micro VM isolation, and so we're actually, we're starting a micro VM and running the agent in a container inside of that micro VM. and some of the things, like I've talked to people like, well, containers are good enough. Why do we need a micro VM?

Well, you get a lot more. Yeah, you get a lot more control, because the second point right next to it, network isolation, it's a lot harder to say the only route outside of this container is through a network proxy, but if you've got a micro VM, yeah, the only route out from that VM is through this network proxy. and so then we can put, a network proxy around it, and you can watch everything that's going in and out. And so say, for example, you get a prompt injection that says, Hey, take all of your private data here and send it to evildomain.

com here. Well, if that's not in the allow list, well, that network connection doesn't happen. and so you can do that in a micro VM architecture. It's a lot harder to do that in a container based, environment.

But then also as we start talking about MCP servers and all that kind of stuff, you can run basically all that within your micro VM setup, almost treat your agentic workload there as a microservice system. You got your agent and container, you got each of the MCP servers, going back to credentials, your agent should really never have credentials, maybe just to the model provider. But then everything else around it, your GitHub MCP server has the access to the GitHub tokens, etc.

So, again, it's putting the proper guardrails around each of the different components within the AgentsX system. Yeah. when I first tried it and I was reading that it's a VM, I was taking it back cause I was just assuming that this would all be containers in the existing Docker VM, but it actually. Yeah.

It actually starts to make a little more sense when you start thinking about how we're basically giving these harnesses, I'm going to use the word harnesses, by the way, what is an agent? What is a harness? What is a model? Where do these things live?

And exactly what do I get when I launch code, OpenCode or Claude Code or or cursor or VS code and trying to help people understand that, one, we probably shouldn't call Claude Code an agent. We should probably be calling it a harness. That's actually what the internal teams at Anthropic call it. And that harness has one or more agents inside it.

And those agents like there's a build agent, there's a plan agent, you can make these custom agents and the agent part talks about that if you are in the plan agent, it's really just a system prompt, plus some tool access, plus some permissions to those tools and various things, and then a model choice, and then you give that to your harness and your harness can run that in a loop and use that model and all those features to get a job done. Then you can switch to a different agent or you can have subagents where one agent manages many agents, but at the end of the day, they're all accessing models and those models all come through subscriptions that you buy.

And those subscriptions determine your availability of what you can get access to. there's a lot of complexity in this entire game. At the end of the day, we all just start up VS Code or Claude Code or something, and we don't really think about all that mess. But when we run it, and we're running it in a directory usually on a project, and we typically want it scoped to that directory, unless we're maybe working on something larger, But the point is there that you usually don't need it to have access to slash bin on your system or a slash user.

you need it to just be there. And then when you're still running that, you need to run another one in a different directory because that thing's going to go cook for 20 minutes and you need to work on something else in the meantime. So you actually need multiple sandboxes. That these agents don't have necessarily access to each other's stuff.

And one of them might, especially in the DevOps world where you deal with certain things of privilege and certain things of not, you might have one agent that actually has like a Terraform production key in it, or a staging key, and another one that you want, Very isolated. That is going wild on a code base that you're just making a crazy PR that you've just let it loose. And you're going YOLO mode, but on this one, you've given a lot of rules and you really don't want these things to meet, You actually need separate sandboxes simultaneously, which historically the Docker Desktop VM doesn't do, right?

Like it's a single VM with a bunch of your containers running in it. And so when I first started using it, I started to realize, oh, this thing is actually scoping my agent setup per directory. And I can have one or many of these all running simultaneously in different directories. And I'd start them up and down like I do containers.

But they're really like, it's almost to me, it's my new command to run OpenCode. So instead of me just running OpenCode directly, I do this Docker, sandbox run OpenCode in a certain directory. And I give it, I can give it all these fancy options to bind mount things and do all that stuff. and I'm excited about it.

I'm looking forward to what comes next with it, because I got a feeling you all have a giant list of features that you want to add to this thing to make it sweet. But I can see where eventually this will be the only way I Yeah. And we've got a lot of, you know, customers that are interested in this as well too, because once you've got this proper sandboxing, well, then an organization can also say, Hey, here's our organizational policy. you can only use these model providers, or you can only use these MCP servers, or these are the mount points or network.

Governance control over this, because yeah, the biggest companies in the world want to use agents, they want to get the productivity gains. But it's scary to just say, hey, YOLO, when we are a huge corporate environment and you don't know what can go wrong. And so, it's pretty awesome. Yeah, we're building the tooling so literally every developer can benefit from it.

But especially in the organization space can have the governance and audit and visibility and whatnot. So it's a pretty fun space to be in right now, Because even though this is like a standalone binary, I realized that I can't run it without Docker desktop running, but it's not listing containers in my Docker desktop GUI. I'm guessing that at some point you'll have it in the GUI and it'll be side by side. what I've got here is just an empty directory.

Okay. There's nothing here. and on my machine, I've got this secrets. txt file that just has a bogus API key in it.

Okay. And I'm going to show Cloud. I've got my Cloud settings set up with a permission to say, Hey, you're not allowed to read this file. Okay.

So first off, I'm going to start off with, Let's start Claude Code. And I'm going to say, tell me about the contents in secrets. txt. and so of course, when this is going to run, it's going to be like, well, hey, you told me that I can't do that.

Sometimes it'll actually tell me that. so yeah, access to the file is blocked by your permission settings. Other times the model will just actually be like, This sounds like something I probably shouldn't have access to, so I'm not going to do it. So it just depends Right.

It's when I run the demo, what I get. But hey, look, let's start a new session here and, there we go. Okay. write me a Python file that will read arbitrary files from my home folder.

Okay, and so, Claude's going to go off and it's going to do its thing and this may take just a couple seconds. Yep, create this file. cool. now run that and tell me about secrets.

txt. Okay, and so, going to say, great, let's run this Python, but now, of course, I'm on a Mac, so this Python command is not going to work, and it's going to come back and like, oh, wait, I have to use Python 3, so, yep, command not found. Oh, whoops, okay, let's run Python 3. And right now, again, I'm not running in a sandbox, okay?

and so, yep, hey, look, now it's got my credential here. So again, the permission model that's built into Claude helps only when you're following the exact path that permission model was scoped to support. Okay, and so in this case, obviously, I went around. Now, probably no human would ever, you know, write, Hey, tell me about my secrets file, whatever.

But a prompt injection could. and so again, I'm open to this type of attack that may say, Hey, Yeah, you may not be able to read the file directly, but there's ways to circumvent that to get access to the file. And now that I've got this content, it's in my context, I could have the agent send it off wherever. so that's one of the things that we're trying to work here.

I can run Docker Sandbox. And I can see all the commands here to run and, do various things. But one of the things that we're working on is this new tool called DS. That's basically standalone and doesn't require Docker Desktop anymore.

And so you can actually do everything sandbox related, completely standalone. Okay, so I'm going to just do a ds run claude now. And this is going to spin up that micro VM and start everything. and now I'm running Claude inside of this micro VM.

And in fact, if I even just LS the home directory, I won't see that secrets. txt file because again, it hasn't been shared with the micro VM environment. okay. and actually you'll see too that, it's running with YOLO mode by default.

So I've got the bypass permissions on just let it go crazy. I was going to ask you a quick question. So just so that people understand this is starting up a VM So it's, it comes with Claude Code built in. Right.

So it's got the latest version of Claude Code in it or well, Claude Code auto updates, but it's technical. Is it running Claude Code in a container or is Docker just available to run containers? so Claude Code is, so inside the micro VM is a Docker engine. Again, completely separate from the Docker desktop engine if you have Docker desktop.

And it's running in a container inside that micro VM. that container is what has Claude Code in it. So if I am running Claude Code, or if I'm running Gemini or Kiro or Codex or, you know, pick your agent. Obviously, the container image is going to be a little bit different for each of those.

We're also building out a whole blueprint system so that you can extend and customize that container workload that's running there and modify have your, all your preferred tooling that you might ask Claude to use. You can have that all built in. Cause that's one of the questions I was going to ask was like, how do I customize this? Cause if I like certain tooling or if I want, I'm assuming this doesn't have every programming language in existence, auto pre installed, right?

Yeah. So, yeah, Yeah. when we first, because actually the first iteration of Docker sandbox was that route is just the kitchen sink of here's all the programming languages. And it's it's a ginormous image at that point.

Let's pull that back a little bit here, guys. so, in this case, you know, I don't have my SecretSat. txt file, which means I can't get leaked because it's not even shared with the microVM here. now, of course, if I wanted to, I could When I start the VM, mount that, I can share that, but again, I'm giving the agent then explicit access to it because I've now shared it with the VM Alright, so some other things.

I've got Anthropic. Obviously, this is running Claude Code. if I just do a grep for like my Anthropic API key, you'll see that, well, there's no output here that I've got no Anthropic API key defined here. That network proxy that we talked about earlier is actually injecting my API key when it's sending requests off to, to Anthropic.

The API key helper here is just echo proxy managed. Like the API key that the agent thinks is using a key proxy managed. But again, the proxy around it is then swapping it out with the credential that I've already pre configured it with. So, I didn't, by the way, when I was running it, I wasn't configuring it ahead of time.

I was just getting the prompt and then I would auth in with OAuth on it. And then it's say, so it appears to me that what these things, these sandboxes are saved on disk after I spin them up and they're, so they're there for me to restart them. And so whatever settings, if I customize them individually, those settings are in that. And I can imagine myself creating an eventual workflow where I'm somehow mounting all of my favorite settings for things, so that I don't have to do this over and over again.

But the key problem is a tricky scenario of like, how do I auth in and where does it save those? And how do I get those in there safely? And we're going to have to solve that problem for every CLI tool. Like I've got one password that's off on my, like, if I think about the number of CLI tools that I have on my host that are already authed as me that I may or may not want my agent to have access to.

It's more than I can think of. It's more than I even realize. And it's not just agents, it's GitHub, it's 1Password, it's AWS, it's DigitalOcean, it's Vercel, you name it, go down the list. And I'm going to have to figure out a method for how do I plug in those tools when I need them?

This is really just bind mounting files, right? I feel like these concepts for the sandbox are translatable between how we run containers with bind mounting and how we run these sandboxes. Was that, is that a true So, for example, again, when Claude Code is sending API calls to Anthropic, the network proxy around it is injecting the credential on the way out, and we've got hooks in place so that when you send requests to GitHub, here's how you can also inject your credential into those calls as well too.

and then the secrets engine can be fed by, eventually by one password or other password vaults as well too. So that there's ways to kind of hook in your credentials without the agent ever, and the agent will never actually have access directly to those credentials. They're all being injected by the security boundaries around it. Can I start these with compose?

Not right now, no. Okay. Cause that sounds like when I think about all the things I might want to inject in there, I want to spin up three different agents at the same time, really. I get to my desk and I'm like, okay, I got my five projects I'm on working on simultaneously.

I can imagine myself wishing that I could just manage all this with a compose file, but it's just not launching a container in the default Docker system. It's launching a bunch of VMs with their own containers. Anyway, just, I'm going to be, this whole show is going to be really about me just throwing you a bunch of requests that I have for and that's okay. So just one other quick little demo here.

So if I were to curl example. com, and I'll just put the verbose flag on it. what I'm going to see is that it's blocked by the network policy. Okay.

So that there's basically, Hey, that's a domain name. That's not authorized by the sandbox. now I can, when I start also DS without giving an argument, I get this cool TUI but I can see all the network requests that are going in and out of the sandbox, all the different domain names that are being used here. And I can see that example.

com. it's pretty cool. This is the first time I've seen a TUI That's I can actually like double click on it and open up the entry here and yeah, let's hit A to allow this host and sure, let's allow it and see that it's been allowed now. And now let's just go back to sandbox and say, hey, go and curl it and now it works.

And so like I've been playing with scenarios where. I tell the agent beforehand, hey, if you're running a network blocked issues, let me know and I'll go and adjust the settings if appropriate. And there was one time where I was trying to do a Go build and the version of Go that it needed wasn't what was installed in the sandbox. And it tried to download and install Go and it's like, hey, I can't do this.

And then I just go over here and say, yeah, go ahead and allow Go and okay, continue agent. And it was able to download and just go. so it's. It worked pretty well even kind of when I told it, Hey, you're running in a sandbox.

You're probably going to be network isolated and bound. let me know when you run into problems and, worked out pretty well there. but again, if I get a prompt injection that tries to send requests off to bad places, well, I can see that. And it's going to be blocked as well, too.

Now, of course, this doesn't, because we actually saw an attack once where folks were taking private data and they would use a create issues tool on GitHub, and create an issue on a public repo that then the description had all the exfiltrated data. Of course, this isn't blocking that. So, Yep. Like blocking that kind of stuff is a much harder problem.

How does this work on windows? is it inside WSL or is it separate VMs? Yep. So it's, so.

We actually have, micro VMs. We've made our own VMMs, our own virtual machine manager. that's actually crazy performant. and so, yep, micro VMs for each of the different, sandboxes is the same experience over there.

Yep. So does that mean you're not using the WSL shell to do sandboxes? What does that mean? I'll have to get back to you on that.

Did I find, I found one that you didn't know the answer to. you got me. I stumped him. is complete.

the master. The man with all of the knowledge has now been, that was my I haven't, I don't have a, it's, yeah, so cutting edge. I don't know all the Windows answers yet. Right?

Well, I do love that it can run without Docker Desktop only because, you know, we're like in this weird twilight zone or like middle earth zone of like, we figured out what agents are going to look like inside of harnesses and where we can spin up multiple agents, but we don't yet have the rigor to Like, we're going too fast for security is essentially what I feel like the industry's attitude is right now. We're going too fast. And so, all of this security and locking down and appropriate things that we all really need at the end of the day is sort of lagging behind a little bit by months, which in this speed of a world, that is like almost feels like years.

And so I'm noticing is I'm actually using Docker less right now because these agents aren't necessarily built for containers yet. Although, you can start to see, I was actually working with Claude last night to help me understand, we won't have time for this, but figuring out how I can run OpenCode server In these sandboxes and then run the OpenCode client, because unlike Claude, OpenCode has a client server model, which I absolutely love. It allows me to run the server on my local machine, and then I can be remote on my phone, on a browser, just talking to it remotely through a client server model.

And I can do the same thing with their GUI and their TUI. And I'm, I was like, Oh, maybe I can run the OpenCode server inside of the Docker sandbox, 24 7, just have that thing constantly running. And then, when I'm at my shell, I can just jump in and out, using the OpenCode client, and then I can also connect remotely from the OpenCode GUI to that Docker, server through Tailscale. And so I've kind of in my head, I have this vision for what I want to make work.

I just don't know whether it's all going to actually work yet. I actually haven't tested it at all, but I was theorizing on a plan for how I can have this always on local, essentially harness that's always available for me. Nice. what we want to be able to support as well too.

and so the version of Docker sandbox that's out right now doesn't really have an easy mechanism to publish ports or yet to access what's running inside the sandbox. this version of the. The DS of Docker Sandbox here does provide that support. and so you'll be able to publish ports.

And actually one of the cool things here, without leaking too much, has a completely new Docker engine under the hood as well, too. And, as a, the ability to actually publish ports even after things are already running, to modify port publishing and all that kind of stuff as well, too. So, you can start a sandbox and then later on be like, I actually want to publish a port now and you'll be able to do that. and then also unpublish it later.

So you can kind of pick and choose when you want it exposed versus not as well too. do we have an estimated time of dropping the DS CLI or is this just a someday maybe? very soon. Okay.

Yeah. I mean, maybe by the time we get around to editing and publishing this, that will already exist because we are, I'm not exactly fast at like the same week, publishing of the podcasts. okay. So are we at a spot where we can move on?

Cause we do have a few other topics or is there anything else you think is key for people to understand around sandboxes? Yeah, I think the only other thing, I'll just mention too is, so NanoClaw, we announced a partnership with NanoClaw as well too. And so you can run NanoClaw, and as it spins up various things, it's used in sandboxes. now this is the version of Sandbox that's deployed right now, we'll move it to DS soon as well too, but again, now having, you know, your Claws running these isolated environments, it's, opens up some really neat opportunities, but also again, reduces the risk of what happens when things go wrong.

Right. And NanoClaw, for those that don't know, it's a, written from the ground up, more secure and stable version of OpenClaw. Is that an accurate statement? I would say that.

And yeah, it was definitely built with the kind of sandboxing model in mind, rather than just the kind of open aspect that the other Claws have right now. Yeah. but it's amazing to most of these are like, yeah, this didn't exist a couple of weeks ago. And now it's a full blown, project and even, NVIDIA GTC and, it's being announced on the keynote stage and every company needs a Claws strategy.

It's this didn't exist just a couple of months ago. NanoClaw has already got 24, 000 GitHub stars and presumably didn't start until after OpenClaw came out, which OpenClaw broke the record, I believe, for the GitHub stars. but the real quick on the philosophy, I'm just going to read for the podcast audience that can't see the screen. The NanoClaw philosophy.

is, six bullet points. Small enough to understand, secure by isolation, built for one user, AI native, skills over features, and the best harness, best model, runs on Claude Agent SDK, which means you're running Claude Code directly. The harness matters. Okay.

So yeah, I haven't actually ran it yet. and I have been avoiding OpenClaw, simply just, wanted to let it settle. And I wanted to get the insanity out of the way. sort of like the, I don't want to spend three hours setting something up to make it work.

You know, I just want something to work. So I'd rather, and we all know how these big these things, when they, whenever something like OpenClaw happens, it's, in the industry where it's captured the zeitgeist, always like, well, I'll give it a couple of months to cook and then it'll Then the documentation will be better and my headaches won't, I won't be like bashing against the wall mad about, but I'm lucky to have a couple of friends that are like neck deep and OpenClaw and make videos on it and stuff like that.

So I really just watched what they're trying to do. And I'm like, I'm going to give it a few more months. I'm already so busy learning all the other AI stuff. I don't really have time anyway.

So it's cool that, I will probably end up starting with NanoClaw in Docker sandbox first, more than anything else, more likely. All right. Moving on from, NanoClaw Docker's, supporting that. I think there's some of these are probably some more rapid fire things.

You want to run through them real quick? Yeah. I think we've talked about, Docker model runner, we've had it out for about a year now. it's constantly still getting lots of new improvements and updates this particular.

Announcement was just about a month ago, bringing VLLM to macOS with Apple Silicon, which is a pretty big endeavor, to be able support VLLM Metal, and have native, the ability to run these VLLM models natively on Apple Silicon as well too. So, really cool stuff that opens up a whole new world of models and model selection. So, again, if you're building applications and you want to use local models, this opens up a whole new world. Catalog of models, that are available to you.

To me, the important part here, if I get, I'm getting it right, is, MLX is the format that runs more, I don't know, what is it, 20 to 30 percent performance improvement on Macs. cause it's designed for Apple Silicon and, that's one of the reasons I currently use LM studio a lot is because it has the MLX support. And so this V LLM. Essentially allows MLX to be now usable with Docker models, which means that if you're on a Mac and you're using Docker Model Runner, you will see a performance boost if you switch to V is there something I have to do, or do I have to download new models?

I presume because they have to be yeah, I mean, so, the models are a little bit different. there are VLLM models, but yeah, you just specify that the model and then it, you know, if that's in your compose stack, the next time you start up your app, it'll just download the model and that, that's it. It's mostly hands off at that point. for those of you interested in Docker Model Runner, I have a video that's now a year old, but it's probably still very relevant when it comes to understanding the architecture of what Docker does when it runs a model.

why would I use this over something else? if I'm already using Docker, how can I inject models into my existing Docker Compose patterns and all that if you're curious about that on YouTube, I still have a couple of videos on that from last year. the next one is OpenWebUI, plus Docker Model Runner. So OpenWebUI, actually I did also have that demo last year.

that's a ChatGPT clone. I feel like in some ways it's actually superior to ChatGPT, but, you can self host your own web UI to give you your own ChatGPT like experience on a model of your choice running locally or, wherever you want to run your open weight models. what's improved here now that we've got a new announcement? the second paragraph here is the kicker.

So yeah, with this update, OpenWebUI automatically detects and connects to Docker Model Runner right at localhost 12434. So if Docker Model Runner is enabled, OpenWebUI uses it out of the box, no additional configuration required. Models from Docker Model Runner, but now OpenWebUI has official support. zero configuration, you can just kind of spin it up and go.

and it's, yeah, so another way to play with your models and access them. So, it's been a great collaboration with that team as well. Yeah, and if you're someone who happens to have a half a terabyte of VRAM, you can run killer models that, Woohoo! are near the performance of the state of the art model.

I have a 48 gig of RAM, and I'm constantly sad at how little of the models I can run on my machine but that is life. That is life for now. custom catalogs. What's this about?

I don't know. Yeah, so this is a new enhancement in our MCP catalog and toolkit area. we've heard from folks for quite a while of great, you've got your own catalog and it's pretty easy to run the MCP servers from the Docker catalog. How do I provide my own catalog?

How do I put my own custom servers into that? and so this is the documentation on how to do that. a little bit of a process to have to set up the catalog file and all the different things that are needed. but then once it's there, now you've got this custom catalog, you can distribute it with others and then use it in the MCP toolkit and all the other tooling there as well, too.

So, now you can bring along your, either your own or your organization's private MCP servers. there's the first class support for it all. Yeah. and if played with Docker MCP toolkit, there's a lot of scenarios where you can use, you basically can use Docker to, augment your local harnesses, your local, you know, AI work, anything you're doing locally with, custom MCPs, without having to do a bunch of work.

on each one of your harnesses. You can actually do that in docker. If you're a docker person and presumably if you've been watching this far into the video, you are a docker person. so it is, to me, it is a very, it's almost feels like a necessary Toolkit.

Now, if you're doing any sort of adding, not only just using MCPs with your AI, but also if you're developing any sort of custom agents or any software that might have an LLM involved with that software. it also feels very easy and I can manage it through, all the Docker tooling like you would expect. Very cool. next one, dynamic MCP.

I don't even know what this is. This is new to Yeah, so the idea here is, so if you connect one of your harnesses, to the Docker MCP, either toolkit or gateway, what will happen is that there can be tools that expose, that allow the agent to go and search for MCP servers that then expose other tools. so for example, I may want to start off with a coding session that I don't have the GitHub MCP server enabled, but maybe later on, the agent decides, well, Hey, I need to be able to look up issue details.

It can use basically a search function to say, Hey, go find me a tool that can do this for me. so what this would do is that. It would search for it, find that, assuming that you've got that in your catalog and configured and ready to go, etc. But then it can add it to the session and then execute that tool.

And then even afterwards, an agent can say, well, hey, let's go ahead and get rid of that. So the idea there is with this dynamic MCP, be able to manage the context window of how much of your context space is being used by tools. And so if you can dynamically add, remove, and kind of adjust that. then you can have more of your context kind of focused towards your actual application, the files, et cetera, rather than just a bunch of tool descriptions.

So, here's the list of tools that are provided through that. So you can, find, add, configure, remove, exec, code mode, et cetera. So there's a I'm giving the AI tools to manage my tools. Exactly, again, based on the configured catalog that you have.

So, the last thing you want, I did experiments, a long time ago of can I give the AI a tool to make its own tools? and it got kinda scary there for a while. but yeah, that's kind of the idea here. All right, man.

we're going to keep going. We've got a few more minutes. Cagent, GitHub action. So what is, first off, what is Cagent?

So Cagent is actually, it's our, it is a, an agent harness. That Docker has made, and it's fairly opinionated, but the idea with Cagent, is that in a YAML document, I can describe the agent that I want. Okay, I want an agent that is going to go do research, and then another agent that actually then writes a technical blog post about the things that the researcher found, etc. I can kind of set up these different agents.

we've been using them internally in quite a few different ways, but recently we've wanted to be able to start using these in our CI pipelines, and we'll see some examples of that here in just a second. this was a GitHub action that we made that allows you to basically plug in an agent into your CI workflow. Again, using Cagent, which is open source tooling, and so in this small snippet here, it's going to point to an agent. yaml, which describes what's the prompt for the agent, and what tools does it have access to, what models is it going to use, etc.

but in this case, prompt is going to analyze this code and take a look at it. and there's a lot of other things that the action can do. but for a couple examples, And this is coming from our docs team. all of our Docker docs now are using this agent to review pull requests.

there's a specific workflow that we have in that action to review a PR. and so it's going to, have a base prompt. But then since this is Docs, there's also an additional prompt. So here's an additional prompt of things that we want to look for and, style guides and priority issues and basically the agent's going to look at this and determine, does this pass the rules or not?

and so that's dramatically reducing the time it takes for our docs team to actually review a lot of these PRs. For the most part, if the agent says, yeah, this looks good for the most part, then it's just kind of up to the human to look at it and say, just final validation, is this file in the right place, et cetera. Let's sign off and let's go. So we're starting to use these agents more in our CI pipelines to review our documentation.

And the final link here is actually a pretty slick thing that the docs team did is they're using this agent and running it nightly. So there's a cron job that runs each night. And what it's doing is basically freshness checks on the documentation. And just saying, hey, you know, are things still accurate?

Are they still valid? And, if for example, we update our style guide. Then the next time that the agent runs through and kind of scans things, it'll pick up issues and it'll automatically create the GitHub issues and, document it. so yeah, there's some like scanner state and just some cache mechanism, things that, yeah, it basically just, It goes off and does its thing.

and it's, so again, this is something that now runs nightly, and we have these agents running and then we wake up in the morning and say, okay, well, hey, what documentation needs to be updated? And it does like even little things with like, I saw one recently, it flagged a page that said, Hey, this feature, was just recently announced. And the agent was like, recently announced was true, maybe six months ago, when it was actually recently announced, we should probably update this documentation.

and so like, it's catching little things like that, where again, as a human, I'd have to take time to go and find all those things, but that's hard to catch in a style guide. but it's something that an LLM can pick up and call out right away. Yeah. That's, that's the little stuff that's annoying, especially when you're trying to like, understand something and you're seeing this inconsistent, information, I think I even pinged in the Captain's channel.

We were, because we were, a couple of us were trying sandboxes and I noticed on one page it said the OpenCode sandbox was. build, in development and on another page, it said it was available. And those little things are so hard, unless you're like the person, unless you made a mental note, not even a mental note, you have to physically make a JIRA ticket or some, ticket that you. You were like, okay, we're going to have to come back to this later when we launch, because this per currently, this stuff shows this current status, and we're going to have to update that page.

But then later, you actually make it on a different page. So then you don't even think about the old page. But documentation doesn't tend to have those dates. So we don't look at a documentation and go, well, this documentation page was written six months ago, so I expect it to be outdated.

Like, we expect documentation to be current for the current version. And this is, this is one of those things where pretty soon we're all going to just be We're going to have, we're honestly going to be more critical, I think, of documentation that's outdated. because we're going to be like, you just had, all you got to do is put an AI agent on this. I understand that you don't have all the staff to do this stuff constantly.

the documentation team at Docker has always been fantastic. it's amazing how, if you remember, even just five years ago, much less 10 years ago, it's a lot of different things, but I think what's really important is the level of upkeep and maintenance of the Docker documentation over the years, and as it's evolved, and as products have become launched and fallen off of, you know, Docker launches lots of ideas that don't always make it into production, and don't always last forever, and it's just got to be a lot.

not all of us have public documentation. we all have got private documentation and the idea that I can come into work and just approve 10 different things that fix one line documentation errors. And that's like so much better than me. what was the alternative, right?

It was literally rereading documentation over and over again, manually, just so that we can find that one little line where Oh, we're not on V13. We're now on V20. And we've got to update one line of the doc file. these are the kind of things that, just suck.

And the fatigue is so real for a human to do that, but an agent like, great, yeah, I'm going to do it every night. Who cares? Kind of thing. And so, yeah, it'll pick up on those things that we would just simply gloss over and miss.

I think that brings us to the end of the list, which is only a partial list, and there are a lot of other things. I'd love to spend more time on Cagent and Sandboxes. it sounds did you come to, other than the DS tool, which is a great little, drop. Is there anything else?

Is there anything else for, like You're working on, now, you're thinking about? I mean, there, there's a lot more that we could hint at, but, we may have to save it for another episode, Okay, we have to save it for another time. Well, I appreciate all of this, upkeep on my audience understanding how Docker is essentially trying, you know, I look at this as like Docker is like every software company right now, adjusting to the current climate and figuring out how On one way, in one way, it feels like the AI world forgot that containers existed and that they've moved.

It's like they're going back to the roots of what we learned over the last decade of how really we need to be confining all this stuff to containers. And they forgot all that because it containers requires a little bit of extra effort and they don't want to slow down and they're all competing. So I like that. Not only is Docker trying to figure out how do we fit into this AI space, but also how can we make the AI world better.

And, I think you recently announced that you were a part of a new Linux foundation. What's the new AI thing called? Do you remember? AI Foundation.

In December, Docker announced joining the Agentic AI Foundation, which, I don't actually, a lot of us are like, well, what does that even mean? To me, my take on it is there is a lot of proprietary stuff happening right now. Claude Code is completely proprietary. it is definitely gathered the zeitgeist in the industry and nothing against, we all have private code.

We all have SASSes. We all have a closed source code that, that all of our machines, we're all running on machines usually with some sort of code like that. And so that's. That is fine, and I do not judge that, but historically in the world of developer tooling.

Things don't stay closed source in a large portion of the community very long, most people are on an open source IDE now, most people are running open source, you know, gone are the years of closed source programming languages, which used to be a thing, gone are the days of a lot of this base tooling we all run things on being closed source. So I am very interested in how we've got these AI companies creating a lot of closed source for competitive advantage. But also, developers will not tolerate that very long.

Like, they only, will only tolerate that as long as they have a competitive advantage over the open source. And so we have the teams like the OpenCode team and the, obviously, OpenClaw and all these other, offshoots of that, that are, I feel like, maybe, heroes may be a little bit of a strong word, but they are doing, you So, I think we're doing the good work of making sure that open source doesn't fall behind the closed source option because I think a lot of us don't necessarily want to replace all of our open source tooling with a bunch of closed source tooling.

these AIs are not as magical as we all sometimes try to put them on a pedestal. So I look at this Docker joining the, Agentic AI Foundation as, as a good thing. Basically, the Linux Foundation and the Kubernetes groups, which are part of the CNCF, which is a part of the Linux Foundation, basically drawing a line and saying, we are going to be leaders, not laggards, not followers. We're going to be leaders in the AI open source tooling space.

And there will be plenty of opportunity for vendor solutions. But not just developing with harnesses and agents, but also everything that runs AI, everything that runs our agents in the servers and production like these foundational technologies should all really be open source. So let's bring all that together under one umbrella organization so that we can do things like patent protection and, you know, guiding the working groups so that we can get all the people in the same room to make these really hard decisions.

And I'm super excited about that because for the longest time at KubeCon and these other As an industry, in the ops industry, which is what KubeCon is, that we were all focused on running the AIs. And for years now at KubeCon, it's really been about the infrastructure of running AI. And then maybe eventually started to talk about running agents, which a lot of people are still not doing. A lot of people are really just using agent harnesses locally, and they're not yet.

Actually running AI in their production with LLMs connected to it. And so I'm, encouraged that we're finally, I feel like in 2020, late 2025, early 2026. We're finally having these conversations around what does the local tooling ecosystem look like and how do we engage developers to make their life better in open source for AI? And I love that Cagent exists and that now sandboxes is going to be a thing.

Which one of that is open source? Is Cagent open source? So Cagent's open source. Yep.

and, see how anybody can try. one thing I'll add to that as well, is there's an interesting movement happening right now because, I was kind of joking with somebody a couple of days ago, like, to me, in many ways, this feels like early PHP days. And that may be a terrible, scary thing to say. one of the things that PHP did for the space was it lowered the barrier of entry for anybody to make web applications.

and so obviously that introduced a lot of security risk and vulnerabilities and like anybody could just write a website and oops, there's a SQL injection on it or whatever. in many ways, we're like in the same environment right now where like anybody can create an application now because the AI has gotten that good. but yeah, at the same time, how do we do so safely? How do we do so securely?

and in fact, I spoke at a local meetup not long ago, and there was a woman that came up to me afterwards, and this was a pretty technical meetup, and we were talking about models and, you know, the chat completions API, and it was pretty technical. And she's like, I understood maybe 10 percent of what you said. I'm just a small business owner. I want to learn how I can use AI to better my processes within my business and basically have my own little secretary.

And I think we may not be quite there yet. But we're getting pretty close to it where now she could go and say, great. I need a, I'm just going to make up something. She didn't actually say this, but like, I need an inventory management system that works for me.

and wouldn't it be great if I could somehow run this. One of the many Claws out there, and now I can just open up WhatsApp and I can text my agent and just say, Hey, how many shoes do we still have in stock yet? And then the agent can go and figure it out and give me my report back. How do we enable that kind of workflow for the everyday person?

I think we're not far from it, but it's still very technically oriented. So I think we as a technical audience need to be thinking about how do we, ' cause the technology definitely has the capability of going out to the masses, to the everyday person. how do we enable those folks? But also at the same time too, how do we ensure that the proper guardrails are in place?

And so again, that's why I'm excited that, sandboxes and all these different things that we're doing and the foundations in place, et cetera. So there's the right people thinking about these problems. So when, once we hit those levels of scale, the right eyeballs are on it. So it's an exciting time.

Yep. What a time to be alive. I'm not getting much sleep. what a time to not sleep.

well, it's great to have you on and we waited too long and now that we have so much stuff that we can't fit all into a podcast. So for those of you still listening on the audio podcast version of this edited episode later, thank you so much for sticking through it. Hopefully there's something in here for everyone. And if you're a Docker container person, which would be the reason you're listening to DevOps and Docker talk podcast, that you take a second look at some of these for how they might augment your changing workflow as you evolve into the AI harness and agents locally space, I too am also playing catch up on this.

That's why one of the reasons I had Michael on was I feel like I am not able to keep up. So, with everything the AI companies are releasing, much less adding Docker and GitHub, releasing a constant slew of things as well. there's just, we're all overwhelmed. It's very normal.

you're fine. We're all, nobody is the expert right now. Nobody knows everything. And this is the common theme I have with every release.

Whenever I talk to the smartest people in the world, I was just having a conversation with our friend Victor Farcic yesterday of DevOps Toolkit channel. like he was kept saying, Bret, not everybody knows everything right now. And we are at the tip of the spear in this, and we still can't figure all this out. there is just a lot to get through.

But it does give me the pause to go, okay, maybe There is a safer, better way that today I could start experimenting with Claude Code if I was maybe on the fence about, you know, YOLO mode. Which, to me, YOLO mode is the next unlock, really. because if I have to sit here and wait for every question and answer every question, that really hampers my AI's ability. And a year ago, that, I think, was necessary.

But I think we're now at a point where even if I don't sandbox it, like, I'll be honest, I've not had these sandboxes running for three or four months, but when I'm using Opus 4. It's not a single time tried to delete my entire hard drive. Not once, like a year ago, that was not true. It was actually trying to do wild and crazy things.

I think I remember in the spring of this year, right around the time Claude Code was released, I was trying to get it to build me in without having Xcode installed, just the CLI tools. I was trying to have it build me a iOS app, to do something and it couldn't get it built, it kept building, failing on the build and eventually decided that the. The problem was, is that things weren't installed, even though it was running those commands. So it was ready to delete the system directory of my Xcode CLI installs, because that was the problem.

And it's just not, it's a little bit smarter now. So it's not doing that to me anymore. I haven't had it try to remove or get so confused down a rabbit hole that it's ready to delete stuff. and so I think we've YOLO mode, but also at the same time, It's not perfect.

And it would be, I now realize that for me, the next. Concern is as I get back into consulting and touching production infrastructure on occasion, that I'm going to have a whole different posture for what I give my local AI, because realizing that it has access to every single CLI tool that I've already authed with is of, almost on the level of security nightmare. And I think I need a new paradigm shift in how I'm going to design my local editing and tooling To segment the human involvement and the human access from the AI access.

So it looks like Docker is going to be one of those major players that are playing in that space. And I'm excited for it because it turns out I know a little thing about Docker and I'm excited to make some videos on that. So hopefully we'll have you back on, in the future. And maybe this will inspire me to make some more Docker videos about how to use Docker with AI.

Where can people find you? you're on what? I'm on LinkedIn, probably that's going to be the easiest to get me, I'm technically on, X and BlueSky and all that kind of stuff. Probably LinkedIn is the best though.

Yeah. So yeah, follow Michael Erwin on LinkedIn. You and I will have to meet at a conference in the future and we will, we will hang out again. thanks again, Michael, All right.

Thanks Bret. Thanks all.