A commercial-credit copilot cut the time needed to draft a review memo. Analysts liked it and the output read well. End-to-end completion barely moved. They still searched three systems for evidence, reconciled conflicting figures in a spreadsheet, rekeyed approved fields and waited for the same committee. The pilot had accelerated one visible task without changing the vertical outcome.

That result was useful. The assistant revealed which evidence analysts sought, where policy interpretation varied and which parts of the memo were routine. It was a diagnostic and adoption surface. It was not yet a transformation architecture, because the process state, decision rights, control gates, exception return paths and downstream constraint remained outside it.

A vertical workflow begins at completion rather than at the interface. For credit, completion may mean an authorised decision, executed terms, a customer communication and a control receipt. For complaints, it may mean redress delivered, the customer informed, conduct evidence retained and root-cause obligations assigned. The design works backwards through the state and evidence required for each transition.

This move is not a maturity ladder. Some work should remain a bounded copilot because variation is high and authority remains personal. Some should use deterministic workflow support because rules are stable and consequence is material. Some recurring flows justify a human-AI redesign, a small subset supports bounded agent execution, and some judgments should remain human-led.

Architecture choiceA copilot is sometimes the correct endpoint

Copilots fit exploratory work, novel cases and tasks whose inputs or desired forms change frequently. They can help a person search, compare, draft or question while the person retains responsibility for framing and action. Their loose coupling reduces integration cost and allows rapid adaptation. That flexibility is valuable when no stable unit of work or outcome boundary exists.

They also fit personal authority. A strategist exploring scenarios or a lawyer developing an argument may need modular assistance without turning the work into a centrally orchestrated flow. Instrumentation can observe recurring patterns, but forcing every thought into a state machine would remove useful variation and create brittle procedure.

The limitation appears when the business case claims an end-to-end result. A local task dividend cannot be multiplied across volume while downstream queues, approvals and capture stay fixed. The copilot owner must report the task effect and the vertical constraint separately. This distinction keeps a useful tool from carrying a transformation claim it has not earned.

Davenport and Short argued that information technology and process redesign should be considered together, with business processes treated as the object of analysis rather than existing functional silos.[1] The principle remains relevant, but today’s architecture has to distinguish deterministic services, model inference, human judgment and tool-using agents rather than treating technology as one uniform capability.

End-to-end redesign is appropriate when decision episodes recur, authoritative states can be observed, outcomes can be evidenced, exception types are bounded and coordination loss is material. It also requires an executable control boundary. A flow diagram is not an operating design if its system writes are unauthorised, the human review box has no capacity or exceptions disappear into unowned work.

The architecture decision should be preserved as a falsifiable record, not a slide that disappears after funding. It names the outcome and eligible population, shows the measured constraint, compares the five allocation modes at each consequential step and states which facts would reverse the choice. A team selecting a vertical workflow should therefore specify why a bounded copilot cannot release the constraint, why deterministic support is insufficient and which judgment still requires a person. It should also identify modular boundaries.

Evidence preparation, eligibility calculation, recommendation and authorised action can be separately replaced when their contracts expose inputs, outputs, authority and receipts. This keeps redesign from becoming a single irreversible platform bet. Review dates are triggered by operating evidence such as a new exception class, changed policy, deteriorating outcome quality or a cost range that crosses the value range.

The choice is economic as well as technical. Integration, state reconstruction, control engineering, workforce transition and ongoing monitoring may exceed the value available from a small or volatile process. Reversibility matters: a bounded copilot can be removed easily, while a vertical workflow may change roles, contracts and systems of record. The Studio therefore compares full cost and reversibility, not automation appeal.

Original synthesisThe six-spine redesign contract

The vertical workflow redesign contract keeps six kinds of truth aligned around one completed outcome. Each spine has its own owner and evidence, but they meet at transition boundaries. Omitting one produces familiar failures: activity without outcome, chat without state, recommendations without authority, automation without recovery or role change without capacity planning.

The outcome spine prevents an organisational chart from becoming the target architecture. “Transform underwriting” is not a completion condition. “Issue an authorised decision and terms to an eligible applicant within the stated window, with evidence and an appeal route” is closer. It specifies what the flow must deliver without predetermining which team or technology performs every step.

The state spine distinguishes an authoritative transition from conversational context. Messages may explain an event, but they do not become the case record by implication. Each transition records prior state, triggering event, evidence version, valid time, actor or service, resulting state and restart point. If an exception leaves the main path, its return condition is explicit.

The decision spine prevents a recommendation from silently acquiring authority. It identifies the alternatives, uncertainty, consequence and person or service empowered to choose. The execution spine then performs permitted actions. Recommendation and execution can be adjacent, but they are not collapsed unless the operating policy explicitly authorises bounded automatic action.

The control spine expresses policy intent rather than preserving every inherited approval. Designers ask which risk or obligation a gate controls, whether another mechanism can satisfy it and what evidence proves operation. A historical approval may be redundant; a segregation requirement may remain essential. Removing procedure is redesign only when the underlying intent is still met.

The workforce spine treats role change as architecture. Faster preparation can concentrate harder cases on senior reviewers, create a new exception queue or remove developmental work from junior staff. Capacity, proficiency, job design, consultation and transition cost belong in the same contract as model and integration choices. Task research shows that technology can substitute for some activities while creating or changing others.[2][3][4]

The six spines also share a version boundary. A release is not merely a new model: it is the exact bundle of outcome definition, state schema, decision policy, execution permissions, controls and staffing assumptions operating together. The outcome receipt stores that version so investigators can reconstruct what the workflow knew and was allowed to do. Change control then follows dependency rather than organisational ownership. If a policy threshold changes, the team checks rule logic, model context, customer notice, reviewer capacity and historical comparability.

If an exception rate rises, the workflow owner tests whether the cause is source data, model behaviour, policy ambiguity or insufficient proficiency before adding another approval. This shared versioning prevents one spine from quietly invalidating the others and makes rollback a coherent operating act rather than a software-only reversal.

Function allocationChoose the mode step by step

Each step receives one primary allocation. Deterministic execution handles stable rules, validation, calculations and routing where the inputs and authority are clear. Model-assisted preparation gathers, classifies, drafts or compares while a person controls the decision. Model recommendation presents an option and uncertainty to an authorised human. Bounded agent action executes a narrow, reversible action under verified preconditions. Human-only judgment remains where meaning, authority or variation cannot be safely encoded.

These allocations are not status levels. A deterministic eligibility calculation may be more reliable and transformative than an autonomous model. A human-only conduct judgment can coexist with automated evidence assembly. The aim is a coherent operating flow, not the maximum count of model calls.

Parasuraman, Sheridan and Wickens distinguish types and levels of automation across information acquisition, analysis, decision selection and action, which helps avoid treating automation as one switch.[7] Human-AI interaction guidance likewise emphasises timing, correction, explanation and graceful failure across the interaction lifecycle.[9] The contract applies these ideas to production transitions and authority.

Before assigning a model, designers test whether a deterministic service can express the policy. Stable identity checks, limit comparisons, mandatory disclosures and entitlement rules usually benefit from explicit logic. Models may prepare evidence for those checks, but uncertainty should not be introduced where the rule is already known.

Before assigning an agent, designers verify identity, tool scope, preconditions, write authority, idempotency, observability, stop controls and recovery. An agent that can open broad tools before these exist is not a transformed workflow. It is an unauthorised execution path with conversational camouflage.

Human review needs a service design. The contract names the queue, capacity, proficiency, information shown, response time, intervention rights and escalation route. If the predicted exception volume exceeds staffing or no return path exists, “human in the loop” is an empty box. The workflow fails at that point even if the automated path performs well.

Operational truthState, evidence, exceptions and restart

State must be reconstructable without replaying chat. The system of record holds the authoritative case status; event records explain how it changed. Model context may include conversation, but the workflow does not infer whether an action happened from prose. This distinction supports audit, safe retries, handoffs and customer explanation.

Evidence has valid time and provenance. A bank statement, policy version or customer instruction may be true at one transition and stale at another. The state spine links each decision to the evidence version available then. Later updates create new events rather than rewriting history. This is necessary when an outcome is challenged or a model version changes.

Exceptions need a topology. Designers enumerate detectable exceptions, ambiguous exceptions and unknown failures. Each route has an owner, service target and return condition. A manual side channel that never updates the main state creates two workflows and weakens every later control. Exception completion must return a signed event to the authoritative rail.

Restart points prevent recovery from duplicating actions. After a timeout, the system knows whether a payment, notification, limit change or case creation completed. Idempotent requests, action receipts and reconciliation jobs matter more than a fluent recovery message. Bounded agents are feasible only when the execution spine can prove this state.

Process mining can reveal the actual event paths, variants, loops and queues that differ from the documented procedure, provided event data are sufficiently reliable.[8] It is especially useful before redesign, because informal work may handle genuine variation. The team captures why it exists before standardising or removing it.

Exception capacity must be tested against a distribution, not an average. The team estimates arrival volume by exception class, burst behaviour, handling time, required proficiency and the share that returns for more evidence. It then rehearses a stressed day with model abstention, an unavailable system of record and a policy clarification arriving mid-queue. The test asks whether priority rules protect high-consequence cases, whether staff can see the relevant state and whether every intervention produces a return event. Capacity evidence also constrains launch scope.

A route that works for one region or product may fail when a different evidence pattern enters the same queue. Scaling gates therefore use observed tail volume, queue age and successful return rates. When these cross limits, the system narrows eligibility or reverts to the previous safe mode rather than allowing hidden work to accumulate.

Negative controlsWhere apparent progress fails to complete

Copilot overlay

The credit assistant drafts well, but analysts still reconcile evidence, rekey results and wait for the same approvals. The correct receipt is a drafting dividend plus diagnostic evidence. Claiming full completion value would count queue time the copilot never changed.

Chat as workflow

A conversational front end asks questions and invokes tools, but state transitions live in messages. It cannot prove which evidence supported an action, whether a write completed or where an exception should restart. The design needs an authoritative state and event rail behind the dialogue before it becomes a workflow.

Automation islands

Classification, drafting and quality checks each become faster. The same scarce reviewer still controls completion, and their queue grows because upstream steps feed it more quickly. Local productivity has amplified work-in-progress. The redesign must address capacity, threshold, routing or decision allocation at the constraint.

Premature agent

An agent receives broad system access before deterministic policy gates, workload identity, write boundaries and recovery exist. Successful demonstrations do not establish safe production action. The correct route is bounded preparation or recommendation until the execution and control spines can verify preconditions and reverse failures.

The downstream constraint is tested after every proposed improvement. If faster evidence assembly does not change the rate at which authorised decisions leave the reviewer queue, the design has not improved completion. It may still reduce cost or improve quality, but those receipts are reported on their own terms.

Worked verticalsCredit and complaint resolution

In commercial credit, the before-state is fragmented: an analyst opens documents, searches systems, calculates ratios, drafts the memo, requests missing evidence, rekeys fields and submits to an approver. The copilot improves drafting. The redesigned flow gives the case an authoritative identifier and evidence state, uses deterministic validation for required fields and calculations, applies model assistance to unstructured evidence, and preserves approval authority with the named credit officer.

The model may recommend a risk interpretation with cited evidence and abstain on unsupported cases. Deterministic policy checks prevent disallowed structures before the recommendation reaches the decision owner. After approval, bounded services write terms and produce a customer communication only under signed authority. Exceptions return to the evidence state with a reason and required action. The outcome receipt joins decision, terms, customer notice and control evidence.

This architecture does not automate the credit officer by implication. It removes duplicate assembly, makes evidence provenance explicit and narrows the judgment to the consequential alternatives. Revised US model-risk guidance emphasises risk-based governance, validation and controls tailored to model profile and use.[12] The operating boundary determines which model outputs are advisory and which deterministic services may act.

A complaint-resolution flow provides a different allocation. Intake and identity checks are deterministic where possible. A model can classify the issue, extract chronology and assemble cited policy and interaction evidence. A caseworker evaluates remedy and conduct consequence. Low-risk acknowledgements or status updates may be executed by a bounded agent, but redress and final resolution remain under the authority defined by policy.

The flow carries redress, conduct and customer receipts. If the complaint reveals a systemic issue, an event creates a root-cause obligation rather than hiding it in the case narrative. If evidence is missing, the exception returns to collection with a time-bound customer update. Closure requires both the customer action and the control evidence; an internal status change alone is not completion.

This counter-case succeeds because its state, evidence, exception and authority boundaries are observable. It does not rely on the conversation to remember what happened. It also plans capacity for the hard cases concentrated on caseworkers. The workflow owner remains accountable for completion even though different services and people own individual transitions.

Authority and transitionControls, recovery and workforce evidence

NIST’s AI RMF asks organisations to define roles, responsibilities, context, impacts, monitoring and response, while its human-AI appendix stresses that interaction results vary and oversight roles need differentiation.[10][11] A generic human approval after the model acts does not satisfy this. The contract ties authority to specific transitions and gives people the information and time required to intervene.

Articles 14 and 15 of the EU AI Act address human oversight and accuracy, robustness and cybersecurity for high-risk systems.[13] Their practical implication for workflow architecture is that oversight, technical performance and resilience cannot be bolted onto a finished orchestration. The control and execution spines must make intervention, monitoring and safe failure possible by design.

ISO/IEC 42001 frames AI management as an organisational system with objectives, responsibilities and continual improvement.[14] The vertical owner therefore governs changes across model, rules, queues and roles. A model version can alter exception volume; a policy change can invalidate prompts; a workforce change can remove recovery capacity. Releases are evaluated as workflow versions, not isolated components.

Field studies of generative assistance show that effects differ by worker experience and task boundary.[5][6] Transition planning measures who gains preparation speed, who receives harder residual work, what knowledge is lost and which new coordination roles appear. Training is tied to the future role, not generic tool familiarity.

Completion receipts connect economics to the design. They record elapsed time, quality, adverse outcomes, human effort, exception demand, system cost, control evidence and customer result for the eligible population. Local step metrics remain useful diagnostics, but no step books the whole vertical benefit.

Operating ownership is singular even when transition ownership is distributed. One accountable owner resolves conflicts between product, operations, risk, data and technology, maintains the state definition and convenes re-gating when outcomes or authority change. Without that owner, the six spines can become six documents that drift independently.

Migration is a controlled change of operating state. Before live traffic moves, the team replays representative histories, shadows the new flow and reconciles its receipts with the current process. It rehearses loss of a model endpoint, delayed evidence, a failed write, an overloaded review queue and rollback after some actions have completed. Entry criteria cover technical performance, operating capacity, customer communication and workforce readiness; exit criteria define the smallest safe unit that can revert. Early production uses a narrow eligible population and paired outcome measurement. The comparison is not merely new versus old average time. It tests whether the redesigned population improves completion, quality and effort without exporting harm to excluded cases, reviewers or downstream teams. Only a receipt that reconciles customer, control, workforce and economic effects supports expansion.

Interactive instrumentCopilot-to-Workflow Redesign Studio

The Studio selects an architecture route from observable state, variability, constraints, authority, controls, workforce change and economics. It does not reward maximum autonomy. Each result names the target layer and missing evidence needed before commitment.

ConclusionRedesign the completion system, not the interface alone

A copilot can be a valuable endpoint, a diagnostic or one component inside a larger flow. Its local gain becomes a vertical transformation only when state, evidence, decisions, execution, controls and roles are deliberately reassembled around a completed outcome. The downstream constraint decides whether task speed becomes completion value.

Choose function allocation step by step. Prefer deterministic services for stable consequential rules. Use models for bounded variable work with abstention. Preserve named human authority where consequence demands it. Permit agent action only under verified identity, preconditions, least privilege, action receipts and recovery. Keep irreducibly variable or personal work human-led.

The operating contract closes with customer, outcome, control and workforce receipts. It owns exceptions, restarts and transition capacity. Progress is not measured by how autonomous the interface appears, but by whether the completed outcome improves within a credible, recoverable and economically justified architecture.

Evidence spineReferences

1. Davenport, T. H. and Short, J. E. (1990), ‘The New Industrial Engineering: Information Technology and Business Process Redesign’, Sloan Management Review, 31(4), 11–27. MIT Sloan Management Review.
2. Autor, D. H., Levy, F. and Murnane, R. J. (2003), ‘The Skill Content of Recent Technological Change: An Empirical Exploration’, The Quarterly Journal of Economics, 118(4), 1279–1333. doi:10.1162/003355303322552801.
3. Acemoglu, D. and Restrepo, P. (2019), ‘Automation and New Tasks: How Technology Displaces and Reinstates Labor’, Journal of Economic Perspectives, 33(2), 3–30. NBER Working Paper 25684.
4. Acemoglu, D., Kong, F. and Restrepo, P. (2024), ‘Tasks at Work: Comparative Advantage, Technology and Labor Demand’, NBER Working Paper 32872. doi:10.3386/w32872.
5. Brynjolfsson, E., Li, D. and Raymond, L. R. (2023), ‘Generative AI at Work’, NBER Working Paper 31161. doi:10.3386/w31161.
6. Dell’Acqua, F. et al. (2023), ‘Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality’, Harvard Business School Working Paper 24-013. HBS working paper.
7. Parasuraman, R., Sheridan, T. B. and Wickens, C. D. (2000), ‘A Model for Types and Levels of Human Interaction with Automation’, IEEE Transactions on Systems, Man, and Cybernetics, Part A, 30(3), 286–297. doi:10.1109/3468.844354.
8. van der Aalst, W. M. P. et al. (2012), ‘Process Mining Manifesto’, in Business Process Management Workshops, LNBIP 99, 169–194. doi:10.1007/978-3-642-28108-2_19.
9. Amershi, S. et al. (2019), ‘Guidelines for Human-AI Interaction’, in Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems, Paper 3, 1–13. doi:10.1145/3290605.3300233.
10. National Institute of Standards and Technology (2023), ‘AI Risk Management Framework: Core’. NIST AIRC Core.
11. National Institute of Standards and Technology (2023), ‘Appendix C: AI Risk Management and Human-AI Interaction’. NIST AIRC.
12. Board of Governors of the Federal Reserve System, Office of the Comptroller of the Currency and Federal Deposit Insurance Corporation (2026), ‘Revised Guidance on Model Risk Management’, SR 26-2. Federal Reserve letter.
13. European Union (2024), Regulation (EU) 2024/1689 Laying Down Harmonised Rules on Artificial Intelligence, Articles 14–15. Official Journal text.
14. International Organization for Standardization and International Electrotechnical Commission (2023), ‘ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system’. ISO standard record.