22 — LangGraph Tool Execution¶
Understand how LangGraph integrates tools into AI Agent workflows, including tool selection, tool execution, validation, authorization, error handling, retries, state updates, idempotency, observability, and production-grade tool execution patterns.
📖 Overview¶
Tools allow AI Agents to interact with the external world.
Without tools:
With tools:
User
↓
Agent
↓
Reason
↓
Select Tool
↓
Validate
↓
Authorize
↓
Execute Tool
↓
Observe Result
↓
Reason Again
↓
Response
Tools can provide capabilities such as:
Database Access
API Calls
Search
RAG
File Operations
Calculations
CRM Operations
Ticket Management
Payments
Email
Cloud Services
Enterprise Applications
LangGraph provides the orchestration layer for controlling how tool calls become part of the graph execution.
A production tool architecture should therefore separate:
LLM Decision
↓
Tool Selection
↓
Tool Validation
↓
Authorization
↓
Tool Execution
↓
Result Validation
↓
State Update
↓
Next Graph Node
The objective is not simply to enable tool calling.
The objective is:
Controlled Tool Execution
+
Security
+
Reliability
+
Observability
+
Idempotency
=
Production Agent Tools
🎯 Learning Objectives¶
After completing this chapter, you will be able to:
- Understand tool execution in LangGraph
- Understand the relationship between LLMs and tools
- Define structured tools
- Bind tools to models
- Execute tool calls inside graph nodes
- Route between model and tools
- Validate tool arguments
- Handle tool execution failures
- Implement retries
- Implement timeouts
- Apply authorization before tool execution
- Design tool gateways
- Handle tool results
- Prevent duplicate side effects
- Implement idempotent tool execution
- Observe tool calls
- Secure tool execution
- Design production tool execution architectures
1. What Is a Tool?¶
A tool is an externally executable capability available to an AI Agent.
Examples:
search_customer()
get_transaction()
create_ticket()
send_email()
calculate_tax()
search_documents()
execute_payment()
Conceptually:
2. Tool Execution Model¶
A typical agent tool loop is:
This creates:
3. Tool Execution in a Graph¶
flowchart TD
A[START] --> B[Agent]
B --> C{Tool Call?}
C -->|No| D[Final Response]
C -->|Yes| E[Tool Validation]
E --> F[Authorization]
F --> G[Tool Execution]
G --> H[Tool Result]
H --> I[Update State]
I --> B
D --> J[END]4. Tool as a Capability¶
A useful architectural principle is:
For example:
The agent should not need to understand the internal implementation of the capability.
5. Tool Contract¶
A production tool should expose a clear contract:
Tool Name
Description
Input Schema
Output Schema
Authorization Requirements
Failure Semantics
Idempotency Requirements
Example:
Tool:
get_customer
Input:
customer_id: string
Output:
customer profile
Authorization:
customer.read
Side Effect:
None
6. Defining a Tool¶
Conceptually, a tool can be defined using a structured schema.
Example:
from langchain_core.tools import tool
@tool
def get_customer(customer_id: str) -> dict:
"""
Retrieve customer information.
"""
return customer_service.get_customer(customer_id)
The exact import and tool APIs may vary with the LangChain/LangGraph versions used in the project.
7. Tool Schema¶
The LLM needs to understand:
Example:
@tool
def get_transaction(transaction_id: str) -> dict:
"""
Retrieve transaction details using transaction ID.
"""
...
Conceptually:
{
"name": "get_transaction",
"description": "Retrieve transaction details",
"input_schema": {
"transaction_id": "string"
}
}
8. Structured Tool Arguments¶
Prefer structured arguments:
over:
Structured inputs provide:
9. Tool Calling vs Function Calling¶
The terms are often used closely.
Conceptually:
The important architectural distinction is:
but:
The LLM should not directly execute arbitrary application code.
10. Tool Binding¶
An LLM can be provided with a set of available tools.
Conceptually:
The exact API depends on the model/provider integration.
11. Tool Selection¶
The model may determine:
Example:
The graph then controls:
12. Tool Selection Architecture¶
flowchart LR
A[User Request] --> B[LLM]
B --> C[Tool Call]
C --> D[Tool Validator]
D --> E[Authorization]
E --> F[Tool Executor]
F --> G[Result]
G --> B13. Tool Node¶
A dedicated tool node can execute requested tools.
Conceptually:
def execute_tools(state):
tool_calls = state["tool_calls"]
results = []
for call in tool_calls:
result = execute_tool(call)
results.append(result)
return {
"tool_results": results
}
In production, tool execution should include stronger controls than this simplified example.
14. Model Node + Tool Node¶
A common graph pattern:
Diagram:
flowchart TD
A[Model] --> B{Tool Call?}
B -->|No| C[END]
B -->|Yes| D[Tool Node]
D --> AThis is one of the fundamental agent execution patterns.
15. Tool Loop¶
The tool loop can continue:
For example:
16. Bounded Tool Execution¶
Never allow:
without limits.
Use:
Example:
These are illustrative values.
17. Tool Allowlist¶
Do not expose every enterprise capability to every agent.
Instead:
while:
This is the principle of:
18. Tool Authorization¶
Tool selection is not authorization.
Example:
This does not mean:
Use:
19. Authorization Architecture¶
flowchart TD
A[LLM Tool Call] --> B[Tool Validation]
B --> C[Identity]
C --> D[Authorization]
D --> E{Allowed?}
E -->|Yes| F[Tool Execution]
E -->|No| G[Reject]
F --> H[Result]
G --> I[Safe Error]20. Tool Permissions¶
A permission model might look like:
Then:
21. RBAC¶
Role-Based Access Control:
Example:
while:
22. ABAC¶
Attribute-Based Access Control can consider:
Example:
23. Tool Gateway¶
For enterprise systems, tools can be centralized behind a Tool Gateway.
24. Tool Gateway Architecture¶
flowchart TB
A[Agent] --> B[Tool Gateway]
B --> C[Authentication]
C --> D[Authorization]
D --> E[Schema Validation]
E --> F[Rate Limiting]
F --> G[Idempotency]
G --> H[Enterprise Service]This creates a strong control boundary around tool execution.
25. Tool Input Validation¶
Never trust LLM-generated arguments.
Example:
The tool layer should validate:
26. Schema Validation¶
Example:
from pydantic import BaseModel, Field
class RefundRequest(BaseModel):
transaction_id: str
amount: float = Field(gt=0)
The tool should reject invalid inputs before executing the side effect.
27. Business Validation¶
Schema validation is not enough.
Example:
may be valid structurally.
But:
may violate a business rule.
Therefore:
28. Tool Output Validation¶
Tool results should also be validated.
Example:
29. Tool Result Is Not Automatically Truth¶
An agent should not blindly trust every tool response.
Potential issues:
Use:
30. Tool Errors¶
Tools can fail.
Example:
or:
or:
The graph should route errors appropriately.
31. Tool Error Routing¶
flowchart TD
A[Tool] --> B{Success?}
B -->|Yes| C[Observation]
B -->|No| D{Error Type}
D -->|Transient| E[Retry]
D -->|Rate Limit| F[Backoff]
D -->|Unauthorized| G[Reject]
D -->|Validation| H[Correct]
D -->|Unknown| I[Escalate]32. Retryable Tool Errors¶
Usually candidates for retry include:
Do not blindly retry:
33. Retry Strategy¶
Use:
Prefer:
for appropriate transient failures.
34. Tool Timeout¶
Every external tool should have a timeout.
Example:
The actual timeout should be based on the service contract.
Without timeouts:
35. Circuit Breaker¶
If an external dependency is unhealthy:
The circuit can move to:
to prevent repeated calls.
36. Tool Reliability Architecture¶
flowchart LR
A[Agent] --> B[Tool Gateway]
B --> C[Timeout]
C --> D[Retry]
D --> E[Circuit Breaker]
E --> F[Enterprise API]
F --> G[Result Validation]
G --> A37. Idempotency¶
Tool execution becomes especially important when tools create side effects.
Examples:
If execution is retried:
the tool could execute twice.
38. Idempotency Key¶
Use:
Example:
The downstream service can detect duplicates.
39. Idempotent Tool Architecture¶
flowchart TD
A[Agent] --> B[Tool Call]
B --> C[Idempotency Key]
C --> D[Tool Gateway]
D --> E{Already Executed?}
E -->|Yes| F[Return Existing Result]
E -->|No| G[Execute]
G --> H[Store Result]
H --> F40. Tool Call Identity¶
Every tool call should ideally be traceable using:
This makes debugging and auditing much easier.
41. Tool Call Lifecycle¶
or:
or:
42. Tool Execution State¶
Example:
class ToolExecution(TypedDict):
tool_call_id: str
tool_name: str
status: str
arguments: dict
result: dict
error: str
Keep sensitive fields appropriately protected.
43. Tool Result State¶
The graph may update:
Example:
Production applications should define consistent result schemas.
44. Tool Messages¶
Agent frameworks commonly represent tool interactions as structured messages.
Conceptually:
This allows the model to receive tool results as part of the conversation context.
45. Tool Call Message Flow¶
sequenceDiagram
participant U as User
participant L as LLM
participant T as Tool
participant G as Graph
U->>G: Request
G->>L: Prompt + Tools
L->>G: Tool Call
G->>T: Execute
T->>G: Result
G->>L: Tool Result
L->>G: Final Answer
G->>U: Response46. Multiple Tool Calls¶
An LLM may request multiple tools.
Example:
The graph needs to determine whether they can execute:
or:
47. Parallel Tool Execution¶
If tools are independent:
then:
48. Parallel Tool Architecture¶
flowchart TD
A[Agent] --> B[Tool Calls]
B --> C[Customer API]
B --> D[Transaction API]
B --> E[Policy API]
C --> F[Merge]
D --> F
E --> F
F --> G[Agent]Parallel execution can reduce latency but introduces:
considerations.
49. Sequential Tool Execution¶
Some tools depend on previous results.
Example:
This must remain sequential.
50. Tool Dependency Graph¶
flowchart TD
A[get Customer] --> B[get Accounts]
B --> C[get Transactions]
C --> D[Analyze]The graph should make dependencies explicit.
51. Tool Selection vs Tool Execution¶
Separate:
from:
Architecture:
This allows deterministic controls around model decisions.
52. Tool Execution vs Business Workflow¶
A tool should generally provide a capability.
Example:
while a workflow might be:
Do not hide large business workflows inside a single opaque tool unless there is a strong architectural reason.
53. Capability-Oriented Tools¶
A useful enterprise abstraction:
Then framework adapters can expose those capabilities as tools.
54. Ports and Adapters¶
A framework-neutral architecture:
flowchart TB
A[Agent Graph] --> B[Tool Port]
B --> C[Customer Adapter]
B --> D[Payment Adapter]
B --> E[Ticket Adapter]
C --> F[Customer Service]
D --> G[Payment Service]
E --> H[Ticket Service]This reduces direct coupling between agent orchestration and enterprise APIs.
55. Tool Registry¶
A production platform may maintain a registry:
Tool Registry
├── Tool Metadata
├── Schema
├── Permissions
├── Version
├── Owner
├── SLA
└── Risk Level
Example:
56. Dynamic Tool Availability¶
An agent may receive tools based on:
Example:
Do not expose unavailable capabilities and rely only on the model not to select them.
57. Tool Versioning¶
Tools evolve.
Example:
Changes may include:
Version important tools explicitly.
58. Tool Compatibility¶
If an agent expects:
and the tool changes to:
execution may fail.
Therefore:
should be compatibility-tested.
59. Tool Governance¶
Each production tool should have:
Owner
Purpose
Risk Classification
Input Schema
Output Schema
Authorization
Rate Limit
Timeout
SLA
Version
Audit Policy
60. Tool Risk Classification¶
Example:
Risk should influence:
61. High-Risk Tool Pattern¶
62. Tool + Human Approval¶
flowchart TD
A[Agent] --> B[Tool Request]
B --> C[Validation]
C --> D[Risk Assessment]
D --> E{High Risk?}
E -->|No| F[Authorization]
E -->|Yes| G[Human Approval]
G --> H[Authorization]
F --> I[Tool]
H --> I
I --> J[Result]63. Tool Result Security¶
Tool responses may contain:
Apply:
before exposing results to the model where appropriate.
64. Tool Result Filtering¶
The model should receive only the data needed for the task.
65. Prompt Injection Through Tools¶
Tools can return untrusted content.
Example:
The returned content must be treated as:
rather than trusted agent instructions.
66. Tool Result Boundary¶
flowchart LR
A[External Tool] --> B[Raw Result]
B --> C[Validation]
C --> D[Security Filter]
D --> E[Agent Context]
E --> F[LLM]67. Tool Sandboxing¶
Some tools execute code or access files.
Examples:
These should run in isolated environments where required.
68. Tool Execution Isolation¶
flowchart TD
A[Agent] --> B[Tool Gateway]
B --> C[Sandbox]
C --> D[Restricted Runtime]
D --> E[Limited Resources]
E --> F[Result]Apply:
where appropriate.
69. Tool Rate Limiting¶
Agents can generate bursts.
Use:
rate limits.
70. Tool Quotas¶
Example:
This provides additional protection against runaway agents.
71. Tool Cost Controls¶
Some tools have direct costs.
Examples:
Track:
72. Tool Observability¶
Track every execution:
Do not log sensitive arguments or results unnecessarily.
73. Tool Trace¶
Example:
Execution: exec-101
Agent
↓
Tool: get_customer
↓
Authorization: PASS
↓
Latency: 80ms
↓
Status: SUCCESS
Agent
↓
Tool: get_transactions
↓
Authorization: PASS
↓
Latency: 120ms
↓
Status: SUCCESS
74. Tool Metrics¶
Useful metrics:
Tool Call Count
Tool Success Rate
Tool Failure Rate
P95 Latency
P99 Latency
Retry Rate
Timeout Rate
Authorization Failure Rate
Cost
Duplicate Execution Rate
75. Tool Evaluation¶
Evaluate:
Example:
76. Tool Selection Accuracy¶
Example:
| Query | Expected Tool | Actual Tool | Result |
|---|---|---|---|
| Customer lookup | get_customer | get_customer | ✅ |
| Transaction lookup | get_transaction | get_transaction | ✅ |
| Create ticket | create_ticket | search_customer | ❌ |
Measure this over a representative dataset.
77. Tool Argument Accuracy¶
Correct tool selection is not enough.
Example:
Actual:
This can be more dangerous than selecting the wrong tool entirely.
Therefore evaluate:
78. Tool Error Recovery¶
A production agent should be able to respond intelligently to tool failures.
Example:
or:
Side-effecting tools require special handling.
79. Tool Status Reconciliation¶
For critical operations:
Do not automatically repeat the operation.
Instead:
80. Unknown Outcome¶
This is a critical distributed-systems scenario.
Example:
The result is:
not necessarily:
Treating unknown as failed and retrying blindly can create duplicate side effects.
81. Tool Outcome State¶
Use states such as:
This is especially important for:
82. Tool Reconciliation¶
flowchart TD
A[Tool Call] --> B[External Service]
B --> C{Response}
C -->|Success| D[Success]
C -->|Failure| E[Failed]
C -->|Timeout| F[Unknown]
F --> G[Query Status]
G --> H{Known?}
H -->|Yes| I[Reconciled]
H -->|No| J[Human Escalation]83. Tool Execution and Transactions¶
Do not assume an agent graph transaction automatically covers external APIs.
For example:
These may not share a single transaction.
Use appropriate distributed workflow patterns.
84. Saga-Like Compensation¶
For multi-step workflows:
If C fails:
Example:
If payment fails:
The exact compensation strategy belongs to the business workflow.
85. Tool Execution and Compensation¶
flowchart TD
A[Create Order] --> B[Reserve Inventory]
B --> C[Charge Payment]
C --> D{Success?}
D -->|Yes| E[Complete]
D -->|No| F[Release Inventory]
F --> G[Cancel Order]
G --> H[Failed]86. Tool Execution Boundaries¶
A strong enterprise architecture is:
This keeps:
separate from:
87. Framework-Neutral Tool Architecture¶
This prevents the core domain from depending directly on LangGraph.
88. Example Capability Interface¶
public interface PaymentProvider {
PaymentResult refund(
String transactionId,
BigDecimal amount
);
}
Then:
The LangGraph layer can invoke the capability through an application-facing tool.
89. Tool Adapter¶
This is consistent with Ports & Adapters architecture.
90. Tool Registry Architecture¶
flowchart TB
A[Agent] --> B[Tool Registry]
B --> C[Tool Metadata]
B --> D[Schema]
B --> E[Permissions]
B --> F[Risk]
B --> G[Version]
B --> H[Tool Gateway]
H --> I[Enterprise Services]91. Production Tool Lifecycle¶
Design
↓
Define Schema
↓
Implement
↓
Test
↓
Security Review
↓
Register
↓
Deploy
↓
Observe
↓
Version
↓
Retire
92. Tool Testing¶
Test at multiple levels:
Unit Test
↓
Schema Test
↓
Authorization Test
↓
Integration Test
↓
Failure Test
↓
Agent Tool-Selection Test
↓
Load Test
93. Tool Contract Testing¶
Validate:
Example:
This protects agents from breaking changes.
94. Tool Failure Testing¶
Simulate:
Verify the graph routes each case correctly.
95. Tool Load Testing¶
Measure:
Also test the downstream service's limits.
96. Tool Security Checklist¶
Authentication
Authorization
Input Validation
Output Validation
Data Minimization
Secret Management
Tenant Isolation
Rate Limiting
Audit
Sandboxing
97. Tool Execution Checklist¶
Tool Design¶
- [ ] Clear purpose
- [ ] Structured schema
- [ ] Input validation
- [ ] Output validation
- [ ] Error contract
- [ ] Versioning
Security¶
- [ ] Authentication
- [ ] Authorization
- [ ] Least privilege
- [ ] Tenant isolation
- [ ] Secret protection
- [ ] Data filtering
Reliability¶
- [ ] Timeout
- [ ] Retry
- [ ] Backoff
- [ ] Circuit breaker
- [ ] Idempotency
- [ ] Reconciliation
Operations¶
- [ ] Tool tracing
- [ ] Metrics
- [ ] Cost tracking
- [ ] Audit
- [ ] Alerts
98. Key Takeaways¶
- Tools give AI Agents access to external capabilities.
- The LLM should decide what it wants to do, while trusted application code executes the tool.
- Tool execution should be separated from tool selection.
- Tool arguments must be validated before execution.
- Authorization must be enforced independently of the LLM.
- A Tool Gateway can centralize enterprise controls.
- Tool outputs should be validated and filtered before entering agent context.
- Tool loops must be bounded.
- Retryable and non-retryable failures should be handled differently.
- Timeouts prevent blocked agent executions.
- Circuit breakers protect unhealthy downstream systems.
- Idempotency protects side-effecting tools from duplicate execution.
- Unknown outcomes require reconciliation rather than blind retry.
- High-risk tools should pass through stronger controls and potentially human approval.
- Tool registries improve governance across large enterprise tool ecosystems.
- Tool versions should be managed explicitly.
- Tool execution should be observable at the tool-call level.
- Tool selection and argument accuracy should be evaluated independently.
- Sensitive tool results should be minimized before being exposed to models.
- External content returned by tools should be treated as potentially untrusted.
- Code-execution tools may require sandboxing.
- Capability-based tool design reduces framework coupling.
- LangGraph should orchestrate execution rather than become the enterprise system of record.
- The production goal is not maximum tool access.
- The goal is safe, controlled, observable, and reliable capability access.
📝 Quick Revision Notes¶
Tool Execution¶
Tool Security¶
Tool Reliability¶
Unknown Tool Outcome¶
High-Risk Tool¶
Tool Architecture¶
❓ Interview Questions¶
Beginner¶
- What is a tool in an AI Agent?
- What is tool calling?
- How does a LangGraph agent execute tools?
- What is a tool node?
- Why should tool arguments be validated?
- What is tool authorization?
- What is a tool allowlist?
- Why are timeouts important?
- What is idempotency?
- Why should tool outputs be validated?
Intermediate¶
- How would you implement tool execution in LangGraph?
- How would you route between an LLM node and a tool node?
- How would you handle tool failures?
- Which tool failures are normally retryable?
- How would you implement exponential backoff?
- How would you prevent duplicate side effects?
- How would you implement tool authorization?
- How would you design a Tool Gateway?
- How would you handle multiple tool calls?
- When can tools execute in parallel?
- How would you validate LLM-generated tool arguments?
- How would you handle unknown tool outcomes?
- How would you evaluate tool selection?
- How would you evaluate tool argument accuracy?
Advanced¶
- Design a production-grade enterprise Tool Gateway.
- How would you prevent an LLM from invoking unauthorized tools?
- How would you design idempotent financial tools?
- How would you handle a payment API timeout after the request was submitted?
- How would you reconcile an unknown transaction outcome?
- How would you design tool versioning?
- How would you handle tool schema evolution?
- How would you design multi-tenant tool authorization?
- How would you protect against prompt injection through tool results?
- How would you sandbox code-execution tools?
- How would you design tool rate limiting?
- How would you design circuit breaking for tool dependencies?
- How would you monitor tool execution across thousands of agents?
- How would you combine LangGraph tools with a capability-based architecture?
- How would you implement compensation for multi-step tool workflows?
- How would you design a tool registry?
- How would you handle parallel tool execution and state merging?
- How would you prevent an agent from abusing high-cost tools?
- How would you implement human approval for high-risk tools?
- How would you design tool governance for an enterprise AI platform?
- How would you separate AI orchestration from enterprise service execution?
🛠️ Practical Exercise¶
Build a customer-support agent with the following tools:
Graph:
flowchart TD
A[START] --> B[Agent]
B --> C{Tool Required?}
C -->|No| D[Final Response]
C -->|Yes| E[Tool Validation]
E --> F[Authorization]
F --> G[Tool Execution]
G --> H[Validate Result]
H --> I[Update State]
I --> B
D --> J[END]Add:
Tool Allowlist
Input Validation
Output Validation
Timeout
Retry
Tool Metrics
Audit
Maximum Tool Calls
🧪 Failure Simulation Exercise¶
Simulate:
1. Tool timeout
2. Rate limit
3. Unauthorized request
4. Invalid arguments
5. Malformed response
6. Service unavailable
7. Duplicate execution
8. Unknown execution outcome
Define the expected behavior:
Timeout
→ Retry
Rate Limit
→ Backoff
Unauthorized
→ Reject
Invalid Input
→ Correct / Reject
Malformed Response
→ Validation Failure
Service Unavailable
→ Retry / Fallback
Duplicate
→ Idempotency
Unknown
→ Reconcile
🚀 Advanced Tool Exercise¶
Create:
with:
Example:
Tool Risk
--------------------------------
search_customer Low
get_customer Low
get_transactions Low
create_ticket Medium
update_customer Medium
send_email Medium
refund_payment High
delete_document High
execute_payment Critical
run_code Critical
Implement:
🏢 Production Architecture Challenge¶
Design a Tool Gateway supporting:
1,000+ Tools
10,000+ Agent Executions
Multiple Tenants
Multiple Agent Types
Multiple LLM Providers
High-Risk Operations
Required:
Tool Registry
Tool Discovery
Schema Validation
Authorization
Risk Policy
Rate Limiting
Timeout
Retry
Circuit Breaker
Idempotency
Audit
Observability
Versioning
Architecture:
flowchart TB
A[Agent Runtime] --> B[Tool Router]
B --> C[Tool Registry]
C --> D[Tool Metadata]
C --> E[Schema]
C --> F[Permissions]
C --> G[Risk]
B --> H[Tool Gateway]
H --> I[Authentication]
I --> J[Authorization]
J --> K[Validation]
K --> L[Rate Limit]
L --> M[Idempotency]
M --> N[Circuit Breaker]
N --> O[Enterprise Services]
O --> P[Result Validation]
P --> A
H --> Q[Audit]
H --> R[Metrics]🧠 Final Architecture Challenge¶
Design a Banking Operations Tool Platform that supports:
The platform must enforce:
Least Privilege
Tenant Isolation
Risk Classification
Human Approval
Idempotency
Reconciliation
Audit
Observability
For a refund:
sequenceDiagram
participant A as Agent
participant G as Tool Gateway
participant P as Policy Engine
participant H as Human
participant B as Banking API
A->>G: refund(transaction, amount)
G->>G: Validate Schema
G->>P: Authorization + Risk
P->>H: Approval Required
H->>P: Approved
P->>G: Authorized
G->>B: Refund + Idempotency Key
B->>G: Result
G->>G: Validate Result
G->>A: Tool ResultAnswer:
Where is the tool schema validated?
Where is authorization enforced?
Where is risk evaluated?
Where is human approval enforced?
Where is idempotency generated?
What happens if the banking API times out?
How do you determine whether the refund actually occurred?
How do you prevent duplicate refunds?
How do you audit the operation?
How do you isolate tenants?
How do you version the refund tool?
📚 References & Further Reading¶
Recommended areas for further study:
- LangGraph Tool Execution
- LangGraph Tool Nodes
- LangChain Tools
- Structured Tool Calling
- Function Calling
- Tool Authorization
- Tool Gateways
- Tool Registries
- Capability-Based Architecture
- Ports & Adapters
- Idempotent APIs
- Distributed Transactions
- Saga Patterns
- Circuit Breakers
- Retry and Backoff
- Human-in-the-Loop
- Agent Security
- Prompt Injection
- Tool Sandboxing
- Agent Observability
- Agent Evaluation
- Enterprise API Governance
LangGraph and LangChain tool APIs evolve over time. Verify the exact tool-node, tool-binding, execution, message, and routing APIs against the official documentation for the versions used in your project.
🧭 Chapter Navigation¶
⬅️ Previous: 21. LangGraph Human-in-the-Loop
📚 Part VIII Index: AI Engineering Frameworks & Tooling
➡️ Next: 23. LangGraph Agent Workflows
Enterprise AI Engineering Handbook
Building Production-Grade Enterprise AI Systems — One Chapter at a Time.