Introduction
Over the past few weeks, I’ve been working on a major shift in how we manage Docker Compose inside the agent application. Previously, we were carefully curating every input and output to/from the LLM, tightly controlling what it could do because we had seen how easily things could break when we let it act too freely.
But now, we’ve reached the point where the agent itself can take agency over Docker Compose.
We’re introducing a set of tools that allow the agent to read, diagnose, modify, and regenerate Docker Compose files in the context of that the application needs based on the code base. And importantly — it can do this automatically in the background.
How it works
To show how this works, I intentionally broke a Docker Compose file. The services were still running fine, which is usually what makes these issues painful — everything appears healthy until the next restart. The agent reviewed the YAML config on disk, and the YAML config that was actually running, compared it to the running configuration, detected the subtle differences, and fixed them. It corrected things like an invalid Dockerfile path and Dockerfile name and even a tiny typo (alpine → alpane) — exactly the kind of issue that would otherwise drain time and patience.

Once it performed the fix, the agent spun down the environment, rebuilt it, brought it back up, confirmed all containers were healthy, and summarized what it changed, all on its own.
In this instance, where a change was made, the entire process took about 53 seconds, most of which was just waiting for Docker to shut down and start back up. For processes requiring no change, it takes between 0 - 10 seconds. And because the agent does this immediately when indexing completes, the environment is typically ready before you even try to hit an endpoint. No more “why isn’t Docker Compose working” moments. No need to manually debug or restart containers.
If everything is already correct, the agent simply reassures you:
“Configuration is already running and matches the requirements.”
That’s exactly what you want to see.
Why This Matters
This removes one of the most consistent friction points for users:
- Setting up Docker Compose
- Debugging subtle configuration drift
- Restarting environments after small changes
- Re-syncing what’s on disk vs what’s actually running
The agent now handles that.
Quietly. Reliably. Automatically.
And this is just the start. SQL setups and scenario environments will be getting this same treatment next. Once that’s in place, the only time you’ll need to step in is when something is genuinely impossible to resolve, not when the environment is just misaligned or out of sync.
The goal is simple:
Reduce the time teams spend fighting dev environments to zero.
And with this update, we’re getting very close.
