Docker Agent

You will like this if you have ever abandoned an agent project at the boilerplate stage. The trait that decides it day to day is that a working agent is a short file: model, instruction, toolsets, and it runs. Teams of agents delegate to each other automatically rather than through orchestration code you write and then maintain, which is the part that usually kills these side projects before they are useful.

Pick it when you want something running this afternoon. Pick the OpenAI Agents SDK once you need real control flow, or Mastra if you would rather live in TypeScript from the start.

The gap is between brand and behaviour. Tool servers can be run as containers, and the row records that the shell tool executes arbitrary commands in the user's environment instead. Nobody reads that sentence before granting a toolset. Combine it with automatic delegation between agents and the command that ends up running was chosen by a component two hops from the file you wrote.

What it does right: the tool surface is declared in the same file as the agent, so what an agent may reach is reviewable in a diff rather than discovered in a log.

The notable decision is packaging. 1. An agent definition is stored and retrieved through any OCI registry, which means immutable tags, content addressing and the mirroring infrastructure organisations already operate, none of it built for this purpose. 2. Structured tools for memory, retrieval and language-server queries are provided rather than improvised per project, so capability is declared instead of prompted.

The design should survive model turnover, because the file names a provider and nothing in the packaging depends on which one. No evaluation is published, which is appropriate for a substrate rather than an agent.

The distribution is the strategy. A permissive licence and no price mean the revenue question is answered elsewhere, on Desktop seats and registry plans, and pre-installing an agent runtime in a product on millions of machines is the cheapest customer acquisition in this category. Renaming it from the original project name suggests the parent is consolidating it into the brand rather than treating it as an experiment.

Risk is strategic drift, not insolvency. No acquirer is relevant; Docker is the acquirer in this story. Position: adopt without commercial concern, and expect features to follow Desktop's roadmap.

This is the easy kind of adoption. Sixty engineers already have the parent product on their machines, so there is no new vendor, no new invoice and no new questionnaire for the tool itself. It exposes a documented API server with streaming and a session database, which means our pipelines can call it like any other service and keep a record of what ran. Model spend lands on keys we already issue.

The row records no identity features of its own, so authentication is whatever we put in front of it. Approved with conditions: server mode behind our gateway, and the shell toolset off by default.

Apache-2.0 and installable with brew if I would rather not run the desktop product. The configuration is the whole product: a declarative file that lives in my repository, travels in version control, and takes any MCP server I point at it, whether that server runs locally, over the network or in a container. Sixteen providers are listed and one of them is a local model runner, so inference can stay on my machine.

A fork is realistic and probably unnecessary given who maintains it. This is the first vendor runtime I would put in a dotfiles repository.