Define an AI workflow by its task, the context it needs, the actions it may take and when a person takes over. Check what happens when information is missing, a tool fails or permission is needed. A useful answer is only one part of completing the work.
When the conversation ends, what should happen next, and who owns it?
01 / Choose a bounded task.
Describe a starting event and an intended end state. For example, a customer asks about an appointment and the workflow gathers enough information to propose a time. The availability check, confirmation and booking are separate actions to design and evaluate.
A bounded task makes the discussion specific. It gives the team a way to ask what information is needed, which systems are involved, and what should happen if the request cannot be completed.
02 / Connect the context to the action.
A conversation may need business knowledge, a script or information from an existing system. An action may need a tool connection and the right permissions. List these separately so a fluent answer is not mistaken for a completed operation.
NYCG’s AI calling example connects a conversation to business context, tool actions and a human handoff. Explore the workflow to see how the request, the action and the next owner fit together.
NYCG: AI calling workflows (opens in a new tab)03 / Define the handoff before testing.
Consider the points where the workflow should ask for clarification, stop, or involve a person. State who will receive that handoff and which information they need. Those decisions are part of the workflow, not just the wording of a message.
NIST’s AI Risk Management Framework includes defining and documenting human oversight, assigning responsibilities, and evaluating systems in their deployment context. Apply that principle to the task in front of you rather than assuming that a human-review label is sufficient.
NIST: AI RMF Core (opens in a new tab)04 / Test what the workflow actually does.
Prepare examples of the ordinary request, an ambiguous request and a request the workflow should not complete. For each example, define the expected response and the expected next step.
Review the action as well as the conversation: was the requested change made, was it left for review, or did the workflow stop? A clear account of those states gives you a better basis for deciding what to change next.
- The trigger and intended outcome
- The information and systems involved
- The permitted action
- The point for clarification or human review
- The evidence that the next step happened
A workflow that can fail usefully
- Ordinary request
- A caller asks for an appointment. The workflow checks availability, asks the caller to confirm and reports the result returned by the scheduling system.
- Missing information
- The caller has not specified a service. Ask for clarification before searching for an appointment.
- System unavailable
- Availability cannot be checked. Explain the limitation and prepare a handoff; do not announce a booking.
- Uncertain result
- The system times out after a booking request. Check the existing request before retrying so the caller is not booked twice.
- Human handoff
- Give the receiving team the request, information collected, action attempted and what remains unresolved.