{"schemaVersion":"1.0","canonicalUrl":"https://www.iamgeorgekelly.com/field-guide/supervised-commerce-workflows","markdownUrl":"https://www.iamgeorgekelly.com/field-guide/supervised-commerce-workflows/index.md","editorialNote":"AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.","slug":"supervised-commerce-workflows","title":"From request to release: a supervised commerce workflow.","description":"An original seven-stage operating checklist for turning agent-assisted commerce work into an inspectable, authorized, verified release.","category":"Operations","status":"published","published":"2026-09-05","updated":"2026-09-05","author":"George Kelly","answer":"A supervised commerce workflow separates preparing a change from authorizing it and proving the live result. Carry the same scope and artifact version through intake, source collection, drafting, preview, approval, publication, and verification.","sections":[{"id":"unit-of-work","title":"Make the unit of work a reviewable artifact","paragraphs":["“Improve the product page” is too broad to evaluate. A usable request names the page, the intended customer outcome, the fields that may change, and the evidence that will establish correctness. A reviewer should be able to compare the proposal with the current page without reconstructing a conversation.","An agent can help assemble the evidence and produce the proposal. The operating design still needs to identify who can authorize the resulting action. Anthropic’s engineering guidance describes evaluation, environmental feedback, and human checkpoints as parts of agent design; the release workflow here applies those ideas to commerce operations."],"sources":["anthropic"]},{"id":"release-contract","title":"The seven-stage release contract","paragraphs":["Treat each stage as a handoff with a concrete output. A stage can be automated when its acceptance condition is reliable and the action is authorized. A missing source or changed scope should return work to the relevant stage instead of being quietly bypassed."],"table":{"headers":["Stage","Acceptance check","Evidence","Owner"],"rows":[["Intake","Goal and affected URLs are explicit","Scoped request","Request owner"],["Source","Material facts have current approved sources","Source register","Product or content owner"],["Draft","Proposed changes are inspectable","Draft and difference","Producer"],["Preview","Content and behavior match the proposal","Preview URL and checks","Reviewer"],["Approval","Decision applies to this exact version","Versioned approval record","Release owner"],["Publish","Authorized artifact reaches its destination","Deployment identifier","Release owner"],["Verify","Canonical live output matches approved artifact","Live URL and recorded result","Verifier"]]},"download":{"url":"/downloads/commerce-release-checklist.csv","label":"Download the release checklist"}},{"id":"permissions","title":"Match the permission to the consequence","paragraphs":["Reading a public specification, preparing a draft, changing a product description, sending a customer message, and changing a budget have different consequences. Giving one process the broadest credential needed by any of these tasks removes the distinction that the workflow is supposed to enforce.","Record the action boundary directly: which account, which destination, which fields, which amount if applicable, and whether the operation is reversible. A request to investigate a problem should not be interpreted as permission to carry out every proposed remedy. When publication is already authorized for a defined change, the workflow should carry that authorization forward rather than repeatedly asking the same question.","Use a specific stop condition for missing evidence. For example: if the specification and page disagree about included components, prepare the discrepancy and pause the affected copy. That condition is testable; “be careful” is not."]},{"id":"example","title":"A worked example: a product spotlight page","paragraphs":["In this hypothetical example, a commerce team requests a spotlight page for a product family. The request identifies the intended audience and approved product records. The draft contains only supported specifications, shows which variants are covered, and links to the correct destination.","The preview review checks visible copy, responsive layout, keyboard navigation, images, metadata, and the destination for each primary link. If a new accessory or unsupported performance claim appears, it returns to source review. If only spacing changes, the reviewer checks the affected layout rather than repeating unrelated product research.","After approval, the release owner publishes the exact version that was reviewed. Verification opens the canonical public URL and compares the material content with the approved artifact. A successful build or an accessible preview proves a different condition from a correct production page."]},{"id":"evidence","title":"Keep an evidence record small enough to use","paragraphs":["A useful release record contains the request identifier, affected URLs, source references, approved version, deployment reference, validation results, and unresolved exceptions. It should help the next person answer what changed, why, who could authorize it, and whether it reached the intended destination.","Do not bury the decision in an undifferentiated transcript. Preserve the durable facts and link to detailed evidence when needed. A short structured record is easier to compare across releases and easier for another agent to ingest without mistaking old suggestions for current instructions."]},{"id":"improve","title":"Evaluate the workflow on accepted releases","paragraphs":["Measure elapsed time, human handling time, rejection reasons, rework, and escaped defects. Generation speed is only one component. If a faster draft causes more source verification work, the apparent improvement may disappear after review.","Use the rejection log to improve the narrow step that failed. Missing units suggest a contract check. Unclear requests suggest a better intake template. Incorrect live destinations suggest release verification. Increasing autonomy is a possible response to reliable performance, not the default response to every bottleneck."]}],"sources":[{"id":"anthropic","title":"Anthropic: Building effective agents","url":"https://www.anthropic.com/engineering/building-effective-agents","note":"Supports evaluation and environment feedback as agent-design principles. The seven-stage commerce checklist is an original adaptation, not an Anthropic standard.","checked":"2026-09-05"}],"related":["ai-product-copy-evaluation","product-data-for-agents","agentic-commerce"],"project":"american-standard-bathing"}