Rowan Cheung: Map an AI Announcement to a Checkable Workflow
When an AI announcement promises a new way to work, how can I tell what would actually happen in my task?
Choose, practice, reflectA practical learning exercise
The Lesson
“AI agents can transform your workflow” leaves a lot unanswered. Which information goes in? What does the system produce? Who checks the result? What happens if something is missing?
In a May 2025 interview published under Rowan Cheung’s byline, UiPath founder Daniel Dines describes combining AI models, automation and human expertise in workflows. This is Dines’s explanation of his company’s approach. It is a useful starting point for asking how those roles would fit a specific task, rather than assuming that a product announcement proves the entire task will work reliably.
A current, concrete example appears in UiPath’s documentation for a Human node: a process can pause for a person’s review, approval or input, then continue after they complete the task. The general question you can take into your own planning is: where would the process need a person’s response before proceeding?
You do not need to buy that platform to investigate the question. Draw the steps of a task you understand. Separate interpreting information, following a specified rule and deciding whether to use a result. One application might perform several of these steps, but the responsibilities still need to be clear.
Consider a fictional community workshop receiving a question about what to bring. An assistant could prepare a reply from the organizer’s approved information sheet. A specified check could flag an unanswered field. The organizer could review the draft. Sending the reply would be a separate action. Treating all four as “answer the message” makes it harder to see a missing check or an unauthorized decision.
The distinction matters even when a draft looks polished. A reply can be fluent while using an old venue, inventing a supply requirement or overlooking the person’s actual question. A named reviewer needs access to the information that would expose those errors. Merely writing “human review” on a diagram does not explain what that person will inspect.
Reflection
- What does the announcement actually demonstrate, and what am I assuming?
- Which input would my task require?
- Where does a draft become an action someone else experiences?
- What information would a reviewer need to accept, change or reject it?
Practice
Original SelfGrowthVideos exercise: walk through one workflow on paper. This is our exercise, not Rowan Cheung’s or UiPath’s prescribed method.
Use fictional workshop details. No accounts, connected tools or real messages are required.
- Define the input. Invent a short question: “What should I bring to Saturday’s drawing workshop?” Make a separate information card stating the date, venue and confirmed materials.
- Describe the draft step. Write what an assistant would receive and what it should return: a proposed reply grounded in the information card, with unanswered questions left visible.
- Name one rule. For example, the workflow must not proceed if the materials field is empty. Write down what happens instead: ask the organizer to supply the missing information.
- Specify the person’s review. The organizer compares the draft with the information card, checks that it answers the question and chooses accept, revise or reject. Explain what each choice does next.
- Separate the final action. Put “send the approved reply” in its own box. In this paper trial, only describe the action; do not connect an inbox or send anything.
- Walk through a problem case. Remove the venue from the information card. Trace the steps again. Does your diagram stop for the missing detail, or does it quietly allow an invented venue?
Mark the exact place where each question gets resolved. If you cannot identify who resolves it or which source they use, circle that gap. Add one sentence describing what would be needed to test that step in a later prototype.
Review
Revisit your diagram after the missing-detail trial. Did the reviewer receive enough context? Could a rejected draft still reach the final action? Which responsibility remains unclear?
Change one step and repeat the paper walk-through. Keep the result modest: you have clarified a proposed workflow and its open questions, not established that a deployed system will behave the same way.