Results, artifacts, and observable state
A useful result tells you what was accomplished, where the deliverables are, and what was verified. Holon separates that user-facing delivery from the execution records that explain how the agent worked.
For example, a request to update documentation might produce an edited file, a link-check result, and a short completion report. The command output alone does not explain whether the requested documentation is complete.
Which surface answers which question?
| Surface | Use it to understand |
|---|---|
| User-facing brief or final response | The outcome, caveats, and next action for the current interaction. |
| WorkItem completion report | What was delivered and verified for a tracked objective. |
| Progress message | What the agent is doing now; it may be transient or compressed by the client. |
| Task status and output | Whether a command or delegated invocation ended, and what it returned. |
| Transcript and tool evidence | The detailed execution history needed for diagnosis or audit. |
| Artifact | The actual file, patch, image, or other deliverable. |
The final report should stand on its own. A blocker or required operator action must not appear only in an intermediate progress message. A file link helps you inspect a deliverable, but it does not replace the outcome and verification summary.
Acceptance, execution, and completion
An accepted message means the runtime received a request. A terminal execution means that execution stopped, whether successfully, unsuccessfully, or by cancellation. A completed objective means the requested outcome was checked and explicitly closed.
Consider a report-generation app. Its request may be accepted immediately; a task may later finish writing a PDF; the agent must still check the PDF and report any missing sections. The first successful receipt is not the final result.
Similarly, a final response can say that work is waiting for approval. It ends the interaction without completing the WorkItem. Use the objective's lifecycle and report to understand acceptance, not the presence of any final message.
Where artifacts live
Artifacts have concrete locations. A file created in a linked worktree belongs to that execution root, even if a file with the same name exists in the canonical checkout. A handoff should preserve the actual location.
A host filesystem path is not automatically accessible from a remote browser or another machine. A logical file route or a runtime-supplied locator may offer access through a client, subject to authentication and file access rules. It does not turn the artifact into a public download.
When publishing documentation or sharing a result outside the runtime, use portable relative references or an approved published location. Do not expose private host paths or callback capabilities merely to make a link clickable.
Reading incomplete results
Check the layer that can answer the question. If a command failed, inspect its bounded output. If the command passed but the objective is open, inspect the remaining acceptance criteria. If the agent is waiting, inspect the recorded wait and the external state it depends on.
Output can be truncated, and some runtime evidence is subject to retention. Use available artifact or source references when the exact content matters. The fact that a report exists does not guarantee every temporary file or historical log will remain available indefinitely.