The demo worked. Then the source went offline.
“Prepare a renewal email from the current agreement.”
An account manager asks an assistant to prepare a renewal email. The assistant finds the agreement, reads the relevant dates, and produces a reasonable draft. Everyone in the room can see how this would help. Now disconnect the document store and ask again.
That small interruption changes the conversation. Can the assistant tell that its source is missing? Does it reuse something from yesterday? Does the account manager know whether a draft was saved? A production plan starts to take shape when the team works through those questions with the same care it gave the first successful answer.
Make a promise you can finish
For this example, the promise is deliberately narrow. The assistant prepares a renewal draft using the current agreement. A person checks it and decides whether to send it. The assistant does not choose commercial terms or send a message. That boundary gives the team a complete task to build and a result the account manager can judge.
Even a narrow task has real integration work. The agreement belongs to a particular account. The person asking must be allowed to read it. Its dates need to mean the same thing in the document store and the account system. The saved draft needs a stable place to live, so refreshing the page does not make the user wonder whether the work disappeared.
Connect that whole path early. A copied document can help settle the first product question, but it cannot tell you how the actual permissions, versions, and save behavior will work together.
Keep the request.
Change the day.
Change the source or permission condition and follow where the renewal draft request stops.
- 01
Check access
Who is asking?
Permitted - 02
Read the source
Current agreement
Retrieved - 03
Prepare a draft
Source-linked wording
Prepared - 04
Save the work
Recoverable result
Saved - 05
Human review
Before any send
Your move
A draft is ready for a person.
The agreement was available and the account manager could read it. The assistant prepared and saved a draft, with its source attached.
One draft saved · Nothing sentReview the wording and terms. Sending remains a separate human decision.
Run the same request three ways
The ordinary request should produce a draft with its source attached. When the source is unavailable, the assistant should stop before composing agreement-specific claims and tell the user what is missing. When permission has changed, it should stop before reading. These are different outcomes with different remedies. Retrying an outage may help. Retrying with the same revoked access will not.
Notice how much of the work stays the same when only one condition changes. The account manager still wants the draft. The request still needs an identity and an account. What changes is how far the system can responsibly take the work and what it owes the user when it stops.
This is also a useful way to define acceptance. Ask someone outside the implementation team to follow each route and explain what happened. If they cannot tell whether anything was saved or sent, the interface still has work to do.
Leave enough behind to recover
Suppose the save completes but the browser loses the response. The user clicks again. That second click should not create a second business action by accident. Give the request a durable identity and design the save operation so a retry can find the existing result. Test the interruption at the point where it can happen.
An operator also needs to find that request. Record which workflow version ran, which source version it read, what the tools returned, and where it stopped. Keep document contents out of routine logs when a controlled reference will do. A useful trace answers a concrete support question without making every log reader a document reader.
Choose limits for time, cost, and retries before real users arrive. An assistant that keeps trying forever is difficult to operate and difficult to trust. A saved, understandable pause is often a better user experience than another minute of unexplained activity.
Bring the awkward requests to the release meeting
Keep a set of examples that includes missing sources, conflicting dates, changed permissions, and repeated submissions. Add the failures found during development, but keep some examples aside so a change is tested on more than the cases used to tune it. Review the consequential errors individually. An average score should not hide an unauthorized read.
NIST’s AI Risk Management Framework is a useful reference for tying evaluation to the setting a system will be used in. For this small assistant, the release evidence can stay concrete. Show the supported task, the difficult requests, the saved results, and the recovery path. Name the person who will respond when the source goes offline on an ordinary working day.