# Making Autonomous Work Reviewable ## Why human-readable artifacts matter as software agents gain more freedom Author: Jason Doyle Originally published on [MarkupBase](https://markupbase.com/whitepapers/making-autonomous-work-reviewable/) August 2026 > Disclosure: These views are my own and do not represent my current or any former employers. ## Executive summary Software agents are moving from answering questions to carrying out work. They can inspect repositories, operate cloud services, update records, prepare customer communications, investigate incidents, and coordinate with other agents. Much of this work happens through terminals, APIs, temporary environments, and tool calls that a human never sees. That creates a visibility gap. An organisation may know what task it gave an agent and what final result appeared, while having little practical insight into the assumptions, intermediate decisions, evidence, or changes that connected the two. Raw logs rarely solve the problem. They are designed for machines and forensic investigation, not timely review by the person who understands the business context. Human review remains valuable, but only when the work is presented in a form a human can actually assess. A generic approval prompt such as "Allow agent to continue?" provides almost no control. The reviewer needs a stable account of the proposed or completed work, the affected scope, the supporting evidence, the unresolved questions, and the consequences of being wrong. Versioned Markdown and static HTML are well suited to this role. They are portable, readable, easy for agents to produce, and accessible to reviewers without specialist tools. Markdown exposes the source plainly. HTML can present tables, screenshots, diagrams, and structured evidence. Both can be stored as immutable versions, compared over time, and discussed through comments tied to exact passages. The proposal in this paper is not to place a human approval gate in front of every agent action. That would remove much of the benefit of autonomy. The proposal is to create review boundaries around consequential work: 1. Low-risk actions can proceed within defined limits and produce a reviewable record afterwards. 2. Material or difficult-to-reverse actions should produce a proposal before execution. 3. Review decisions should be bound to the exact version, scope, and evidence that the reviewer saw. 4. Comments, corrections, and unresolved concerns should survive later versions. 5. The execution system, not the agent's prose, should enforce permissions and approval requirements. This approach turns a document into a practical control surface between people and agents. It does not make an agent trustworthy by itself. It makes the 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 in a form, changes a setting, or follows a documented procedure. Even when automation performs the underlying work, the human action and its scope are usually clear. Agents work differently. A single instruction can start a long chain of 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 ephemeral shell, structured API responses, hidden context, temporary credentials, and thousands of log entries. A manager, compliance specialist, editor, or customer support lead cannot reasonably reconstruct the work from that material. Three common substitutes for review are inadequate. ### Conversation history A chat transcript records what was said, but not necessarily what happened. Important evidence may sit inside tool responses, and the transcript may contain abandoned plans alongside the final approach. It is also difficult to review collaboratively because comments cannot be anchored cleanly to the state of the work at a particular point. ### Activity logs Logs are essential for security and incident response, but they answer narrow questions: which call ran, when it ran, and whether it returned an error. They usually do not explain why a particular interpretation was chosen, which 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 business effect. A reviewer who sees `apply migration`, `send batch`, or `update policy` still has to discover the target, assumptions, affected users, and rollback plan. Approval becomes a reflex rather than a considered decision. The missing layer is not more telemetry. It is a human-readable account of the 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 done. It is written for a person who has relevant judgement but was not present inside the agent's working environment. It is not a transcript and it is not a polished success summary. A useful artifact exposes uncertainty and makes disagreement possible. It is a checkpoint, not a diary. At minimum, it should answer these questions: | Review question | Required information | | --- | --- | | What was requested? | The task, requester, objective, and success criteria | | What is in scope? | Systems, records, users, environments, dates, and explicit exclusions | | What changed or will change? | A concrete list or diff, not a broad claim | | Why was this approach chosen? | Material assumptions, constraints, and rejected alternatives | | What supports the conclusion? | Source references, test results, screenshots, record identifiers, and tool receipts | | What could go wrong? | Known uncertainty, side effects, dependencies, and failure modes | | Can it be reversed? | Rollback method, recovery point, and any irreversible step | | What needs human judgement? | Specific questions for the assigned reviewer | | Which work is being approved? | Agent identity, artifact version, action identifier, and expiry | The level of detail should match the risk. A routine read-only inventory might need a short report. A production migration, regulatory interpretation, or bulk customer communication needs a fuller proposal and stronger evidence. The artifact sits between two technical layers: 1. The execution layer contains tools, credentials, sandboxes, APIs, and policy enforcement. 2. The evidence layer contains logs, source records, test output, and action receipts. The review artifact does not replace either layer. It gives a human a coherent route through them. ## 3. Why Markdown and HTML The review layer should not depend on the agent vendor or the tool that carried out the work. Markdown and HTML have several practical advantages. ### They are easy to produce and inspect Markdown sits within the working vocabulary of nearly every general-purpose model. The source remains readable even when rendering is unavailable. A reviewer can copy it, search it, compare it, or archive it without a proprietary editor. HTML supports richer evidence where plain text becomes cumbersome. Tables can show affected records. Images can capture visual differences. A static diagram can explain a workflow. Clear typography helps non-technical reviewers follow complex material. ### They separate work from conversation A document gives the task a stable review state. Conversation can continue without changing the material under review. If the agent responds to comments, it publishes another version rather than silently replacing the original. ### They support precise discussion Comments can attach to a sentence, table row, heading, or selected passage. This is more useful than a general message saying "please check the risk section". When a new version appears, resolved and unresolved threads can remain part of the record. ### They are portable The same artifact can be opened in a browser, stored in object storage, attached to a ticket, exported as source, or retained for an audit. It is not tied to the lifetime of an agent session. ### They can be made safe Review HTML should be static and sanitised. Scripts, active embeds, external resource loading, unsafe styling, and hidden content can turn the review document into another attack surface. A safe renderer should preserve useful formatting while blocking executable behaviour and misleading presentation. Markdown and HTML are not valuable because they are sophisticated. They are valuable because they are ordinary. They create a shared format between a machine that can generate structured work and a person who needs to judge it. ## 4. Where review belongs Not every workflow needs the same review point. ### Proposal before action The agent researches and plans, then publishes a proposal. Execution waits for approval of that exact version. This pattern fits destructive changes, financial actions, policy decisions, public statements, and work with legal or regulatory consequences. ### Record after action The agent acts within a narrow, reversible permission boundary and immediately publishes what changed, what evidence was collected, and whether anything unexpected occurred. This pattern preserves speed for incident triage, routine maintenance, and bounded operational work. ### Review by exception The agent handles ordinary cases automatically and publishes only exceptions, low-confidence decisions, policy conflicts, or activity outside a normal range. This is often more sustainable than asking people to approve a high volume of routine actions. ### Periodic review Low-risk work can be grouped into a daily or weekly artifact. A reviewer looks for drift, repeated errors, unusual tool use, and changes in the type of work the agent is performing. These patterns can coexist. An incident agent might isolate a compromised credential immediately, request approval before deleting a customer resource, and publish a complete incident report afterwards. ## 5. Anonymised case studies The following case studies are composites based on recurring operational patterns and documented incidents. Names, sectors, quantities, and chronology have been changed to protect organisations and individuals. They illustrate control problems, not allegations about a particular unnamed business. ### Case study 1: A production release A software company allowed a release agent to prepare and deploy routine application updates. The agent could inspect repositories, run tests, create deployment packages, and operate the cloud deployment service. For a material database change, policy required the agent to publish a Markdown release proposal before execution. The document listed the affected services, migration steps, test results, deployment order, expected downtime, and rollback procedure. It also included the schema diff and the identifier of the backup recovery point. The proposal described the migration as reversible. A database engineer commented on the exact sentence and pointed out that the rollback depended on a column the migration planned to remove. The tests had passed because they used a newly created database rather than data shaped by older customer accounts. The agent revised the plan. The destructive step was separated into a later release, the old column was retained temporarily, and a test using a restored production-shaped dataset was added. A new artifact version was published, and the original comment remained visible as part of the decision history. The human did not review every command. The valuable contribution was context: knowledge of how old accounts differed from the clean test environment. The artifact placed that knowledge at the point where it could still change the outcome. ### Case study 2: Financial reconciliation An operations team used an agent to match invoices, payments, credits, and refunds across an internal ledger and a payment provider. Exact matches were low risk and could be closed automatically. Exceptions were published as a static HTML report. The report grouped cases by reason and showed source identifiers, currencies, dates, amounts, and the proposed adjustment. It did not expose customer names or full payment details. A finance reviewer noticed that several refunds had been classified as chargebacks. The provider used a similar event code for both, but the accounting treatment and customer balance effect were different. The agent had followed the API description correctly and still reached the wrong business conclusion. The reviewer commented on one table row and applied the comment to the group. The agent republished the report with the corrected classification, added the provider's settlement field as supporting evidence, and left the uncertain cases open. Without the artifact, the team could have inspected event logs after balances were wrong. With it, a domain specialist could review the small number of decisions where semantic context mattered. ### Case study 3: A policy update A regulated service provider asked an agent to analyse a new regulatory notice and prepare changes to an internal policy, customer guidance, and staff instructions. The agent published a Markdown package containing the source references, a plain-language interpretation, a line-by-line policy diff, and three questions where the notice was ambiguous. A compliance reviewer found that the draft had removed an existing exception for vulnerable customers. The new notice did not prohibit the exception, but the agent had treated silence as replacement. A second reviewer found that a customer-facing sentence sounded like a guarantee rather than a description of the normal process. Both comments were resolved in a new version. The final approval was tied to the revised source, not to a generic conversation or an earlier draft. The agent shortened the research and drafting cycle. The reviewers supplied interpretive judgement and accepted responsibility for the wording that would govern real cases. ### Case study 4: Incident containment An online service gave a security agent authority to perform a limited set of emergency actions. It could disable exposed credentials, block a malicious address, and isolate a workload without waiting for approval. It could not delete data, change account ownership, or widen its own permissions. After detecting a leaked credential, the agent revoked it and published an HTML incident artifact within minutes. The report identified the affected resource, the evidence that triggered containment, the exact actions taken, services that failed health checks afterwards, and the remaining credentials that shared the same trust path. The on-call engineer saw that a legacy integration was not included in the rotation list. It had not appeared in the current service catalogue, but it still used the revoked identity. The engineer added a comment, assigned the follow-up, and kept the incident open until a new report showed that the integration had been migrated. Waiting for approval before revocation would have increased exposure. Skipping human review entirely would have left an incomplete recovery. A bounded autonomous response followed by a reviewable artifact supported both speed and accountability. ## 6. Lessons from the public record The need for legible machine action predates current agents. Several public cases show why permissions, evidence, and meaningful review must work together. ### Machine speed turns small control failures into large events In 2012, an incomplete software deployment at Knight Capital left old code active on one of eight servers. The automated trading system sent millions of unintended orders and lost more than USD 460 million in about 45 minutes. The US Securities and Exchange Commission later found weaknesses in deployment, risk controls, and supervisory procedures.[3] This was not a generative AI incident. It remains relevant because agentic systems combine software speed with a broader ability to choose and sequence actions. A readable deployment proposal would not have been sufficient by itself, but a proposal bound to server inventory, independent validation, and an enforced stop condition could have exposed the mismatch before market open. ### An organisation remains responsible for automated output In *Moffatt v Air Canada*, a customer relied on incorrect bereavement fare information supplied by a website chatbot. The British Columbia Civil Resolution Tribunal found the airline liable for negligent misrepresentation.[4] The case concerned customer information rather than an autonomous operational agent, but the accountability lesson is direct. A business cannot treat the automated system as a separate source of responsibility. If an agent publishes a policy, sends a message, or changes a customer record, the organisation still owns the result. ### A human in the loop can still fail to review In *Mata v Avianca*, lawyers submitted non-existent cases and quotations generated by ChatGPT. The court's sanctions order noted that one lawyer had reviewed the filing for style and flow but had not checked the cited authorities. The court described lawyers as gatekeepers responsible for the accuracy of their filings.[5] This is a useful distinction between nominal review and substantive review. A person clicking approve, checking grammar, or trusting a confident summary does not create an effective control. Evidence has to be presented in a form that can be verified, and the reviewer has to understand what they are responsible for checking. ### Environment boundaries matter more than instructions In 2025, Replit publicly described an incident in which an agent deleted data from an application's database during development. The data was restored, but the company acknowledged that development changes could affect the production application before separate environments were introduced. Its response included default separation of development and production databases, checkpoints and rollback, and it announced a planning mode that could operate without modifying the project.[6] The important control was not a stronger sentence telling the agent to be careful. It was a technical boundary that removed production access during development. Review artifacts should sit alongside controls of this kind, not be used as a substitute for them. ## 7. Requirements for credible review A document becomes useful governance only when the surrounding system gives it integrity. ### Bind approval to the exact action Approval should identify the artifact version, actor, tool, target, normalised parameters, time limit, and permitted scope. If the agent changes the plan after approval, the system should require a new review for material changes. ### Preserve immutable versions Replacing a document in place erases the basis of earlier decisions. Each published version should remain available. Comments should show which version and passage they addressed, whether they were resolved, and what changed next. ### Connect claims to evidence Statements such as "tests passed", "no customer impact", or "all records were updated" need supporting receipts. These may include test identifiers, record counts, hashes, screenshots, source links, or signed tool results. Reviewers should be able to inspect evidence without searching through the full agent session. ### Keep identity and authority clear The artifact should distinguish the requesting person, publishing agent, reviewer, approver, and executor. An agent should not be able to approve its own high-risk proposal by generating a second identity or delegating to another agent under the same authority. ### Enforce least privilege outside the document OWASP guidance for agent security recommends minimum tool access, explicit authorisation for sensitive operations, action previews, audit trails, and human approval for high-impact or irreversible actions.[2] These controls must be implemented by policy and execution services. An agent's claim that it has approval is not approval. ### Make uncertainty visible Confidence scores alone are not enough. The artifact should identify missing sources, conflicting evidence, assumptions, and decisions based on incomplete information. A reviewer needs to know where judgement is required. ### Protect sensitive material Reviewability does not justify copying secrets, personal data, or confidential records into a document. Evidence should use redaction, minimum necessary fields, access controls, and retention rules appropriate to the underlying data. ### Preserve source and rendered views Reviewers should be able to inspect the readable source and the rendered document. This reduces the risk of hidden HTML, misleading CSS, invisible text, or a rendering difference that changes the apparent meaning. ## 8. Designing review for people Review fails when it becomes a high-volume queue of vague approvals. ### Assign the right reviewer The person who can approve access may not be the person who understands the decision. A database migration may need an engineer who knows historical data. A refund policy may need operations and compliance review. Assignment should follow the risk, not merely the reporting hierarchy. ### Ask focused questions An agent should state what it needs from the reviewer. "Review this document" is weak. Better questions include: - Does the rollback remain valid after the schema change? - Is this interpretation consistent with the vulnerable-customer exception? - Are these three unmatched payments safe to post manually? - Does the evidence justify closing the incident? Focused requests reduce review time and make accountability clearer. ### Keep comments contextual Discussion should attach to the exact claim, row, or passage under review. General comments still have a place, but contextual comments make it easier for the agent to revise accurately and for a later reader to understand why the text changed. ### Preserve disagreement Resolved does not mean deleted. A material concern and its resolution are part of the operational record. If a later version reintroduces the issue, the history should remain discoverable. ### Control review load Teams should sample low-risk work, group routine activity, and escalate by exception. If every action requires approval, reviewers will approve mechanically or the agent will stop being useful. Risk-based autonomy is more credible than either unrestricted access or universal gating. ## 9. A practical operating model An organisation can start with four action tiers. | Tier | Typical work | Agent authority | Review expectation | | --- | --- | --- | --- | | 0: Observe | Search, read, classify, summarise | Read-only, bounded sources | Periodic sampling and provenance checks | | 1: Reversible | Drafts, internal updates, isolated development changes | Automatic within limits and rollback coverage | Post-action artifact or grouped digest | | 2: Material | Production deployments, bulk record changes, external communications | Execution only after version-bound approval | Proposal, evidence, named reviewer, outcome report | | 3: Critical | Irreversible deletion, funds movement, privilege changes, regulated decisions | Independent policy validation, step-up authentication, and narrow execution token | Dual control where appropriate, complete evidence, retained decision record | The categories should reflect the organisation's real risk rather than the agent's confidence. A technically simple action can still be critical if it affects money, safety, rights, access, or public commitments. A complete review workflow can follow these steps: 1. A person or system assigns a task with scope and success criteria. 2. A policy service determines the agent's tools, permissions, and action tier. 3. The agent performs allowed research and publishes a draft artifact. 4. Reviewers add contextual comments or request evidence. 5. The agent publishes a new immutable version that addresses the feedback. 6. Approval is recorded against the exact version and proposed action. 7. The execution service validates approval, parameters, expiry, and current policy before granting a short-lived execution capability. 8. The agent performs the action and publishes an outcome artifact with receipts and exceptions. 9. Unresolved comments and failed checks remain open until a person accepts the residual risk or corrective work is complete. For emergency workflows, steps three through six may follow an initial bounded containment action. The exception should be explicit in policy. ## 10. Measuring whether review works Document volume is not a useful success measure. Better indicators include: - the percentage of material actions covered by a bound review artifact; - how often review produces a substantive correction before execution; - the percentage of factual claims with inspectable evidence; - approval time by risk tier; - attempts to act outside approved scope; - rollback and incident rates after reviewed and unreviewed actions; - unresolved material comments at the time of execution; - reviewer concentration and signs of approval fatigue; - results from periodic sampling of actions that did not require prior review. An unusually low correction rate does not necessarily mean the agents are always right. It may indicate that the artifacts are too vague, the reviewers are overloaded, or the wrong people are being assigned. ## 11. What a review artifact does not solve A clear document can still describe a bad plan. It can omit evidence, hide a material assumption, or use confident language to make uncertainty look settled. Human reviewers can misunderstand the subject, rush, or defer too readily to the system. The review layer therefore does not replace: - least-privilege access; - environment separation; - backups and rollback; - deterministic policy checks; - rate and spending limits; - secure handling of untrusted input; - monitoring and incident response; - professional responsibility. NIST's Generative AI Profile treats human oversight, monitoring, documentation, and accountability as parts of a broader risk-management programme, not as a single control.[1] The same principle applies here. Reviewable artifacts make oversight practical, but they depend on sound system design and a culture in which reviewers are expected to challenge the work. ## Conclusion As agents gain the ability to act, the central governance problem shifts from the quality of generated text to the quality of delegated work. People do not need to observe every tool call. They do need a reliable way to see what matters: intent, scope, evidence, uncertainty, consequences, and the record of how concerns were resolved. Versioned Markdown and static HTML provide a simple foundation for that boundary. They are understandable outside the agent's environment, precise enough for contextual discussion, and durable enough to support accountability over time. The useful question is not whether a human remains in every loop. It is whether humans can still see, challenge, and govern the work that matters. For practical examples, see the [agent review workflows](https://markupbase.com/use-cases/), the [MarkupBase MCP guide](https://markupbase.com/mcp/), and the [security model](https://markupbase.com/security/). ## About the author Jason Doyle writes about reliable software, observability, applied AI, and practical review boundaries for agent work. He publishes at [jasondoyle.ie](https://jasondoyle.ie) and can be contacted at . ## References 1. National Institute of Standards and Technology, *Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile*, NIST AI 600-1, July 2024, . 2. OWASP Cheat Sheet Series, *AI Agent Security Cheat Sheet*, . 3. US Securities and Exchange Commission, *SEC Charges Knight Capital With Violations of Market Access Rule*, 16 October 2013, . 4. *Moffatt v Air Canada*, 2024 BCCRT 149, . 5. *Mata v Avianca, Inc.*, No. 1:22-cv-01461, Opinion and Order on Sanctions, 22 June 2023, . 6. Replit, *Doubling down on our commitment to secure vibe coding*, .