When you ask an AI agent to complete a multi-step task, you hand over a single natural-language prompt and get back a result. Everything that happens in between, the tool calls, the file manipulations, the branching logic, the error recovery, happens behind a veil of fragmented execution logs. You see the output. You might not see how the agent got there, whether it made mistakes along the way, or how to change the process for a slightly different task next time. A new paper from Saarland University, Microsoft Research, and the Singapore-MIT Alliance for Research and Technology tackles this problem by proposing post-task workflows: editable, graph-based representations of what the agent actually did, presented after execution completes.
The Transparency Gap in AI Agents
AI agents automate complex tasks by decomposing a single request into a sequence of actions across tools, files, and applications. But this automation shifts the user's role rather than eliminating it. Instead of carrying out the task, you now oversee the agent's execution, understand what it did, and validate the result. Existing agent interfaces expose execution artifacts, action traces, tool calls, intermediate outputs, and final results. Claude Cowork shows task progress and the agent's current activity during execution. These artifacts help, but they scatter information across many actions, tools, and outputs. Users must mentally reconstruct the end-to-end process from fragments.
The researchers drew inspiration from workflow automation platforms like n8n, Node-RED, and Zapier, where graph-based representations externalize the operations and dependencies involved in completing a task. Nodes represent operations, tools, or artifacts. Edges capture data flow, control flow, or dependencies. Together, these elements provide a structured view of how the different parts of a process fit together. The question was whether presenting such a graph after an agent completes a task, as a descriptive artifact rather than a prescriptive specification, could help users understand, validate, and reuse the execution.
What Real Workflows Look Like
Before building anything, the team analyzed 10,803 public workflow templates from n8n to characterize real-world automation practice. The templates covered five main domains: customer operations (28%), data analytics (22%), personal assistance (22%), content production (19%), and other (9%). The median workflow had 17 nodes and 12 edges, with a longest path of 8 steps. Purely sequential workflows were rare (17%). Most contained at least one branch or merge (49%), and about a quarter contained cycles.
The node functions broke down into four categories. Task-action nodes appeared in 94% of workflows, with HTTP Request (50%), Google Sheets (33%), and Gmail (20%) being the most common. Workflow-control nodes appeared in 87%, dominated by If (45%), Merge (20%), and Split In Batches (18%). Data-processing nodes appeared in 82%, led by Code (54%) and Set (52%). AI-supported nodes appeared in 51%, with AI Agent (34%) and OpenAI Chat Model (24%) as the most frequent. This analysis informed the design space for Trace2Flow, the system the researchers built to translate agent execution traces into post-task workflows.
Trace2Flow: From Execution Trace to Interactive Workflow
Trace2Flow is a research probe with two interfaces. The left side is a chat interface where users delegate tasks to an AI agent through natural language, with a progress panel showing major steps and execution status. After the agent completes, a button translates the execution trace into a post-task workflow displayed on a graph canvas. The right side shows the workflow: nodes represent operations (file operations, data processing, AI tasks), and edges show data dependencies. Users can click any node to inspect its inputs, outputs, and parameters in a configuration panel, modify values, rerun individual steps, add or remove nodes, change connections, and rerun the full workflow.
The translation pipeline has three stages. Grounding examines the agent's execution trace and matches tool executions to workflow node specifications, retaining expected inputs, outputs, and example outputs observed during execution. Given the grounded node catalog, an LLM reconstructs the execution as a compact intermediate representation, determining which operations are needed, how they should be configured, and how data passes between them. The intermediate representation uses symbolic references like "list_1.files" to indicate that a downstream node consumes the files output from an upstream node. Compilation converts this representation into the structured graph, instantiating nodes, converting symbolic references into explicit input bindings and edges, and checking that all referenced nodes exist and outputs are compatible with expected inputs. If a check fails, the system feeds the error back to the LLM for one regeneration attempt.
The User Study
The researchers conducted a within-participant study with 20 regular AI-agent users. Each participant reviewed agent executions and completed follow-up tasks under two conditions. In the chat condition, they reviewed execution through the chat interface alone and completed follow-up tasks by writing a new prompt. In the workflow condition, they additionally had access to the post-task workflow graph and completed follow-up tasks by adapting and rerunning the workflow. Five task pairs were used, each with a review task (containing a deliberate error) and a related follow-up task. Tasks spanned data analytics, customer operations, and content production, with errors divided between prompt errors (the user's instruction was ambiguous or incomplete) and agent errors (the agent misinterpreted or failed to follow the instruction).
Understanding: Workflows Help You See What Happened
The workflow condition consistently outperformed chat-only review across multiple measures. Step recall, the fraction of execution steps participants could identify, was .94 with workflows versus .78 without (p less than .01). Tool recall was .84 versus .66 (p less than .05). Process comprehension, rated on a five-point scale of how well participants understood the agent's process, was .82 versus .57 (p less than .01). Self-reported understanding was 4.47 versus 3.88 (p less than .05). Step and tool precision did not differ significantly between conditions, meaning that when participants did identify steps or tools, they were accurate in both conditions.
In interviews, 17 out of 20 participants found the post-task workflow helpful for review. Fourteen said the workflow made the agent's process transparent. Seven valued step-level inspection, being able to see inputs, outputs, parameters, and tool-call results for individual nodes. One participant described the tendency to accept output without checking details, comparing it to assuming a bank statement summary is correct without verifying each entry. The workflow graph made it concrete enough to inspect.
Validation: Cross-Checking Across Evidence Sources
The most important finding about validation was how it succeeded. The researchers categorized review patterns into four types: no pattern observed, output check only (inspecting final outputs), workflow check only (inspecting the graph structure), and cross-check (comparing information across multiple sources). Validation success rates told a clear story.
Output check only succeeded in 1 out of 10 cases (10%). Workflow check only succeeded in 0 out of 2 cases (0%). Combining output and workflow checks without cross-checking succeeded in 4 out of 8 cases (50%). But adding cross-checking, comparing the prompt against outputs, rerunning a node and comparing results, or tracing data flow across nodes, pushed success to 17 out of 23 cases (74%). In the workflow condition specifically, the combination of output checking, workflow checking, and cross-checking achieved 85% success (11 out of 13 cases).
The overall validation success rate was 30% in the chat condition (7 out of 23 sessions) versus 65% in the workflow condition (15 out of 23 sessions), a statistically significant difference (beta = 2.62, SE = 1.04, p less than .05). The task also had a significant effect (chi-squared(3) = 8.66, p = .034), reflecting that some errors were inherently harder to detect than others. Per-task results ranged from 33% to 100% in the workflow condition, with prompt errors generally easier to catch than agent errors.
For the specific error cases, the workflow condition improved detection of prompt errors dramatically. On T2, where the user's instruction mixed up which article group should go to Slack versus Google Sheets, validation jumped from 17% (1 out of 6) in chat to 83% (5 out of 6) with workflows. On T3, where the instruction omitted a requirement to write non-fiction books to a specific sheet and sort by price, it went from 67% to 100%. Agent errors improved more modestly: T1 went from 33% to 50%, and T4 from 0% to 33%.
Follow-Up Tasks: Workflow Reuse Versus Prompting
For follow-up tasks, adapting the workflow matched adapting the prior prompt in all objective measures. Task success was 74% with workflows versus 57% with prompts (not statistically significant). Completion time was 6 minutes 12 seconds versus 5 minutes 24 seconds (not significant). Perceived difficulty was 1.48 versus 1.77 (not significant). The two approaches were functionally equivalent in outcomes.
Preferences, however, split along experience and adaptation scope. Nine out of 20 participants preferred workflow adaptation, six preferred prompt editing, and five said it depended on the situation. Of the seven participants with prior workflow-automation experience, six preferred workflow reuse. Among the 13 without experience, preferences were mixed: three preferred workflow, six preferred prompting, and four were situational. All five participants who cited learning cost as a barrier were from the non-experience group.
Adaptation scope also mattered. Small, localized changes, like swapping a file path or changing a filter parameter, favored workflow adaptation because participants could locate the specific node to modify. Broader changes, like restructuring the entire process, favored prompting because the existing prompt served as a starting point. Critically, of the six participants who preferred prompting, only one would still prefer it if they had to write a prompt from scratch. The preference was contingent on having a prior prompt available.
What the Analysis Revealed About Practice
The n8n template analysis was not just design background. It revealed that real-world workflows are rarely linear. The prevalence of branches, merges, and cycles in the 10,803 templates meant that the workflow graph had to support conditional logic and data aggregation, not just sequential steps. The high frequency of AI-supported nodes (51%) confirmed that AI is already embedded in many automation workflows, not as the sole actor but as a component alongside data processing, API calls, and conditional routing. The top task-action nodes, HTTP Request, Google Sheets, Gmail, mapped directly to the tools used in the study tasks.
The three design goals derived from the formative surveys shaped Trace2Flow's interaction model. Making the execution process visible and traceable addressed the primary complaint from AI-agent users, who could not understand what the agent had done. Supporting workflow-based adaptation and reuse addressed the workflow-automation users' observation that similar tasks benefit from step-level modification rather than full re-specification. Complementing natural-language delegation rather than replacing it acknowledged that workflows are not always the right tool. For exploratory or substantially different tasks, prompting remains preferable.
Limitations and Open Questions
The study had 20 participants, only 7 with workflow-automation experience. The observation about experience lowering barriers to workflow reuse is exploratory and needs validation with larger, more diverse samples and longer-term studies. The tasks were compact with limited structural complexity, and follow-up tasks preserved the original structure with little modification. Conclusions about larger workflows or broader adaptations remain open. Trace2Flow was built as a research probe, not a general-purpose trace-to-workflow translation system. Its translation pipeline was validated only on the study task set.
The validation success rates also reveal a persistent challenge. Even with workflows, agent errors were harder to detect than prompt errors. When the agent misinterpreted an instruction, the workflow showed what the agent did but not necessarily why the interpretation was wrong. The user still needed domain knowledge to recognize that the agent's logic was incorrect. Workflows provide the structure for inspection, but the judgment still requires the human.
For developers building AI agent interfaces, the practical takeaway is that post-task workflow graphs are worth considering as a transparency mechanism. They improve process understanding, enable cross-source validation, and provide a reusable artifact for related tasks. But they work best when combined with output inspection and when users are willing to cross-check across sources. A workflow graph alone, without cross-referencing against the prompt, the output, and intermediate results, is not enough. The graph is a scaffold for the human's reasoning, not a substitute for it.