Making Autonomous Work Reviewable | MarkupBase

Making Autonomous Work Reviewable

Why human-readable artifacts matter as software agents gain more freedom

A MarkupBase whitepaper<br>August 2026

Executive summary

Software agents are moving from answering questions to carrying out work. They<br>can inspect repositories, operate cloud services, update records, prepare<br>customer communications, investigate incidents, and coordinate with other<br>agents. Much of this work happens through terminals, APIs, temporary<br>environments, and tool calls that a human never sees.

That creates a visibility gap. An organisation may know what task it gave an<br>agent and what final result appeared, while having little practical insight<br>into the assumptions, intermediate decisions, evidence, or changes that<br>connected the two. Raw logs rarely solve the problem. They are designed for<br>machines and forensic investigation, not timely review by the person who<br>understands the business context.

Human review remains valuable, but only when the work is presented in a form a<br>human can actually assess. A generic approval prompt such as "Allow agent to<br>continue?" provides almost no control. The reviewer needs a stable account of<br>the proposed or completed work, the affected scope, the supporting evidence,<br>the unresolved questions, and the consequences of being wrong.

Versioned Markdown and static HTML are well suited to this role. They are<br>portable, readable, easy for agents to produce, and accessible to reviewers<br>without specialist tools. Markdown exposes the source plainly. HTML can<br>present tables, screenshots, diagrams, and structured evidence. Both can be<br>stored as immutable versions, compared over time, and discussed through<br>comments tied to exact passages.

The proposal in this paper is not to place a human approval gate in front of<br>every agent action. That would remove much of the benefit of autonomy. The<br>proposal is to create review boundaries around consequential work:

Low-risk actions can proceed within defined limits and produce a reviewable<br>record afterwards.

Material or difficult-to-reverse actions should produce a proposal before<br>execution.

Review decisions should be bound to the exact version, scope, and evidence<br>that the reviewer saw.

Comments, corrections, and unresolved concerns should survive later<br>versions.

The execution system, not the agent's prose, should enforce permissions and<br>approval requirements.

This approach turns a document into a practical control surface between people<br>and agents. It does not make an agent trustworthy by itself. It makes the<br>agent's work legible enough to challenge, correct, approve, or stop.

1. The visibility gap

Traditional software usually exposes a recognisable interface. A person fills<br>in a form, changes a setting, or follows a documented procedure. Even when<br>automation performs the underlying work, the human action and its scope are<br>usually clear.

Agents work differently. A single instruction can start a long chain of<br>activity:

read files and messages;

retrieve material from external systems;

choose tools;

form and revise a plan;

create or modify records;

ask another agent to complete a subtask;

test the result;

respond to errors;

decide that the task is complete.

The environment is often optimised for the agent. It may consist of an<br>ephemeral shell, structured API responses, hidden context, temporary<br>credentials, and thousands of log entries. A manager, compliance specialist,<br>editor, or customer support lead cannot reasonably reconstruct the work from<br>that material.

Three common substitutes for review are inadequate.

Conversation history

A chat transcript records what was said, but not necessarily what happened.<br>Important evidence may sit inside tool responses, and the transcript may<br>contain abandoned plans alongside the final approach. It is also difficult to<br>review collaboratively because comments cannot be anchored cleanly to the<br>state of the work at a particular point.

Activity logs

Logs are essential for security and incident response, but they answer narrow<br>questions: which call ran, when it ran, and whether it returned an error. They<br>usually do not explain why a particular interpretation was chosen, which<br>alternatives were rejected, or what a domain expert should inspect.

Approval prompts

An approval dialog may show a command or API call without explaining its<br>business effect. A reviewer who sees apply migration, send batch, or<br>update policy still has to discover the target, assumptions, affected users,<br>and rollback plan. Approval becomes a reflex rather than a considered<br>decision.

The missing layer is not more telemetry. It is a human-readable account of the<br>work, connected to the underlying evidence and the exact action being reviewed.

2. The review artifact

A review artifact is a durable statement of what an agent intends to do or has<br>done. It is written for a person who has relevant judgement but was not present<br>inside the agent's working...