The Person Who Built the Workflow Is Away. What Happens Next?

The weekly report is due and the person who built the workflow is away. A folder contains several prompts, a spreadsheet called final and a reassuring note that the process usually works. The backup operator can open the files. They cannot tell which version is current or whether pressing run will also send the report.

This is a continuity problem before it is an AI problem. The team depends on knowledge that has not been made usable by another authorised person. A successful output from the builder's machine does not establish that someone else can reproduce the work, identify a defect or recover without contacting the builder.

Start by separating the service from its creator. Describe what the workflow produces, who relies on it and the conditions under which it must stop. Then collect the minimum instructions and evidence that another person needs. The aim is a handover that survives a practical exercise, including an interruption the builder normally handles without thinking.

The missing knowledge is often ordinary

List the decisions made between opening the folder and accepting the result. The builder may know which export contains approved data, why one status code is excluded or when a changed template needs review. These details are part of the workflow even if they have never appeared in its prompt or script.

Ask the builder to explain an awkward cycle, not only the usual one. What happens when an input arrives late, an expected column changes or the output names an unsupported conclusion? The response reveals where operational judgement is required. That judgement needs an owner and a clear escalation route; a longer prompt cannot simply absorb it.

Distinguish knowledge from access. An operator may understand every step and still lack permission to read the source or use the approved tool. Conversely, access does not mean competence to interpret the output. The handover needs both an authorised access route and a supervised opportunity to demonstrate the checks.

Use roles for durable responsibilities, then record the actual authorised cover through the organisation's normal process. A role called backup operator is useful only if someone has accepted it and can obtain support. Keep the business approver separate from the workflow maintainer where the task requires distinct judgement, even when a small team combines other duties.

Write the smallest pack that supports operation

A useful continuity pack starts with a short service description. It names the approved inputs, the expected output and its recipient. State whether the output is a draft, a reviewed report or a record ready for a separate publishing step. That status prevents an operator from treating completion of generation as permission to distribute it.

Include an input inventory with stable locations and version expectations. A path to the builder's desktop is a dependency that needs resolving, not an adequate shared location. Identify who supplies each input, how the operator recognises the correct reporting period and which missing item prevents a run from starting.

Keep operating instructions in execution order, with the expected result after each meaningful stage. A command or button label is not enough if the operator cannot recognise success. Explain what a correct draft contains, where it is saved and which evidence the reviewer uses to accept or reject it. Avoid screenshots carrying sensitive records.

Record the environment only to the depth needed to reproduce the task. Name the approved application or runtime, relevant version information and controlled configuration. Do not turn the pack into a catalogue of every preference on the builder's machine. Where behaviour depends on a setting, include the setting and its purpose so the backup can check it deliberately.

The pack should refer to secure access arrangements without including secrets. Name the approved request route and administrator role. Do not include passwords, private keys, session cookies or another person's account. A missing permission is a stop condition to resolve through the proper channel, not a reason to copy the builder's access.

Permissions remain outside the prose promise

An instruction that says draft only helps describe the task, but the environment also needs appropriate controls. OpenAI's Codex documentation on agent approvals and security distinguishes sandbox mode, which limits what the agent can technically do, from the approval policy, which sets when it must ask before acting. That distinction matters when another operator opens the same project: knowing what the instructions request is different from knowing what the environment permits. OpenAI: Agent approvals and security.

Anthropic's Claude Code documentation describes permission rules that allow, ask about or deny tool use, with configuration at different levels. A handover therefore needs a check of effective permissions in the actual environment. Copying an instruction file alone does not prove that the backup has the same controls as the builder. Anthropic: Configure permissions.

These are documentation references, not evidence of a tested configuration in this article. The recovery method is tool-neutral and does not rely on a particular plan, operating system or current button label. Before using a product-specific procedure, the responsible technical reviewer must confirm the installed version and the controls available to that user.

For a small private business, this can be a practical operational check inside its existing access process. A Commonwealth agency must also follow its own applicable authorisations and policies. Neither setting gains permission to bypass controls because the report is due. If the approved route is unavailable, use the agreed fallback or escalate the delay.

A constructed weekly reporting workflow

Consider a fictional private Australian consultancy preparing an internal weekly delivery summary. The report groups approved project status rows by service category and drafts a short commentary for a manager. The workflow never sends the report. It produces a draft in a review folder and a separate source-reference list.

Every file, run record, failure and proposed model response described here is constructed. No recovery exercise was performed and no software behaviour was observed. The example is a design for a supervised test that a team can run in its own approved environment. It uses fictional aggregate rows with no client names, employee information, secrets or commercially sensitive project details.

The constructed pack contains weekly-status.csv, reporting-rules.md, category-map.csv and an approved output example. The status file uses category codes. The mapping file explains how those codes become report headings. The rules require an unknown or missing mapping to block generation, rather than allowing the assistant to guess what a code means.

The first constructed run deliberately omits category-map.csv from an isolated exercise copy. The desired control response is a missing-dependency notice identifying that file and the stage that cannot proceed. The draft report must not be produced from guessed mappings, and the operator must not substitute a similarly named file without checking its approved version.

The proposed failed-run record says input validation stopped because the category mapping was absent. It records that no report was accepted or distributed. This is an expected outcome for the exercise, not an actual log. Labelling it that way is essential: a well-designed record does not prove that the implemented workflow will generate it.

The backup operator's next step in the constructed scenario is to consult the dependency register. It names the reporting coordinator as the role responsible for supplying the approved mapping. The operator requests the correct exercise copy through the authorised channel. They do not access the absent builder's account or ask the model to reconstruct the missing file.

The second constructed run uses the restored, identified mapping and the same approved status input. Its proposed output is a draft with a reporting period, grouped status statements and source references. The reviewer checks the grouping against the mapping and every substantive statement against the input. Only a separately recorded human acceptance can move it beyond draft status.

This exercise tests two capabilities. The backup must recognise when the workflow cannot safely proceed, then recover it without changing its authority. Producing a plausible report while the mapping is absent would fail the first capability, even if the wording looked convincing. Recovery is successful only when the evidence and controls survive the interruption.

Constructed exercise record

Run the exercise without turning it into an incident

Use a separate, approved test environment and constructed inputs. State the exercise boundary before starting, including whether network access, external writes and distribution are disabled or otherwise controlled. Never remove a live production dependency merely to see what happens. The deliberately missing file belongs only to the exercise copy.

Ask the backup to follow the pack while the builder observes without silently correcting the steps. Record each point where the operator needs information that the pack does not contain. If the builder intervenes to protect the environment, record the intervention and its reason. A coached completion should not be reported as independent operation.

Separate a procedure defect from an access defect. Missing instructions require a documentation change. Missing legitimate access requires the normal access process. An output defect may require changes to the workflow or its checks. Naming the category prevents the team from solving every problem by granting broader permissions or adding another paragraph to the prompt.

Keep an exercise record that another reviewer can understand. Identify the input set, workflow version, operator role, expected result and actual observed result. Record where evidence is stored and whether the run had external effects. Leave those fields blank until a real authorised exercise supplies them; the constructed example is not a substitute.

Choose pass conditions before the exercise. For this workflow, a missing mapping must be detected, guessed categories must be rejected and the restored run must retain source references. The backup also needs to locate the appropriate escalation route. A report appearing in the output folder is only one observation among those checks.

Prepare a fallback that the business can use

The fallback should preserve the essential outcome with a known level of service. For the fictional report, that might be a manually checked status table without generated commentary. The recipient must agree that this is useful during an interruption. Do not describe a fallback as available if no one knows how to produce or approve it.

Decide how a delay is communicated and by whom. A backup operator should not improvise promises about recovery or send an unreviewed substitute. The service owner needs enough information to choose between waiting, using the reduced report and postponing the activity. Put that choice in the continuity pack alongside the technical recovery steps.

Include the evidence that must be retained after a failure. A safe copy of relevant logs and the affected input version can help explain what went wrong. Retention and access still follow the organisation's rules. The continuity pack should identify the approved evidence location rather than encouraging operators to scatter copies across personal folders.

Keep cover current after the first exercise

A handover becomes stale when the workflow changes. Tie review to changes in input format, permissions, output requirements and the people providing cover. A new model or application version can also justify checking the relevant behaviour. Update the pack with the actual change and repeat the affected part of the exercise.

Do not require a full rehearsal after every wording correction. Match the check to what changed. A changed category mapping calls for grouping checks. A changed output destination calls for destination and permission checks. A new backup operator needs an opportunity to demonstrate the whole operating path, including the stop and escalation conditions.

For managers, begin with the workflow whose absence would cause the most immediate disruption. Ask an authorised colleague to explain how it starts, stops and recovers using the current pack. Turn every unanswered question into a specific dependency or instruction. Then arrange the safe exercise. Continuity is established by demonstrated operation under the intended controls.

Copyable continuity prompt

Use only the approved workflow instructions, dependency inventory, constructed
sample inputs and expected-output record supplied. Prepare a continuity pack:
service purpose; authorised inputs and outputs; operating sequence; dependencies;
acceptance checks; stop conditions; secure access request route; fallback; and
recovery exercise. Exclude secrets, credentials, real personal records and
unapproved external content. Do not infer missing configuration or permissions.
Label proposed examples constructed and all untested steps untested.
Identify gaps that prevent another authorised person operating the workflow.
Do not run commands, change access, send messages or publish output.
A responsible technical reviewer and business owner must verify the pack and
approve a separate supervised exercise before continuity can be claimed.

Recovery-exercise checklist

1. Confirm isolated environment, constructed inputs and permitted actions.
2. Identify the workflow and configuration versions.
3. Have the backup locate all dependencies and expected outputs.
4. Omit one exercise dependency and check the stop behaviour.
5. Restore it through the approved route and repeat the affected checks.
6. Record actual results, interventions, defects and acceptance separately.

Workflow continuity pack

Status: operating aid. All sample files, failures and recovery records are constructed. The template is not evidence of a completed exercise.

Service and dependency record

Workflow: [NAME/VERSION]
Purpose and recipient: [OUTCOME/ROLE]
Output state: draft for review
Business owner: [ROLE]
Maintainer and technical escalation: [ROLE/APPROVED ROUTE]
Backup operator: [AUTHORISED ROLE]
Approver: [ROLE]
Approved inputs and versions: [INVENTORY]
Required dependencies and suppliers: [FILE OR SERVICE/OWNER]
Execution environment and relevant version: [ENVIRONMENT]
Effective permissions check: [REVIEW EVIDENCE]
Secret/access request route: [APPROVED PROCESS, NEVER A SECRET]
Operating sequence and expected stage results: [STEPS]
Acceptance criteria: [SOURCE CHECKS]
Stop conditions: [CONDITIONS]
Fallback and recipient agreement: [REDUCED SERVICE/APPROVAL]
Recovery evidence location: [APPROVED LOCATION]
Review triggers: [MATERIAL CHANGES/OWNER]

Constructed dependency map

No item contains credentials. No step includes external distribution.

Continuity prompt

Use only the approved workflow instructions, dependency inventory, constructed
sample inputs and expected-output record supplied. Prepare a continuity pack:
service purpose; authorised inputs and outputs; operating sequence; dependencies;
acceptance checks; stop conditions; secure access request route; fallback; and
recovery exercise. Exclude secrets, credentials, real personal records and
unapproved external content. Do not infer missing configuration or permissions.
Label proposed examples constructed and all untested steps untested.
Identify gaps that prevent another authorised person operating the workflow.
Do not run commands, change access, send messages or publish output.
A responsible technical reviewer and business owner must verify the pack and
approve a separate supervised exercise before continuity can be claimed.

Actual exercise record, leave blank until performed

• Exercise authority and isolated environment: [RECORD]
• Workflow/configuration/input versions: [VERSIONS]
• Operator and observer roles: [ROLES]
• Missing dependency introduced in exercise copy: [ITEM]
• Expected stop: [CRITERION]
• Actual observed behaviour: [OBSERVATION]
• Output/external effects: [OBSERVATION]
• Builder interventions: [DETAILS OR NONE OBSERVED]
• Recovery through approved route: [EVIDENCE]
• Rerun and review result: [OBSERVATION]
• Documentation/access/workflow defects: [DEFECT/OWNER]
• Accepted scope and remaining limitations: [HUMAN DECISION]

Do not prefill observations from the article's constructed narrative. A produced draft is not permission to distribute it. Test missing dependencies only in an isolated approved copy; never remove production inputs to stage an exercise.

Related reading

The golden test set guide covers controlled workflow tests, and Name an Owner for Every Assisted Task covers task ownership. This continuity exercise adds a receiving operator and a recovery dependency.

Also see What the Next Case Manager Needs to Pick Up the Claim, the companion article for 9 November.

Do this Monday

Choose one important workflow. Collect its current inputs, dependencies and acceptance checks. Name a backup and a fallback. Arrange a constructed-input exercise with one deliberate missing dependency and record what actually happens.

References

1. OpenAI: Agent approvals and security
2. Anthropic: Configure permissions