How We Brief, Review and Release Agent Work

Field note · 25 October 2026

Before an agent edits this website, our instructions require it to read the project brief and the complete item thread. It needs to know what was approved, where it may work, and where its responsibility ends before it edits a file.

That is part of how we support software under management. Agents handle implementation and checks; a person remains accountable for the work. Here is the preview workflow our current instructions specify, including the limits of what those instructions establish. This is a description of the process, not an audit of every past run or a claim that this article has already completed it.

A Workspace Is Not an Isolation Guarantee

We have described server-hosted coding workspaces in Give Your Coding Agents a Safe Home. Persistent storage and a terminal multiplexer can let work survive a disconnected laptop. They do not guarantee that a task keeps running: processes stop, usage limits apply, and rebuilds can interrupt sessions.

Nor does a container alone prove that an engagement is isolated. Filesystem mounts, host access, network permissions and credential scope need checking in the actual setup. Work can also run locally, with different coding clients. There is no single topology to assume across engagements.

Constructed illustration: example UI and data, not a live capture or evidence of workspace isolation.

For parallel edits, our instructions call for separate worktrees or workspaces, rather than several writers changing the same checkout. Finished changes are committed and pushed; an interrupted or unfamiliar dirty tree is reported rather than reset. These are operating rules, not proof that interruption or conflicting edits cannot happen.

A Fresh Brief Still Needs Fact-Checking

The platform assembles a brief for the project's role at the start of a pass. It combines house rules, role boundaries, client and project guidance, live settings, and scoped memory. Credential entries in that brief are names or references, not secret values automatically inserted into the text.

Live settings determine such things as deploy mode and allocated ports. Project-specific guidance can refine defaults, but cannot override hard safety rails. The agent still has to inspect the code and check the facts it relies on.

Memory carries an age and a trust indication. That helps the next reader judge it; it does not make it current or correct. A freshly assembled brief can contain an old observation. Serving context fresh is different from verifying its truth.

Where People Decide in Preview Mode

For this site's preview releases, the intended sequence is:

request -> analyst proposes acceptance criteria
        -> person approves the scope
        -> developer builds on the release branch and self-verifies
        -> fresh-context critic, separate review and testing
        -> person accepts the verified work
        -> releaser promotes the ready release
        -> deploy checks and fresh production verification
        -> marked deployed

Approval authorises the build. Acceptance moves the work to ready for deployment and authorises the releaser leg once the release is ready. There is no additional human deploy gate after production verification. The releaser performs the promotion and checks; it does not make the acceptance decision.

New is analyst intake, not an approval queue. A proposal waits for approval after analysis. Developer handoff requires a recorded test command and actual result, or an explicit reason there was nothing to run. Separate review and testing precede acceptance.

Constructed illustration: simplified example states and items, not a live board or a record of completed work. Review and acceptance states are omitted from this overview.

The platform supports automatic dispatch for some legs. That is a capability, not an assertion that it is enabled: this project's analysis, development and release auto-dispatch settings were off when checked on 25 October 2026. Other deploy modes have different mechanics; this diagram is not a universal flow or a requirement for a new human decision on every permitted data read.

Separate Readers, With Shared Blind Spots

The prescribed fresh-context critic receives the diff and acceptance criteria, without the builder's explanation, and is asked to find faults. A reviewer examines the change separately; a tester checks the built result against the criteria.

Different context can reduce confirmation bias. It cannot eliminate shared model errors, missing criteria or a mistaken test oracle. A test that merely repeats the implementation's logic can agree with the same bug. We therefore ask for outcome checks and, for guards, a deliberate weakening that should make the test fail. Multi-model review adds another perspective, not a guarantee.

As a hypothetical example, consider a request to respect reduced motion. The criteria should cover both the initial setting and a change while the page is open. The developer would exercise both, the tester would repeat them independently, and a person would review the evidence before accepting. This example does not attribute a finding to a historical critic or claim a particular release followed that sequence.

Promotion Is Not the End of Verification

The site is statically exported. Its preview lets us inspect the proposed pages while production still serves the previous version. Projects that require isolated data need that environment established separately; a preview URL alone does not prove database isolation.

Constructed illustration: example release, items and check results, not a live capture or release evidence. Acceptance authorises promotion; production checks follow it.

After promotion, the releaser waits for deployment and smoke checks and verifies production afresh. Preview evidence does not establish that the production deployment succeeded. Recovery decisions remain with the accountable person; this is not an automatic rollback promise. Cleanup is scoped to the release and remains subject to permission, not a licence to delete unfamiliar work or infrastructure.

The buyer does not need to operate this machinery. It supports the service: agreed work, visible progress and one person responsible for the result. The scope starts with the Software Health Scan and management agreement, not with buying our internal platform.