AI-assisted workflows

A recurring task with recognizable inputs and an observable end is a practical starting point. A request arrives with supporting material; someone needs to inspect it and decide what happens next. We build the application around that task, then use AI where it can help prepare the work.

The model might suggest a response, extract candidate details or find relevant guidance. A fixed rule may be the better choice for a permitted status change or a required field. We can combine those approaches within the same application instead of forcing every part of the process through a prompt.

A proposed action needs to survive more than one browser session. The application can retain the request, selected sources, generated material and edits so the next person sees the work in context. Saving a draft should not also imply permission to perform an external action.

The local example on this site uses a made-up delivery-change request. It prepares a proposed reply and lets a reviewer approve the example. It does not contact a customer or change a delivery. A production build would need the connected systems, authorization rules and action results agreed for that particular workflow.

A reviewer needs the parts of an action that can change its consequences. For a message, that includes its recipient, content and attachments. For a record change, it includes the target record and the values being replaced. We design the review view around those details rather than a single approval button beside a generated paragraph.

The permission to review an item may differ from the permission to execute it. Some actions can be performed by the application after a specific approval; others may require the person to complete the final step in the receiving system. That choice depends on the business rules and on the supported integration.

A reviewed item may still be waiting for another team or connected system. The application needs to make that waiting state visible and show who is responsible for moving it on. Otherwise an item can disappear from the review queue while the work itself remains unfinished.

We define which states appear in each team’s view and what a person can do from them. That may include returning an incomplete request, assigning a reviewer or opening the result in the receiving system. A resumed task should carry its saved context, so the next person can establish what has already happened. The approval-records note examines the more detailed case of an uncertain external action.

We use representative tasks to check how the whole application behaves. Those examples can include a useful draft, unsupported source material, an edited recipient, a withdrawn approval and an interrupted external action. The expected outcome should be understandable to the people doing the work.

A useful first release keeps its boundaries clear. It may handle one request type and one connected action well while leaving unusual cases with a person. Extending that boundary later is a software change with new examples to check, rather than an assumption that one successful demonstration covers every task.