Your agent spent twenty minutes on a revenue report. It wrote the file, told you the path, and you moved on. A few hours later the machine suspended on its idle timer, and the download button stopped working.

That's not a bug in one product. It's the default shape of agent infrastructure: output lives on the computer that made it, and that computer is designed to go away.

From September 4 an agent can mark something as yours. It gets a permanent home, a name, and a URL that keeps working when every machine you own is asleep.

The Octomind Artifacts screen: four kept files — Onboarding funnel chart, Service dependency map, Churn by cohort, Q3 revenue report — each with filename, size and age, a Public link badge on one, Copy link and Delete actions, and 438 KB shown against the plan's 2 GB allowance

Two failures, not one

The agent had no way to say which file mattered. The symptom is the download that 404s.

Ours guessed. It scraped file paths out of the model's own prose and rendered whatever looked like a filename as a download chip. The code said so plainly in a comment: "a missed path costs one manual download; a false positive renders a dead chip." That's an honest trade for a heuristic, and it's the wrong mechanism for "here is the thing you asked me to make".

So there are two problems: deliverables don't survive, and nothing distinguishes a deliverable from a temp file.

One tool, and the restraint is the hard part

The agent gets one tool: artifact. Publish a path with a title. That's it — it doesn't choose where the file goes, what it's called on disk, or what type it is.

The interesting engineering isn't in the capability. It's in stopping the agent from using it. The failure mode of "you can keep files" is an agent that keeps its node_modules, on storage the user pays for. So the tool description teaches restraint before capability, and ends:

If you are unsure whether something is a deliverable, it is not — mention the path in your reply and let the user ask.

Three tiers, and only the third is new: scratch on the working disk (the default, and it must stay the default), durable state like memory and indexes, and artifacts — the short list of things a human actually asked for.

Moved, not copied

Publishing moves the file. Copy, verify the hash matches, then unlink the original.

Leaving both would bill the same bytes twice — once on the machine's working disk, once in shared storage — for a duplicate nobody asked for. There is no keep-the-original flag, because a knob there is just a way to get double-billed by accident. Nothing is lost: the file stays readable in the machine at its new path, and the tool result points to the shared directory where it now lives.

Why it survives, exactly

Artifacts land in the account's shared directory, which is already mounted inside every machine as ~/.local/share. So a publish is a move the machine performs on itself — no bytes cross the control plane.

The reading half is the part that matters. The shared directory lives on storage nodes and, in our own architecture docs, "never moves" — not when a machine stops, not when it's archived, not when it's deleted. The control plane mounts it read-only and streams downloads straight off it.

No machine is involved in a download. That's the whole feature. Everything in the screenshot above was fetched with the machine that produced it suspended.

Storage billing needed no new code: the hourly sweep already counts every byte in that directory, so an artifact is charged the moment it lands, at the same $0.10/GB-month as everything else.

The explorer finally works when it's most needed

The file browser had the same problem — it talked to a container, so it was empty exactly when you wanted it. It now has two roots in one row, and Shared opens first because it always works.

The Octomind file explorer with Shared storage selected and Machine disk beside it, showing artifacts, octobrain and octomind folders with timestamps, and the note "Kept between machines — readable while they sleep"

Same browser, one extra root. Not a second screen.

Three decisions we'd defend

Bytes never come from the API origin. An artifact can be agent-authored HTML or SVG. Serving that next to a logged-in panel session is stored XSS with a product roadmap. Artifacts are served from the user-content domain that already isolates public endpoints — and even there, only inert types render inline; everything else downloads.

A private link is signed and expires in an hour. Public means public; private means a link you can't forward tomorrow.

Public downloads are metered. Our egress meter works by sampling running containers' counters, so it is structurally blind to a file the control plane serves itself. Left alone, a public artifact link would be free unlimited file hosting on our bandwidth. Those bytes now go into the same 1 TB monthly allowance at the same $0.01/GB overage — one egress number, no new line item.

What we're telling you up front

On the free plan, an idle workspace is reclaimed after 7 days — artifacts included. That's stated on the screen, in the product, before you rely on it. Paid plans keep everything until you delete it.

And deleting really deletes: publishing moved the file, so there is no copy left on the machine. The confirmation says so.

Try it

Ask for something and then ask to keep it: "write up the Q3 numbers and keep the report for me." Then suspend the machine and download it anyway.

Available on every plan. Machines pick up the tool on their next restart.