Who decodes provider output and who writes artifacts in MCO

The MCO runtime architecture example in Archify separates provider execution, answer decoding, and result artifacts. Reading its source reveals an important ownership detail: the invocation runtime calls an adapter’s decoder and writes streamed answer text; InvocationArtifactWriter prepares answer files and writes the final result and metadata. The decoder is not the filesystem owner.

This case explains the existing MCO runtime diagram, not a newly executed agent run. Open the published diagram: MCO runtime diagram

Version boundary

The diagram’s typed source pins mco-org/mco to 9f1a1cf1afdc04d7b5406782b40dfec76d9bc798. The Archify source examined here is 04dc1916e1651086564f16076eab6d2f6ba1ae42. These are different repositories and different revisions. The findings below describe that MCO snapshot, not its current or future main branch. Pinned diagram source

Where provider output becomes answer text

In the inspected invocation path, invocation_runtime.py reads the provider’s stdout log and calls adapter.decode_transport(raw_output) when that method is available. It uses the returned deltas to obtain streamed answer text; when the provider reports SUCCEEDED, it attempts to take transport.final_answer. A decoding exception or a decoded transport status of failed can still make that invocation fail. Without a callable decoder, this path falls back to the raw output. Runtime decoder handling

answer_transport.py defines the shared AnswerTransport structure: deltas, final_answer, status, and optional usage. Its decoder functions cover plain text, JSON text events, Codex events, Pi events, and ACP updates. These functions turn provider output into a consistent representation; their existence does not imply that every provider follows an identical event format. Answer transport

Where files are actually written

The invocation runtime constructs InvocationArtifactWriter, prepares its directory, and creates an answer path for each invocation. While output arrives, the runtime itself appends decoded deltas to that answer path and flushes the file. Saying that only InvocationArtifactWriter writes answer files would miss this direct write in the runtime. Answer-file preparation · Streamed writes

InvocationArtifactWriter owns the final report-writing functions. write_run assembles result.md and calls _write_run_metadata, which writes run.json. The metadata records invocation identifiers, providers, models, statuses, exit codes, errors, output paths, and usage only when included in the invocation result. In the inspected runtime, usage is included only when include_token_usage is enabled and the decoded transport has non-null usage. It is a structured record of results, not proof that an answer is correct or that providers agree. Usage condition · Report and metadata writer

What persist_artifacts changes

For the inspected invocation runner, persist_artifacts selects a retained output directory or a TemporaryDirectory. The final write_run call is conditional on persist_artifacts. With persistence disabled, returned artifact paths are cleared, artifact_root is null, and the temporary directory is cleaned up. Persistence selection · Invocation cleanup

Persistence disabled does not mean zero disk writes. The runner still prepares temporary answer files. The multi-stage workflow also writes aggregate reports inside its selected root, which can be temporary, then clears exposed artifact paths and cleans up when persistence is disabled. The distinction is retained artifacts versus temporary working files. Workflow root · Aggregate write and cleanup

How to read the diagram’s arrow

The typed diagram connects Answer Transport to Invocation Artifacts. Read this as an architectural dataflow relationship: decoded answer content contributes to artifacts. It is not a literal function-call edge from a decoder to a file writer. The source-backed ownership description is more precise: decoding happens through the adapter interface, the invocation runtime coordinates it and appends streamed text, and the artifact writer produces report files. Runtime decoder handling Answer-file preparation · Streamed writes Usage condition · Report and metadata writer Authored diagram edge

This makes the example useful for a concrete repository review question: “Which code changes if decoded text is wrong, and which code changes if saved output is wrong?” Inspect decoder behavior for extraction errors, then inspect runtime writes, artifact serialization, and persistence settings for output-file problems. Those are starting points for investigation, not diagnoses of a reproduced defect.

What this case establishes

The existing Archify artifact makes a bounded runtime model inspectable alongside pinned source. It does not prove a production deployment, a literal chronological call stack, successful execution of a new agent task, tested exports, or a performance improvement. Its animated trace is a presentation of authored relationships, not a captured runtime trace. For installation and the general authoring workflow, use the agent guide rather than treating this case as a new setup tutorial: Agent diagramming guide