Artifacts

Coordination lets several agents contribute to a task, each with its own context and a bounded run. Their work needs to survive those runs and become available to the next participant. An artifact is an object produced by work and saved for later use. Documents, source files, datasets, and task records give the system something to inspect, extend, and use after the agents that created them have stopped.

Research notes can supply evidence for a draft; the draft can receive a review; the review can guide a revision. Each contribution leaves material for the next step. An agent reads the parts relevant to its assignment and saves its contribution in the shared workspace. A path or identifier connects the assignment to the work, while a revision identifies the version examined. The project can grow beyond any one context without requiring every participant to reconstruct every preceding investigation.

Persistence gives these contributions a place to accumulate. Their organization determines how another agent can participate. A task record can identify the result still needed, its current owner, and whether it is ready for review. Instructions and operations associated with that record explain how to claim the task, contribute a result, and submit it for review. The environment can therefore preserve both the work and a protocol for continuing it.

Types and protocols

An artifact type describes a kind of work object and the interactions it supports. A document has sections that can be edited; a dataset has records that can be queried; a task has an assignment and a state that can change. The type determines which parts of the work are identifiable and which operations make sense. Its interface exposes those parts and operations to people, agents, and other software.

A protocol describes how participants use that interface over time. A research task might move from ready to working when a worker claims it, then to in review when the worker submits findings and evidence. A reviewer can accept the result or request changes. The task's current state tells each participant which contribution is needed next. The model still decides how to investigate the question or judge the evidence, while the shared protocol supplies the procedure for handing work on.

This moves recurring instructions and bookkeeping into the environment. A parent agent does not need to repeat the review procedure for every assignment if the worker can find it through the task's interface. Some protocols are conventions that people and models interpret; others have operations that check conditions and update related state. A Markdown instruction can describe who should claim work. An implemented claim operation can also prevent two workers from acquiring the same task. The design must distinguish the guidance participants read from the rules software enforces.

Artifact storage

A filesystem can express an artifact type through folders, document templates, and shared instructions. Task files can link to findings under results/, evidence under sources/, and reviews under reviews/. A WORKFLOW.md file can describe the allowed status changes and what each contribution must contain. The example task points to that protocol; all paths are relative to the workspace root. The model interprets these conventions when it reads and edits the files, using search, diffs, and version control to inspect the work.

# tasks/T-17.md
Question: Has product B shipped?
Protocol: WORKFLOW.md
Status: in_review
Owner: worker-3
Candidate: results/T-17-v2.md
Evidence: sources/release-notes.md
Review: reviews/T-17-v2.md

# WORKFLOW.md
Submit findings with their evidence and a versioned candidate.
Review the linked candidate and record acceptance or requested changes.
A revised candidate needs a new review.
Mark the task complete only after acceptance.

A Notion workspace can express the same design with task pages, status and owner properties, links to results, and relations to sources. A filtered view can expose tasks awaiting review, while a workflow page explains the review procedure. The saved properties and instructions make the work understandable to people and agents using the workspace. Additional tool handlers or automation can implement checks that ordinary page edits would leave to the participants.

Database tables can represent those tasks, results, and sources as rows with identifiers and relationships. Queries select eligible work, and application operations perform the required updates. A filesystem, a Notion workspace, and a database can all support the same protocol; the choice depends on how participants discover, inspect, and change the work. The representation needs enough structure for those operations, and its interface must make that structure accessible to the agent.

Coordination through artifacts

Shared state can carry part of the coordination that a parent would otherwise direct. A worker discovers a ready task, claims it, and later submits a candidate result. A reviewer discovers that candidate through the task's new state. The participants need a way to discover changes, such as a query or notification, but each handoff can refer to the stored task and its protocol. The parent's remaining work can focus on priorities, difficult dependencies, and results that need interpretation.

An operation turns a protocol step into code. A task may have been claimed since a worker read the ready list, so the claim operation must check that it is still available when recording ownership. The illustrative handler below uses a conditional update that checks the status and revision and records ownership in one indivisible storage operation. The revision comes from the selected task, and the worker identity comes from the runtime. A successful claim establishes ownership; the investigation and its review still remain.

// Application interface backed by an atomic conditional update.
async function claimTask(candidate, run) {
  const claimed = await taskStore.updateWhere({
    id: candidate.id,
    status: "ready",
    revision: candidate.revision,
  }, {
    status: "working",
    owner: run.workerId,
    revision: candidate.revision + 1,
  })

  return claimed
    ? { status: "claimed", task: claimed }
    : { status: "conflict" }
}
// After a conflict, refresh the available work before choosing again.
// Additional prerequisites need checks under the same protection.

Operations can also maintain relationships that would otherwise require several coordinated edits. If a reviewed claim changes, reviseClaim can save the new content, advance the revision, and mark the previous review as outdated together. The model proposes the revised claim; the handler updates its revision and review status. The review remains a record of the version it examined, while the new version needs its own assessment. Whether the revised claim is true still requires evidence and judgment.

External computation

An artifact can also be input to a computation. A source file can be compiled or executed; a spreadsheet can recalculate formulas; a dataset can support a query. The file or object has meaning to the software that operates on it. By creating and changing these artifacts, an agent can arrange computations whose intermediate steps never need to pass through a model's context.

An agent can analyze a saved dataset by writing a program. The model produces a program, a tool writes it into the workspace, and a runtime executes it against the data. The runtime returns a result or an error that the agent can inspect. The following application interfaces save that outcome before selecting an observation for the next call. A large result can remain in storage while the model receives the rows or error details relevant to its next decision.

// Illustrative workspace and execution interfaces.
await workspace.write("analysis.py", program)
const outcome = await runtime.execute({
  program: "analysis.py",
  input: "data.csv",
})

const saved = await workspace.saveOutcome(outcome)
return {
  status: outcome.status,
  artifact: saved.path,
  observation: selectObservation(outcome, question),
}

The same arrangement supports iterative work. An error can guide an edit to the saved program; a query result can motivate another query; a rendered page can reveal a layout problem. Programs, data, and outputs accumulate in the workspace while each model call receives a selected view. The environment performs the execution, calculation, or rendering, and the agent interprets the result to choose what to do next.

Concurrent edits

Several agents can follow a protocol and still interfere with each other's work. Two writers may read revision 12 of a document, make different corrections, and each save a replacement. The later write can erase the earlier correction. A written instruction to respect ownership helps participants cooperate, but the storage operations determine whether conflicting updates can actually occur.

A single writer can integrate contributions from separate result files or proposed patches. Multiple writers can instead use version-checked updates: accept a change only if the revision it was based on is still current. The comparison and write must happen atomically, just as the task claim checks availability and records ownership together. Checking a revision and saving in separate unprotected steps leaves room for another writer to intervene.

A conflict gives the agent new information. The agent can read the current version, inspect the other contribution, and decide how to revise its proposal. Independent comments may both survive, while contradictory changes to a conclusion require a substantive decision. The environment can detect a stale update and preserve earlier work; the model or another participant still has to resolve what the combined result should mean.

Continuity across runs

Persistent work lets a later run continue without depending on the previous worker remaining active. The new run reads the task, its protocol, and the relevant artifacts to establish what has been saved and what remains to be done. A conversation that says a citation was corrected is an account of an action; the current document shows whether the correction is present. If an operation's outcome is unknown, the next run may need to check what actually changed before trying again.

The same object can serve several purposes over time. A document is a work product when edited, evidence when reviewed, and memory when retrieved for a later task. Its identity and history connect those uses. Saved content, task state, and the protocol together give a new participant a basis for continuing the work with a fresh context.

Artifacts let work and its procedures outlive individual agent runs. Their interfaces make contributions discoverable, provide operations for changing shared state, and connect the system to external computation. A stored task still needs a running participant to act on it. The next chapter asks what starts those later runs and how they resume a continuing purpose.