The Circular Saw Problem

If the billing system creates a fresh account for every request, retrying can create a duplicate. If the job stops, someone has to establish whether the account exists before running the export again. The builder may have solved the formatting problem perfectly and still have an unresolved decision about live customer records.

Production is where the input arrives malformed, the token expires mid-batch, and the downstream system may have no way to undo just the changes your tool made. A successful demo leaves those questions open.

A circular saw can cut cleanly through a floorboard or a joist. You still need to know which one you’re cutting. For this tool, the decision starts when someone grants it access to the billing system.

A freeze the agent could ignore

In his account of a July 2025 Replit incident, SaaStr’s Jason Lemkin described an AI agent deleting the production database of an app his team was building. He had repeatedly instructed it to freeze changes. Lemkin also reported that the data was eventually recovered, despite the agent initially claiming recovery was impossible.

Replit’s own July 21, 2025 announcement supplies an important architectural detail: its apps had been using a single database for development and live customer data. The company announced a beta rollout of separate databases for new apps. It also described a prompt at redeployment asking whether development database changes should be applied to production.

The distinction we draw from that response is between an instruction and an access boundary. If development code can reach only development data, a destructive write there cannot delete live records. An instruction to leave production alone still depends on the agent following it.

The announcement documents a specific change and a rollout in progress. It doesn’t establish that every route to production was blocked. A separate test database only protects the live one if the builder and its tools lack another way to reach it.

The finished tool still needs a boundary

The overnight export could be a fixed program that never calls an AI model once it’s running. The Replit incident doesn’t establish how reliable that program is. It shows why the development agent’s access matters; the finished program then needs its own assessment.

Development access can end when the build ends. The running job needs its own credential, kept out of the builder’s workspace. Someone must also control which code can run with it: if the builder can publish changes unreviewed, it can change what the live credential is used to do.

Start with the actual work: create customer accounts and update the fields finance has approved. That job doesn’t need permission to change invoice amounts or delete customers. Ask the system administrator whether the vendor can enforce that distinction in the account or credential the job uses. Check those specific actions rather than accepting a generic “write access” label.

Where narrow permissions are available, an internal administrator and engineer can configure them with the builder. Test the refusal as well as the success: in a test environment with matching permissions, try an approved customer update and a forbidden deletion. Read the records back. A restriction described in a setup screen needs to hold when a request reaches the system.

Read access deserves a separate look. A read-only CRM credential prevents edits there, but can still let the tool copy customer records to a third-party formatting service. The approval needs to cover which fields leave the company and the recipient’s retention terms. A sandbox populated with real customer records still carries that disclosure risk.

A tool limited to customer updates can still put the wrong address on every customer it can reach. Permissions exclude actions; they don’t establish that the allowed ones are correct. The interrupted export is a problem entirely inside its legitimate access.

Ask for the interrupted run

The HTTP standard’s treatment of retries explains the opening problem. A request is idempotent when repeating it has the same intended effect as making it once. The standard warns against automatically retrying a non-idempotent request unless the client knows repetition is safe or can establish that the first request was never applied.

For the customer export, that means checking the billing system’s actual behavior. Can the job repeat a request without creating another account? Can it reliably identify the account created by the first attempt? A retry loop alone answers neither question.

For example, if billing can store a stable CRM account ID and enforce its uniqueness, the job can send the same ID with every attempt to create that account. Billing must refuse to create another account with that ID. The job can then retrieve the existing account and compare the fields it meant to save.

That design depends on billing enforcing uniqueness when it saves the record. Merely looking for an existing account before creating one leaves a gap: another run could create it between the lookup and the write.

Ask the builder and reviewer to interrupt a test run after billing saves an account but before the job receives the reply. Run the recovery path and inspect the stored account, including its customer ID and fields. Then try a request that never reached billing. The job needs to recover without duplicates or stop with enough information for a named person to reconcile the uncertain write.

For a stopped run, that person should be able to identify the affected CRM account and check what billing saved without rerunning the export. An engineer-written integration needs the same proof.

The owner of this automation needs authority to stop its schedule, revoke its access, and arrange repair with finance. That can be an existing internal role. Code review contributes technical judgment; it can’t decide on finance’s behalf which changes are acceptable or who will resolve an interrupted batch.

If the vendor only offers broad administrative access, or nobody can yet explain the interrupted run, the tool can still prepare an import file for finance. Use the existing import process when finance can show which account each row will affect and how it reconciles a partial import. A person clicking Import can create the same duplicate; that process owes you a recovery demonstration too.

Sales ops can still automate the reformatting. Leave the unattended write disabled until its permissions and recovery behavior have been demonstrated.