The Uncommitted
The business depends on a script. Its disaster-recovery plan is “ask whoever has the laptop.”
What it is
The Uncommitted is a business automation whose working source and setup exist only on a laptop, a server, or an unshared local repository. The job is useful and people rely on it, but nobody has established a recoverable version, an owner, or a repeatable way to run it elsewhere. The running copy has been promoted to production by popular demand.
How an experiment becomes infrastructure
In an illustrative warehouse team, an AI-generated script converts a supplier’s spreadsheet into an import file. It starts as a one-off and becomes the morning routine. The author adjusts a column mapping directly on the machine running it. A repository exists, but the last saved version predates that adjustment; the schedule and runtime version were never recorded.
When the machine is replaced, somebody restores the repository and gets a plausible file with the wrong columns. The problem was not just a missing commit. The team never checked that its recovery material described the automation the business was actually using.
Why it’s dangerous
Without a known version, a maintainer cannot reliably compare yesterday’s behavior with today’s or recover a lost edit. A repository badge on the project does not establish that the running program matches it. The recovery question is whether a second person can find the right source, obtain appropriate access, and reproduce the result after the original machine disappears.
AI makes useful automations accessible to people whose job is to solve the business problem. The organization needs to supply the path from useful experiment to supported tool. Requiring everyone to discover repository permissions, deployment conventions, and recovery procedures independently is how the shared drive becomes a software platform. An agent’s completion report should distinguish “created and ran locally” from “saved in the shared repository” and “deployed.” A cheerful “done” can hide all three different states behind one word.
How to give it a durable home
Start from the actual launch command or scheduler entry. Find which files it loads, its working directory, runtime, configuration, and state. Compare that source with the repository before overwriting either copy; the server may contain the only copy of a useful fix. Review the captured version for credentials and sensitive data before committing it. Save dependency requirements, the schedule, and representative input and output. Store secrets through the team’s credential mechanism, not in the repository. Record where durable state lives and how it is backed up.
Confirm that the accepted revision is available in the team’s shared remote. A Git commit records a local snapshot; it does not deliver that snapshot to another person or release it to the running system. Record the revision the job actually runs, not merely the latest revision in the repository.
The serious team fix
- Make the supported path easy to find. Provide a repository template and a known place to register the automation, with its business purpose, owner, run location, and recovery instructions. An existing team repo may be enough. AI can help gather and draft this material; someone must confirm it matches the live job.
- Exercise recovery away from the original machine. Have a second person set up the recorded revision in a clean test environment and process a sanitized sample with agreed output. For the spreadsheet converter, check the column meanings, not just that a file was produced. Include required configuration and state; successful source checkout alone is a very early checkpoint.
- Choose a release procedure proportionate to use. A low-risk, occasional conversion may need a documented command and a pinned environment. A shared scheduled job benefits from an automated deployment with recorded versions and failure notifications. Deploy from a recorded revision rather than editing the active copy. For a legacy job that still permits live edits, compare its source with that revision before the next release and reconcile differences; do not overwrite an emergency fix silently. Reuse existing hosting and pipelines. Keep deployment approval separate from merely saving work.
Before switching a scheduled job to its new home, stop the old schedule and account for work in flight. Otherwise the recovery project can leave two working copies performing the same business action. Preserve the old version for recovery, without preserving a second active production job.