FlowDrop Workflow Specification 1.0-draft

A turn's artifacts are persisted on its message and reported on its result

The rule

Normative: this is the rule
  1. The artifacts a run collected are persisted on the last assistant message that run wrote, once per run.
  2. A turn's result aggregates the persisted artifacts of every assistant message in the turn, so they survive a reload, and the turn API reports the same list.
  3. On the wire a message carries them as a top-level toolArtifacts field rather than as raw message metadata.

What it means

Artifacts are not a run-scoped, in-memory extra that a reload would lose: they land on the assistant message itself, so reading the turn back later still returns them. A caller reading the wire form never sees the storage key they were kept under — they arrive as their own top-level field, not nested inside the message's general metadata, so a client does not have to know the internal name to find them.

Example

An artifact a tool call produced during the turnproduced
{ "type": "link", "payload": { "url": "https://example.com/report" }, "tool_call_id": "call_1" }
The assistant message as the door reports itreported
{
  "toolArtifacts": [
    { "type": "link", "payload": { "url": "https://example.com/report" }, "tool_call_id": "call_1" }
  ],
  "metadata": {}
}

The message's metadata never carries the artifacts under their storage key — a client that only reads toolArtifacts sees everything there is to see.

Rule identifiers are permanent and are never renumbered. Each implementation publishes its own standing against these rules; this specification does not.spec 1.0-draft · RT-TOOL-4 · changed in spec 1.0