One product workflow, across its system boundaries.
Model the work before drawing the screen
Take a content-publishing workflow. Generating a draft, approving it, scheduling it and publishing it are different actions. Give each a defined state and an owner. A user should be able to see whether an item is saved, waiting for approval or actually published.
Put authority in the backend
Check the user’s permission when the action is executed. Validate model output against the operation it will feed. Treat generated content and tool requests as untrusted inputs, and keep credentials and privileged integrations on the server.
Design the retry path
A network timeout may leave the client unsure whether a request succeeded. Repeating it blindly can duplicate a business action. Define request identity, idempotent processing where needed and a way for the client to retrieve the result. Where a database change must produce a message, consider an outbox pattern and idempotent consumers.
Show uncertainty honestly
Loading, queued, retrying and failed are useful states. They should lead to a next action, not an endless spinner or a false success message. If a workflow needs human approval, preserve that step even when an AI service can generate the next input.
Agree what release-ready means
Test the complete journey, including denied permissions, interrupted connectivity, duplicate requests and unavailable dependencies. Measure the outcome the user needs. The first release should include a way to investigate failures and support the system after launch.