When you’re building an agentic application, there are often multiple ways to structure it. Agents and workflows can be composed in different ways, and those choices usually feel natural long before you think about human approval. The question comes later, when a tool call feels unsafe or a workflow feels risky: where should a human step in?
Mastra supports approval in different ways. Agents can require approval before tool calls. Workflows can suspend and wait to be resumed. The challenge isn’t picking a “correct” pattern, but choosing the approval pattern that best fits how your application is structured.
In a previous post, I introduced the trust pattern as a way to decide when to use human-in-the-loop approval. This post builds on the idea and focuses on the most common patterns for deciding where to implement human-in-the-loop approval.
The handoff graph
This graph provides a high-level view of how agents and workflows connect, and where human approval fits in. A key thing to keep in mind is timing: approval can happen before a tool call, or later inside a workflow step.
The solid arrows show execution flow, from agent to tool to workflow, or from workflow into steps and nested agents. The dashed lines show where a human can intervene to approve or resume execution.
Agent as an entry point
In this pattern, the agent is the entry point. It decides when to act and initiates work by calling a tool that starts a workflow. The key choice is where approval fits into that flow:
- Before the tool is called
- Inside the workflow after execution has already begun
Tool-level approval
In this pattern, approval happens before the agent calls the tool. The agent pauses, asks for approval, and waits for a human decision. After approval, the tool executes and the workflow runs. This works well when calling the tool itself is the risky part. For example, sending an email, issuing a refund, or triggering a payment may be safe to reason about, but should not happen without explicit approval. Nothing downstream runs until a human approves.
Tool-level tradeoffs
The workflow doesn’t know that approval happened. In many cases that’s fine, but it means the workflow won’t reflect that pause in its state or execution history.
Approve at the workflow
In this pattern, the agent calls the tool immediately and a workflow run is started. Approval happens later, inside the workflow at a specific step. That step pauses execution, asks for approval, and waits for a human decision. After approval, the workflow resumes and continues.
This works well when the risky action happens inside the workflow step rather than at the tool call. The workflow can run far enough to gather context, then pause right before the action that needs approval. Nothing past that step continues until a human approves.
Workflow-level tradeoffs
By the time approval is requested, the tool has already been executed. In many cases that’s fine, but if calling the tool itself is risky, the action will have already happened before the workflow asks for approval.
Workflow as an entry point
In this pattern, the workflow is the entry point. It runs first and controls when and how an agent is called. Approval still happens inside the workflow, but you have two ways to structure the agent call:
- Call the agent from within a step
- Treat the agent as a step
Step calls the agent
In this pattern, a workflow step handles both approval and the agent call. The workflow starts running, pauses to wait for approval, then calls agent.generate() once it resumes. Approval and execution are handled together in the same place.
This works well when you need tight control over the agent call itself. For example, you may want to build the prompt dynamically from workflow state, manage message history, or inspect and transform the response before returning a result.
Step-level tradeoffs
The agent call happens inside the step, which can make it harder to surface in logs and traces how the workflow is behaving. The workflow definition stays compact, but understanding when and how the agent is called requires looking into the step’s implementation.
Agent as a step
In this pattern, the agent is composed directly into the workflow using createStep(agent). An approval step runs first and pauses the workflow using suspend(). After approval, .map() transforms the approval output into the { prompt } shape the agent expects, then the agent step / call can happen.
This works well when you want clear separation and visibility. The workflow definition shows approval as an explicit step, followed by the agent call. When the workflow suspends, its status and the suspended step are recorded, making it easier to see where execution paused and what needs to be resumed.
Agent-as-step tradeoffs
This approach adds more steps to the workflow, and requires using .map() to transform data between steps.
Choosing where to intervene
The diagram summarizes the decision space. In practice, the choice comes down to two things:
- Where the risk lives
- When a human can reasonably decide
If calling the tool is the risky moment, approval belongs before execution.
If the risk emerges inside the workflow, approval belongs at the step where that action happens.
Layered approval is useful when you need to confirm both a broader decision and a specific high-risk action. It’s powerful, but it comes with a cost: multiple approval prompts can become annoying for users.
If approval depends on workflow state but nothing has run yet, it’s usually a sign the design needs revisiting.
Choosing a pattern
If you’re already building with Mastra, this post will help you think through where human approval fits in when agents and workflows are working together. Use these patterns to decide when to pause, where to intervene, and how to balance autonomy with control.
For more on agent approval and workflow step suspension, see our docs:
