Docker has introduced Gordon, an AI agent built into Docker Desktop 4.74+ and the Docker CLI. The pitch is narrow and important: Gordon is not meant to write application code. It is meant to inspect the Docker environment around that code, diagnose container problems, propose changes, and run approved actions.
That distinction matters. Most developer AI tools work from pasted context or files opened in an editor. Docker says Gordon can read running container logs, images, Compose files, the working directory, and Docker resources such as containers, volumes, and networks. Under the hood, Docker describes it as having shell access, filesystem operations, the full Docker CLI, Docker documentation and best-practice knowledge, and web access.
That makes Gordon more operationally useful than a generic chatbot for container work. It also makes the trust boundary sharper.
What Docker says Gordon can do#
Docker frames Gordon around the messy part of development that starts after code exists: builds that fail, containers that exit, services that cannot talk to each other, Dockerfiles that rebuild too often, and local stacks that nobody has documented well.
The examples in Docker’s post are practical rather than exotic. A developer can ask why a container keeps exiting. Gordon can read logs, trace the issue to a likely cause such as a missing environment variable, a bad base image, or a misconfigured volume mount, then propose a fix. The user must approve before the agent applies it.
For a new service, Docker says Gordon can read the project, draft a Dockerfile, generate a Compose setup with something like Postgres, run the stack, and show the result. For routine work, it can clean unused images, stop running containers, show disk usage, list running containers, or pull and run an image without the user remembering the exact flags.
Docker also highlights Dockerfile optimization. Gordon may propose a multi-stage build, reorder layers for better cache behavior, suggest a slimmer base image, or add a health check. The useful part here is not that an LLM can describe a multi-stage build. Many can. The useful part is that the agent is supposed to make suggestions against the project and Docker state it can actually inspect.
The real product claim is context#
The strongest claim in Docker’s announcement is not “AI for containers.” That phrase is too broad to mean much. The real claim is that Gordon starts with local Docker context.
That is where generic assistants often fail. Cursor, Copilot, Claude Code, and similar tools can help with source code, but they usually do not know what is running, what failed, what the logs say, which Compose file is active, what images exist locally, or how the current Docker environment is wired. They can reason from text you provide. They do not automatically own the operational view.
Docker is trying to close that gap from the platform side. Gordon lives inside Docker Desktop and the CLI. In Docker Desktop, it has its own tab and can be launched from areas where Docker surfaces resources or problems, such as containers, images, volumes, builds, and search. The intended workflow is direct: see a failing container, open Gordon from that context, ask it to diagnose, review the proposed action, approve or reject.
That could remove a lot of low-value work. Container debugging often burns time not because the issue is hard, but because the context is scattered: logs in one place, Compose in another, Dockerfile in a third, environment variables somewhere else, and a stale answer from the web confusing the trail. If Gordon can keep those pieces in one reasoning loop, it can be useful even when its final fix is ordinary.
Approval is the key safety detail, but not the whole story#
Docker says every Gordon action requires explicit approval, and permissions reset when the session closes. That is the right default. An agent with shell access, filesystem operations, web access, and Docker CLI control should not be treated like an autocomplete box.
Still, approval prompts are not magic. They reduce risk only if the proposed action is understandable and scoped. A command that removes unused images is easy to review. A multi-file edit, a shell command with side effects, or a Compose change that touches networking and volumes deserves more attention.
The practical trust model is simple: Gordon may be helpful because it can see and act. That is also why users should review what it wants to do. Docker’s post does not present Gordon as an autonomous background operator; it presents it as an agent that waits for approval. Teams should hold it to that boundary.
There is also a data-sensitivity question. Docker says Gordon can read logs, files, and environment context. Logs and local configuration can contain tokens, internal hostnames, customer data, and secrets accidentally printed by applications. The source post emphasizes capability and approval, but readers should still check Docker’s current product documentation and account settings before using Gordon on sensitive projects.
Where Gordon may help first#
The best early use cases are the ones with clear local state and reversible actions.
- Diagnosing why a local container exits.
- Explaining a Compose network problem in the current project.
- Finding Docker disk usage and stale resources.
- Drafting a first Dockerfile or Compose file for a service.
- Reviewing a Dockerfile for obvious size and cache problems.
- Translating Docker concepts against the user’s actual setup, such as bind mounts versus named volumes.
These are high-friction, low-glory tasks. They are also common. If Gordon handles them well, it does not need to be spectacular to be useful.
The weaker area is anything that depends on unstated production assumptions. A local Compose stack is not the same as production networking. A smaller base image is not automatically the right base image. A health check can be syntactically correct and operationally wrong. Gordon can propose; the developer still owns the deployment judgment.
What not to overclaim#
Docker’s announcement is a product launch post, not an independent benchmark. It describes intended behavior and examples. It does not prove reliability across languages, frameworks, messy enterprise environments, or security-sensitive workflows. It also does not establish that Gordon can replace container knowledge. The better expectation is narrower: it may reduce lookup time and context gathering inside Docker workflows.
The “20 minutes to two” framing in the source should be read as illustrative product positioning, not a measured guarantee. The same applies to broad statements about tracing failures and applying fixes. Some failures are obvious once logs and Compose files are visible. Others involve application bugs, race conditions, credentials, cloud networking, CI differences, or images built in ways local Docker cannot fully explain.
That does not make the product unimportant. It makes the evaluation concrete. Gordon should be judged by whether it sees the right local facts, proposes small reviewable changes, explains why, and avoids confident edits when the evidence is thin.
What to check before using it on real projects#
Developers trying Gordon should start with non-sensitive local projects and watch the approval path closely. The first question is not whether the answer sounds smart. It is whether Gordon cites or uses the actual Docker state correctly.
Check what it read. Check the commands it proposes. Check file diffs before approving. Be careful with cleanup commands, volume changes, network changes, and anything that might remove state. If logs or environment files may contain secrets, review Docker’s current privacy and product controls before handing the agent broad context.
Gordon is interesting because Docker owns the surface where container friction happens. If the integration works, it can turn Docker Desktop and the CLI from control panels into active debugging interfaces. That is a real shift. But the old rule still applies: the closer an AI agent gets to the shell, the more the human approval step matters.