Implementing Approval-Aware Tool Execution in LangGraph
In the previous article, I explained why certain agent workflows transition from simple chains to graph-based execution. A chain works well when the path is pre...
In the previous article, I explained why certain agent workflows transition from simple chains to graph-based execution.
A chain works well when the path is predictable. One step follows another, and the output of one stage becomes the input to the next.
However, many real-world workflows are more complex. They branch, pause, retry, require approval, or skip execution if conditions are not met.
This is where a graph-style workflow is beneficial.
This article focuses on practical application. We will use LangGraph to build an approval-aware workflow in which an agent reads data, prepares a recommendation, pauses for approval, and executes only after approval.
This is not a theoretical discussion of agents, but a practical implementation pattern.
The core idea is straightforward: some tools can run automatically, while others require approval before execution.
Why I picked credit review as the example
I have nearly five years of experience in credit analytics.
During that time, I worked on a patent for credit rating based on user expressions captured in a one-minute recorded video. This experience influenced my perspective on AI-supported decision workflows.
Credit decisions extend beyond model outputs. They require evidence, policy review, risk indicators, recommendations, approvals, execution, and audit.
This makes credit review an effective example for this article.
The focus is not the credit model itself, but the workflow surrounding it. Even with AI-assisted analysis, the system must clearly separate recommendations from execution.
Example workflow
Consider a simple credit review workflow.
The agent assists a credit analyst by collecting evidence, calculating indicators, and preparing a recommendation. However, the agent should not update the official credit decision without approval.
The workflow has these stages:
This workflow is well-suited to LangGraph because it is not strictly linear. Execution may need to pause, and recommendations can be incomplete, rejected, or sent for further review.
This is the practical reason to use a graph-based workflow.
Why a simple chain is not enough
A simple chain may look like this:
While this is easy to implement, it conceals a significant issue.
The update step modifies a business system and should not run solely because a recommendation was produced.
In credit analytics, this distinction is critical. A score, signal, or recommendation can inform a decision, but should not automatically become the decision.
In a chain, analysis and execution can be inadvertently connected. A graph allows for an explicit approval step between recommendation and execution.
This is the key practical difference.
The graph provides a point to pause, inspect the state, capture a decision, and proceed only when permitted.
Classifying the tools
Before designing the graph, it is helpful to classify the tools.
retrieve_credit_policy → read-only
read_customer_profile → read-only
read_repayment_history → read-only
calculate_risk_indicators → analysis
draft_credit_recommendation → draft
approve_recommendation → human approval
update_credit_record → system update
notify_downstream_system → external notification
log_review_outcome → audit
This is not a complex governance model, but a practical engineering practice.
Read-only tools typically run automatically. Analysis tools may also run automatically if they do not alter business systems.
Drafting tools generate output but do not execute it.
Update and notification tools require additional caution, as they modify records or initiate communication. This separation will be implemented.
State model
LangGraph operates using shared state.
For this workflow, the state model can remain simple.
The state provides the graph with concrete data to inspect.
It records which data was accessed, which recommendation was drafted, whether approval was obtained, and whether execution occurred.
This is valuable during normal execution and becomes even more important during pause, resume, or retry operations.
In credit workflows, this is especially important. The system should be able to explain which evidence was reviewed, which indicators were calculated, what was recommended, who approved it, and what actions were taken.
Basic graph structure
Now we can define the graph.
Up to this stage, the workflow remains linear, which is acceptable.
A graph does not require constant branching; it allows for controlled branching where necessary.
The critical point occurs after the recommendation stage.
Routing after recommendation
After the recommendation is drafted, the graph decides where to go next.
Then we attach this routing function to the graph.
This is the key implementation step.
The recommendation node does not directly invoke the update tool; it records the recommendation in the state.
The graph then determines whether the workflow can proceed or must pause for approval.
Drafting the recommendation
The recommendation node can be deterministic, model-based, or LLM-assisted.
For this example, the approach remains simple.
The key point is not the scoring logic, but that this node drafts a recommendation without executing it.
The recommendation is stored in the state, and the subsequent step is managed by the graph.
This approach also reflects my perspective on AI in credit analytics: the model or agent can generate strong signals, but the workflow should determine how those signals are used.
Approval step
The approval step allows the workflow to pause.
In LangGraph, this is implemented using an interrupt-style pattern. The graph can pause, send the approval request to a reviewer, and resume once a decision is provided.
This approach makes the approval process explicit.
The workflow does not rely on the model to confirm approval; instead, the approval result is recorded in the workflow state.
This enables the next node to make a safe execution decision.
Routing after approval
After approval, the graph verifies whether execution is permitted.
Then we attach this route.
If approval is rejected, the graph bypasses the internal record update and proceeds to logging.
This approach maintains a clear execution path.
Execute only after approval
The update node must still verify the state.
This is important because workflows evolve. A node that updates a business system should not assume it was reached under correct conditions.
This is a straightforward defensive pattern.
The graph manages routing, while the node validates before execution. Both are essential.
Notify downstream systems
After updating the internal record, the workflow may notify an external system.
This could include a loan origination system, customer management system, risk dashboard, or operations queue.
Again, the node does not determine the business outcome; it communicates the result of the approved workflow.
This separation makes the design easier to understand and maintain.
Complete the graph
Now we connect the remaining edges.
The final logging node can remain straightforward.
This provides a trace of workflow activity.
While not a comprehensive audit platform, it demonstrates where audit should be integrated within the workflow.
Audit should not be added as an afterthought.
Checkpoint and resume
Approval workflows typically require persistence.
Reviewers may not respond immediately, services may restart, and workflows may need to resume at a later time.
LangGraph supports this pattern through checkpointing.
When the graph reaches the approval step, it can pause.
Later, the workflow can resume with the approval decision.
This is a practical benefit of transitioning from a simple chain to a graph.
The workflow can pause at a defined point, preserve state, and resume from the same stage after approval.
Add idempotency for execution
One additional practical detail remains.
Any node that updates a business system should be designed for safe retries.
Retries are common in production environments due to network failures, worker restarts, or API timeouts.
If the update node runs multiple times, it should not create duplicate or inconsistent updates.
Implementing a simple idempotency key addresses this issue.
This practice is not unique to LangGraph; it is standard in production engineering.
However, it becomes increasingly important when workflows can pause and resume.
Where the LLM fits
The LLM remains valuable within this workflow.
It can summarize policy, explain recommendations, draft reviewer notes, identify missing evidence, and prepare communications for customers or operations.
Other AI models may also be involved in credit analytics, generating risk scores, behavioral indicators, document signals, or alternative assessment signals. In previous work, I explored short video-based expression signals as part of a credit rating approach.
However, the underlying pattern remains consistent.
AI can assist with analysis and drafting, but the workflow should continue to manage approval, execution, notification, and audit.
A practical pattern is:
LLM helps with analysis and drafting
graph controls the workflow path
approval step pauses risky execution
execution node validates state
audit log records the outcome
This approach keeps the implementation simple and makes the workflow easier to test.
You can test the routing after recommendation, the approval path, whether execution is blocked without approval, and whether rejected cases avoid downstream notification.
This level of testing is more difficult when logic is embedded within a free-form agent loop.
Practical design lessons
The first lesson is straightforward: do not connect recommendation directly to execution when execution modifies a business system.
Insert an approval step between recommendation and execution.
The second lesson is that approval should be explicitly recorded in the state, not implied from chat messages or hidden in model output.
The third lesson is that execution nodes must validate state before interacting with external systems. Routing is helpful, but defensive checks remain necessary.
The fourth lesson is that checkpointing is essential when workflows pause. Without persisted state, approval workflows are fragile.
The fifth lesson is that audit should be integrated into the graph, with each major step leaving a business-level trace.
These may seem like minor implementation choices, but they distinguish a demo workflow from a production-ready solution.
Conclusion
My experience in credit analytics provided valuable insights into AI systems.
The value lies not only in building better models, but also in integrating those models into the appropriate workflow.
The previous article explained that many agent workflows transition from chains to graphs when processes require branching, review, retries, and state management.
This example demonstrates a practical reason for that transition.
When a workflow requires approval before execution, a graph-based approach is a natural fit.
The agent can read, analyze, and draft, while the workflow can pause, resume, validate, execute, and log actions.
This is the practical value of approval-aware tool execution in LangGraph.