A merchant approves a proposed price change for one item. Before the agent applies it, another user changes the supplier cost. The agent then generates a new price and submits it using the old approval. The merchant authorized an action, but the system committed a different one.
A consequential AI write should move through a concrete preview, approval of that action, controlled application and verification of the resulting state. Each stage has its own evidence. Approval must remain bound to the payload and conditions the person actually reviewed; verification must inspect what happened outside the agent’s narrative.
This chapter of The AI Software Factory develops a hypothetical single-item price update. It is an operating design, not a recommendation to change Salars or customer prices automatically. The existing permission architecture explains general authority; this chapter owns the transaction that carries an approved proposal across a write boundary.
Preview the action rather than the intention
“Improve this listing” is an intention. A reviewable action names the item, current state, proposed state and destination. For a price update, the preview should show currency, amount, relevant assumptions and the specific record that will change.
The preview should also identify consequences the customer needs to assess. Will the change affect a visible price, a subscription, a published claim or a scheduled operation? A text summary that hides the actual field values leaves the reviewer approving the agent’s interpretation rather than the operation.
Use the smallest concrete action that serves the task. A merchant may want to change one item while leaving related inventory untouched. The agent should not bundle several additional changes because they appear economically attractive. Adjacent proposals can remain separate for review.
A preview can be generated with AI, but authoritative values should come from the relevant systems and deterministic calculations where possible. If the supplier cost is missing, show the gap. A model’s plausible estimate should not enter the write payload as if it were an observed amount.
Give the preview an identity and version
An approved proposal needs a stable representation. Retain the target, proposed values, input snapshot and relevant conditions. A version or fingerprint can connect the displayed preview with the payload later submitted.
The representation should include consequential fields rather than only the visible sentence. If the destination account or item identifier changes while the wording remains similar, the action has changed. The system should detect that mismatch.
A fingerprint helps establish whether two representations match under the chosen encoding. It does not prove that the proposal is correct. The reviewer still needs to inspect the content, evidence and consequence. Nor should a fingerprint hide fields that the person must understand; the user-facing preview and machine representation need a clear relationship.
For the hypothetical update, the preview might show item A, current price $40, proposed price $44, currency USD and the version of the cost evidence. Those amounts are assumptions for explanation, not a tested pricing recommendation. The approval refers to that exact proposed action.
Establish who may approve what
The approver needs legitimate authority for the target operation. An account user may be able to read reports without being allowed to change prices. A contractor may prepare a recommendation while the merchant retains commitment authority.
Check the identity and role through the application’s authorization system. A message containing “approved” is not enough. An uploaded document, forwarded email or model-generated summary cannot grant itself the customer’s authority.
The approval should specify the allowed scope. One record, one revision and one destination differ from a standing policy authorizing a category of operations. Standing authorization can be useful, but its conditions must be defined and enforced. A broad natural-language instruction should not quietly become unlimited write access.
The agent security chapter addresses credentials and untrusted inputs. At the transaction boundary, the useful principle is that technical access and legitimate approval are separate facts. A service key capable of changing every item does not mean the agent may change every item.
Make approval understandable and revocable
The user should be able to see what approval does and how to stop before commitment. Avoid a button whose label implies a preview while it immediately changes production. If approval itself commits the action, the interface should say so and the transaction must preserve the binding.
For delayed workflows, record approval time and any expiry or revocation condition. A merchant can revoke access or revise the proposal while a worker waits. The worker should not treat an earlier valid decision as permanently applicable.
Notifications about approval should preserve privacy and scope. A message can point an authorized user to the proposal without embedding unnecessary customer data. The system should not accept a reply from an unrelated participant because it resembles the expected wording.
Usability matters to meaningful approval. If the preview is too broad or confusing to inspect, the formal click supplies little judgment. Narrow changes, clear differences and visible assumptions make review more useful than an extra confirmation dialog attached to an opaque action.
Recheck conditions at commitment
Time can separate preview from application. The target may change, a price may already be updated or the customer may lose the relevant entitlement. Recheck conditions that determine whether the approved action remains valid.
A version check can detect that the target record no longer matches the preview’s baseline. The application can stop and prepare a new preview rather than overwrite another user’s work. The exact conditional-write mechanism depends on the remote system; the invariant is that stale approval should not authorize a silently revised action.
For the price example, if the current price changed from $40 to $42 after preview, the system should follow its stated conflict policy. It might require renewed review. It should not assume that changing $42 to $44 is equivalent to the action the merchant originally saw.
Recheck authority too. Approval can be valid when recorded and invalid when applied because access was revoked. A worker should obtain or use narrowly scoped authority at the commitment boundary rather than retain a broad credential indefinitely.
Keep application separate from generation
Once the payload is approved, the application step should submit that payload rather than ask the model to improvise a new version. A model can help explain a conflict or prepare a revised proposal, but that revision follows a new review path.
The write tool should accept structured validated fields. It should constrain targets and operation types to the task. A generic shell or unrestricted API client can expand the agent’s practical authority far beyond the approved action.
The application step should retain an operation identity and receipt. If the connection fails, the worker needs to know whether the remote effect occurred. Idempotency explains how stable identities and reconciliation can prevent duplicate effects.
Keep application outcomes specific: applied, rejected by conflict, denied by authority, failed before execution or unresolved after an ambiguous response. Collapsing these states into one error message makes the next action harder to choose and can invite unsafe retries.
Verification asks the destination
A successful API response is useful evidence, but the relevant verification may require reading the resulting state. Did the correct item receive the approved value? Is the visible product page consistent? Did the operation affect unintended records?
Verification should compare actual state with the retained approved payload. The agent’s sentence “I updated the price” is a report, not the evidence. A receipt or fresh read can support that report within its scope.
Some systems are eventually consistent. A read immediately after a write can show old state. The verification policy should account for the documented behavior with bounded waiting or an authoritative receipt, rather than declare success from the first convenient response. It should also avoid unlimited polling that consumes resources without changing the uncertainty.
The outcome should remain unresolved when evidence is insufficient. That state needs an owner and reconciliation route. Honest uncertainty is preferable to marking the operation complete because the task wants an ending.
Record the chain without hoarding sensitive data
An audit record should connect proposal, approval, application and verification. Retain the identities, relevant versions, actor, timing, result and recovery action. The record should let an authorized operator reconstruct what was permitted and what happened.
It need not retain every conversational detail or full customer document. A source reference and the consequential fields can preserve useful evidence with less exposure. The privacy design chapter explains why retention needs a purpose and boundary.
Protect the record against casual editing. If the same agent can change the approval log after a failure, the record cannot provide independent evidence. Use the application’s existing audit and access conventions rather than inventing a parallel unrestricted history file.
Auditability is not correctness. A perfectly retained record can show that an authorized person approved a bad price. The record makes responsibility and recovery inspectable; it does not eliminate judgment or substitute for a sound proposal.
Plan reversal before the write
A reversible field update can sometimes be restored to the prior value, provided the target has not changed again and authority remains valid. Other actions create obligations that cannot be erased: a message was sent, a purchase was submitted or a public claim was seen.
The preview should identify the recovery route appropriate to the consequence. For the price update, restoring the old value may be possible, but orders placed while the new price was visible may require separate handling. “Rollback available” should not hide that distinction.
The rollback chapter examines restoration and compensation in detail. The write protocol should retain the state needed to choose that route. A generic undo button without the relevant versions can overwrite a legitimate later change.
Some actions warrant a narrower pilot or human execution first. If the system cannot reliably verify or recover a consequential write, expanding automatic authority is premature. A prepare-only mode can still deliver value by giving the customer an inspectable action to perform through an established interface.
Use standing authorization carefully
A merchant may want routine updates under a preapproved policy. That can reduce review burden when the policy is bounded and the application can enforce it. Define allowed targets, amount limits, frequency, evidence prerequisites and exceptions.
For example, a hypothetical policy could allow preparation of price-change proposals for a named category while requiring individual approval for application. A more permissive policy would need stronger evidence and controls. The exact thresholds are business decisions, not universal safe values.
A standing policy should have an owner, version and revocation path. The worker should record which policy authorized each operation. If the policy changes, pending operations need a clear rule about whether they remain permitted.
Do not treat absence of objection as approval when approval is required. A delayed reviewer or unanswered notification does not create authority. The workflow can expire or remain waiting according to policy without inventing permission to satisfy a deadline.
Test the binding at every handoff
A proposed test suite should change the payload after preview and confirm that the old approval is rejected. It should revoke the approver’s authority before application, alter the target baseline and repeat the application attempt after a lost receipt.
Include allowed countercases. An unchanged valid proposal should apply successfully. A legitimate revised proposal should proceed after its own approval. A denied operation should leave the target unchanged and report the reason clearly.
Test the customer interface as well as the backend. Does the displayed preview match the structured payload? Does a button act on the proposal the user is viewing? Can a stale browser tab approve a newer hidden version? These cases expose gaps that a service-only test can miss.
Independent verification matters here because the agent that produced the proposal should not be the only judge of whether approval remained bound. Deterministic checks can establish exact matches; accountable review can assess whether the preview explains the relevant consequence.
Treat a batch as a set of inspectable operations
A batch preview can make review efficient, but it should preserve item-level identity and result. If ten proposed price changes are approved, the system needs to know which ten values the user saw and which ones applied. Partial success should not appear as all-or-nothing completion unless the receiving system actually provides that guarantee.
The user may approve some items and reject others. Retain that selection in the authorized payload. A worker should not regenerate the batch and include a new item because it resembles the approved ones. Newly discovered opportunities can wait for a later proposal.
Verification should report each item and any shared failure. If one item conflicts with a newer record, the policy may stop that item while allowing independent approved items to proceed. A dependency between items can require stopping the whole set. Define the rule before execution so the worker does not choose it opportunistically after a failure.
The recovery plan should also be item-specific. Restoring a successful update while leaving a failed one unchanged may be appropriate; replaying the entire batch can create repeated effects. Stable operation identities and retained results make the partial state understandable to both the customer and support team.
Keep routine work proportional
Not every edit needs a separate human confirmation. Existing authorization can cover reversible routine work, and the application’s normal release policy may already govern it. Adding approval dialogs everywhere can train users to click without inspection.
The protocol should focus on consequential writes and existing boundaries. Its purpose is to make the approved action concrete and the result verifiable. Where authority is already established, the system can proceed within that scope while retaining appropriate evidence.
The amount of review should match the uncertainty and consequence. A draft saved locally differs from a message sent to a customer. A preview price calculation differs from a live price update. The product should preserve those stages rather than attach the same word “save” to actions with different effects.
A bounded pilot can measure review time, conflicts, duplicate attempts and failures after commitment. Those observations can support a narrower or broader automation policy within the tested scope. They do not justify blanket write access across unrelated apps.
What Would We Do at Salars?
A proposed Forge template would separate proposal generation from application. The first merchant pilot would prepare diagnostics and optional action previews without changing live records. Each preview would expose source evidence, assumptions, destination and exact values.
If a later pilot added authorized writes, it would retain a proposal version, approval identity, operation key and verified result. It would test stale approvals, changed records and lost receipts with safe fixtures before any customer commitment. The repository’s existing release and permission policies would remain the authority for deployment and access.
Supplier Margin Guard and Merchant Revenue Guard are proposed examples, not operating services in this chapter. Their usefulness would need customer validation; their write authority would need evidence appropriate to each action. A diagnostic that passes tests does not authorize an automatic financial decision.
The meaningful chain is concrete: the person saw this action, authorized this action, the system applied this action and the destination confirms this result. When any link is missing, the job should preserve the gap instead of supplying a confident completion story.
Sources
- Salars: permission architecture for agents, inspected October 7, 2026, for related observe/prepare/commit principles; this chapter develops the payload-bound write transaction as a proposed design.
- Stripe: idempotent requests, read October 7, 2026, for the narrow retry mechanism referenced at the external-write boundary.
- Salars AI library, for related verification and privacy guides. All amounts, policies, interfaces and tests here are hypothetical or proposed.
Loading comments…