article · cross business
Run a weekly maintenance check on an AI workflow
Run a weekly review of workflow failures, approvals, permissions, costs, sources, and test results, with a clear owner and evidence for restarting.
The direct answer
Give the workflow a named owner and backup who check failures, duplicates, approval backlog, source changes, access, usage, and sample outputs. Record decisions and next actions. A weekly review is a routine minimum for this teaching pattern; urgent failures require action when they occur.
A maintenance example
Synthetic scenario: A support FAQ location changes while the workflow still supplies its old revision. Drafts sound reasonable but direct readers to the wrong place. The owner pauses drafting, identifies affected pending items by source version, corrects the source, reruns the fixtures, and resumes only after reviewing the results.
This is a proposed response, not an incident report. Automatically updating the “last tested” date would not establish that the new source works.
Owner checklist
| Check | Evidence to inspect | Decision to record |
|---|---|---|
| Run failures | Failed, incomplete, and stuck runs with stable IDs | Cause, owner, retry or reconciliation plan. |
| Duplicates | Ledger versus destination records | Whether extra effects occurred and which items need repair. |
| Approvals | Pending age, rejected and expired items | Escalation or manual handling; never auto-approve backlog. |
| Draft quality | A varied sample including exceptions and corrected items | Supported facts, missing details, and new test cases. |
| Source freshness | Approved source versions and owner notices | Update, withhold, or retain sources with a reason. |
| Permissions | Connected accounts, scopes, departing users, credential state | Revoke unnecessary access; repair only authorized access. |
| Cost | Actual usage, subscriptions, review time, and maintenance time | Compare with assumptions and investigate unexpected growth. |
| Regression tests | Fixture versions and observed rerun results | Continue, narrow scope, or stop. |
| Ownership | Owner, backup, next review, open actions | Confirm coverage and action due dates. |
Read logs without collecting everything
Logs should identify runs, versions, statuses, errors, and destination IDs needed for recovery. Restrict access and retention according to the actual information involved. Avoid copying full customer messages or credentials into a broadly shared maintenance sheet.
Compare the count of accepted source items with completed, pending, rejected, and failed items. An unexplained gap can matter even when no error appears. Record how counts are defined so retries do not inflate apparent volume.
Stop, repair, and resume
Pause the trigger on unexpected access, unauthorized actions, repeated duplicate effects, unsupported commitments, or an unmanageable review backlog. Assign unresolved items to the manual process. Keep the action ledger intact so recovery does not replay completed work.
Fix the cause, then rerun the affected cases and the relevant regression set. Confirm manual fallback and duplicate recovery still work. The owner records why resuming is justified and which limits remain. Do not turn scheduling back on simply because an error message disappeared.
Limits and non-example
A weekly “looks fine” checkbox without evidence is not maintenance. A successful connection check does not establish correct source use, draft accuracy, or approval behavior. Increased volume may require more frequent reviews even when the design has not changed.
Practice exercise
Give the backup a synthetic failed run, a stale FAQ, and a pending approval. Ask them to identify what stops, what remains manual, and what evidence permits resuming. If they need undocumented knowledge from the builder, add it to the operating procedure.
Sources and scope
This is an original operating routine with a synthetic incident scenario. It does not claim a monitored production system or a service-level commitment.
Next step
Put the owner, backup, stopping rule, and review routine in the workflow brief. Suggest a correction.
Change notes
Foundation draft prepared October 20, 2026. No public publication or successful live-tool test is claimed.
Next learning step: One-page workflow brief