Adding Configurable Rules and AI Steps to a Hard-Coded Workflow Engine

Picture a workflow system whose steps are defined in code and always run the same fixed, deterministic way. As a product manager, how would you approach making it more configurable and adding AI capabilities to it? ```hint Decide what must stay deterministic Some steps can tolerate an answer that is usually right; others, such as anything that moves money or makes a compliance decision, must give the same result every time. Sort the steps before deciding where AI goes. ``` ### Clarifying Questions - Who should be able to change a workflow: internal operations staff, engineers, or the business clients whose processes run on it? - What kinds of processes does the system run today, and which steps move money or make regulated decisions such as identity or fraud checks? - What is prompting the change: a backlog of engineering requests for workflow edits, a growing manual review queue, or clients asking for custom logic? - What audit and explainability obligations apply to the decisions a workflow makes? ### What a Strong Answer Covers - A diagnosis of who is held back by the hard-coded system, and how, before any solution is proposed. - A configuration model: how workflows are defined, validated, tested, versioned and rolled back, and who may change what. - Where AI adds value and where deterministic logic must remain, with human review, confidence thresholds and fallbacks for AI steps. - Reliability, auditability and reproducibility of runs that include AI steps, including model outages and cost. - A phased rollout with success metrics and guardrails. ### Follow-up Questions - An AI step and a fixed rule reach different conclusions on the same case. Which one wins, and who sets that policy? - A configuration change breaks a live workflow for several hours. What should have prevented it or limited the damage? - How would you let a user describe a new workflow in plain language and have AI draft it without weakening safety?