Artifacts

When an agent finishes a piece of work, the result has to land somewhere durable, and that record is an artifact. Where a memory is what an agent keeps for itself, an artifact is what it produces for the workspace — a report, a draft, a generated file — saved as a first-class record that other people and agents can read, link to, and build on. Artifacts are how the output of agent work becomes part of the workspace instead of disappearing into a task timeline.

An artifact is a versioned workspace record

An artifact is a stable record that lives at a path in the workspace and holds either markdown or a reference to a stored file. The record's identity never changes, but its content is kept as a series of immutable versions: editing an artifact does not overwrite it, it appends a new version that links back to the one before. That stable identity is what other records point at when they reference the artifact, so a link stays valid no matter how many times the content is revised, and the full history stays readable.

Artifacts share their hierarchy and visibility with documents. Both live on content paths — folder-like paths that carry permissions — so where an artifact sits decides who can see it. The difference is in authorship: documents are the knowledge people write and curate, while artifacts are the records agents and workflows generate as a by-product of doing work.

A folder can be archived and recovered

Knowledge accumulates, and not all of it stays relevant, so a folder can be archived to take it out of the way without deleting anything. Archiving a folder hides it and everything nested under it — its sub-folders, documents, and artifacts — from the drives, the pickers that insert references, and search, and it also keeps that content out of the relevant-knowledge context an agent reads when it starts a job. An archived branch is dormant, not gone: nothing is destroyed, and the content stays exactly as it was.

Recovery is the exact reverse. You browse archived folders from the same drive, recover one, and it returns to the drives, pickers, search, and agent context with its contents intact. Archiving works on the folder alone — nested items are hidden because their folder is, not because each was marked — so anything you had already archived on its own before stays archived after you recover the folder, and recovery never disturbs the state you set underneath. This is how you retire a body of knowledge cleanly and bring it back unchanged if the work returns.

Artifacts carry their provenance

Because an artifact is produced by work, it records where it came from. When an agent creates an artifact from a task, Task Machine links the artifact to that task and to the runtime job that produced it, and the creating agent is always recorded as its author. An artifact created from a task also inherits that task's project scope, so it stays with the project it belongs to and does not leak into unrelated work. The result is that an artifact answers, on its own, which agent made it, in service of which task, on which run — without you reconstructing that from a timeline.

This provenance is also why artifacts surface where the work is. An artifact appears in the timeline of the task it came from, in the details of the workflow run that generated it, and in the related records of anything that links to it, always filtered to what the current member is allowed to see.

Agents write artifacts; people edit them as documents

Artifacts are agent-authored by design, and the editing model reflects that. An agent creates an artifact and appends new versions to it as work progresses. When a person wants to take an artifact and make it durable, curated knowledge, the move is not to edit the artifact in place but to duplicate it into a document: Task Machine copies the current content into a new document on the same path, preserves the project scope, and links the document back to the source artifact. The artifact stays as the agent's record of what it produced, and the document becomes the human-owned version that can be edited freely.

From the machine where an agent runs, the tama CLI is how an agent reads and writes artifacts as it works — tama artifacts list, search, and show to find existing ones, and tama artifacts create and update to produce new artifacts and append versions. Documents are read-only from the CLI, since agents produce artifacts and read documents rather than the reverse. The full command set is in the CLI command reference.

From here, artifacts are the records agents leave behind; the last piece is how those records connect to everything else. See References for the links that tie documents, artifacts, tasks, goals, and members together.