The Docker install is not a black box. It is a first-class coordinator runtime and single folder on your machine,
bind-mounted into a container. The image is replaceable — you swap it on
every upgrade. What is yours is the six folders and the
.env beside that compose file. Know those on day one and
nothing about the container is mysterious or opaque afterward.
What lives where — click a row
You touch three of these on day one: .env to add one key,
operator-config to become your practice instead of the
starter examples, and coo-filesystem to see the first real
file. The rest you can ignore until you need them.
Your machine (the live bundle folder)
mounted at
Inside the container
./coo-filesystem
Your artifact tree: projects, plans, drafts, work logs. Every file an agent makes for you lands here, and every harness you open later reads the same tree.
What you do with itDay one: watch the first real file land here, and open it. Week one: make a project folder for the thing you are actually working on. This is the folder to back up.
When it appears
First start copies an empty skeleton in — but only if the folder is empty. Once you have work, it is never re-seeded.
Who writes it
Operator runtime, your agents, and you. Open it in any editor; it is just files.
If you lose it
You lose the work itself. This is the folder to back up.
Two things this picture explains
Why the unzip is not the install
Every mount in the compose file is relative —
./coo-filesystem, not an absolute path. So the folder you
run compose from is your instance. Run it in Downloads and
your instance lives in Downloads.
Move the unzipped folder to where it will keep running first, then
compose there. On upgrades, copy the new image and compose file into
that same live folder. Commands stay in INSTALL.md.
Where the starter examples come from
On first start the container copies its bundled defaults into
./operator-config — one file at a time, only if missing:
That is what “the starter examples” means. They are on your
disk now. Replace their contents with your practice and your edit
persists; delete one and the starter comes back on restart.
What stays in the image
Replaceable, and not your data
Everything else ships inside the image and is swapped out whole on the
next version. None of it is where your practice lives:
Reference m2m agents, as examples you may invoke — not your fleet
Built-in coordinator skills and job instruction contracts
The bundled defaults that seeded operator-config
The empty skeleton that seeded coo-filesystem
INSTALL.md, OPERATOR_GUIDE.md, and LLM_SETUP.md
Day-one consequences
Upgrading is a swap, not a migration
New image into the same live folder. Your six folders and .env stay exactly where they were, so identity, queue, and work survive the version change. Back them up first anyway.
Your keys are not on the network
The UI publishes to loopback by default — 127.0.0.1:4040. This container holds your provider keys, so it is not on your LAN unless you deliberately change the bind.
Secrets never sit with artifacts
.env is read as environment, not mounted into the tree. Per-agent overrides go in agent-env/<agent_id>.env. Nothing an agent writes into coo-filesystem should ever contain a key.
The container is not the clock
State lives in .dal-docker, including the scheduled queue — but something on your host has to call wake for it to drain. The folder remembers; your machine decides when.
One folder, one instance, one disk you can read.
That is the whole architecture a Principal needs on day one: the image is
rented, the folder is owned. Commands and version tags come from
INSTALL.md; console and settings come from
OPERATOR_GUIDE.md; a making-surface LLM follows
LLM_SETUP.md.
.env · .dal-docker/ · coo-filesystem/ · operator-config/ · my-agents/ · my-skills/ · agent-env/Next: Your agents — what goes in my-agents/ and how COO calls it · The day — practice, spine, what to say← The kit these folders come from