Primary: Graph Engineering for AI Agents: Practical Guide to Failed Branches, Retries, Escalation & Safe Stopping
Agent workflows rarely fail in one simple way. A network request can disappear, a tool can reject an input, two parallel branches can disagree, a human approval can arrive too late, or the workflow can keep retrying even though continuing no longer makes sense. Graph engineering turns these situations into explicit routes instead of leaving them to chance.
This article explains four closely related controls: failed branches, retries, escalation, and safe stopping. The goal is not to make every graph complicated. The goal is to make the graph predictable about what happens when the happy path breaks.
Imagine a school field trip with several buses. If one bus gets a flat tire, the trip does not automatically mean “start every bus again.” The teacher decides whether that bus should be repaired, whether students should move to another safe bus, whether an adult should take over, or whether the trip should stop. A workflow graph needs the same kind of decision logic.
The examples in this article use a fictional invoice-review workflow. It is a teaching scenario, not a description of any company's private implementation.
- Understand failure as a graph event
- Handle failed branches without collapsing the whole workflow
- Design retries that do not multiply side effects
- Use escalation as a deliberate route
- Define safe stopping before you need it
- Combine retry, recovery, escalation, and stopping
- Make state and recovery work together
- Test failure paths as seriously as success paths
- Enterprise Rollout
- Common Mistakes
- ❓ FAQ
- 🔗 References & Further Reading
- 📝 Summary
| Situation | Primary route | Reason | Typical terminal outcome |
|---|---|---|---|
| Transient failure | Retry | The problem may disappear without changing the intended work. | Continue |
| Known branch failure | Recovery route | Only one part of the graph is broken or incomplete. | Degraded completion or recovery |
| Human-fixable or high-impact issue | Escalate | Continuing automatically would require judgment, missing information, or authorization. | Waiting / human decision |
| Unsafe, exhausted, canceled, or expired | Stop | The graph has reached a boundary where more work is not justified. | Explicit terminal state |
01
Understand Failure as a Graph Event
A workflow graph becomes easier to reason about when failure is treated as data that changes the route, not merely as an exception message printed somewhere in a log.
Consider this simplified invoice workflow:
↓
Read invoice
↓
Validate invoice
↓
┌───────────────┬────────────────┐
│ valid │ invalid │
↓ ↓
Risk check Exception review
↓ ↓
Approve? Escalate
↓
Schedule action
↓
END
Now imagine the Risk check service returns a temporary timeout. That is different from a validation failure. The graph should not treat both as one generic “error” because they have different next actions.
| Failure signal | Meaning | Graph response |
|---|---|---|
| Timeout | The service may still be healthy but slow or temporarily unreachable. | Retry under a bounded policy. |
| Invalid invoice data | The business input does not satisfy required rules. | Route to correction or exception handling. |
| Missing approval | The graph lacks an authorized decision for a consequential step. | Pause and escalate. |
| Repeated unknown failure | The workflow no longer has enough information to continue safely. | Stop with an explicit failure state. |
Do not design only the success path. Design the meaning of each important failure before writing the route.
This is where graph engineering differs from merely writing a sequence of function calls. A graph can express that one branch is allowed to fail while another must block the workflow, that one error should loop back, and that another should terminate the run.
Current LangGraph documentation illustrates this idea in a framework-specific way: it distinguishes transient errors, LLM-recoverable problems, user-fixable problems, retry exhaustion, and unexpected errors, with different routing strategies for each. That is an architecture example rather than a universal graph standard. LangGraph documentation.
Risk → A generic error route can accidentally send sensitive or high-impact work into a permissive recovery path. Control → Classify failures before choosing the next node, and make authorization checks explicit. Remaining risk → Classification itself can be wrong, especially when an AI model participates in deciding the route; consequential authorization should therefore remain enforceable outside the model's judgment.
Your workflow has more than one meaningful failure outcome, especially when some failures should continue and others should stop or escalate.
02
Handle Failed Branches Without Collapsing the Whole Workflow
Think about a group project where three students work on three different pieces. One student gets stuck. You do not automatically erase the other two students' finished work. You first ask whether the failed piece can be repaired, replaced, or handed to someone else.
A failed branch is not necessarily a failed workflow. This distinction becomes important when the graph contains parallel work, optional enrichment, fallback providers, or independent checks.
Suppose an invoice workflow runs three checks:
├── Supplier identity check
├── Purchase-order match
└── Risk assessment
If the risk service is temporarily unavailable, you may have several possible designs:
- Block the join. Do not continue until the risk result exists.
- Use a bounded fallback. Continue only if policy explicitly allows a reduced-risk path.
- Escalate. Send the invoice to a human reviewer because an automated decision is no longer justified.
- Stop. End the workflow when the missing branch result is mandatory and no safe fallback exists.
The correct choice depends on the business rule. Graph engineering does not mean “always recover.” It means the recovery choice is explicit.
The purchase-order match succeeds. The supplier identity check succeeds. The risk service times out twice. The policy says invoices above a configured risk threshold cannot be released without a completed risk result.
Expected behavior: the graph records the successful branches, exhausts the bounded retry policy for the risk branch, then routes to Human Review Required. It does not rerun supplier identity or purchase-order matching just because one sibling branch failed.
This matters for both cost and correctness. Re-running completed branches can increase model calls and tool calls, but the bigger risk is that a repeated action may have an external side effect.
“When one branch fails, which already-completed work remains valid, and which work must be recomputed?”
A useful graph state often records more than error=true. It may need a branch outcome, attempt count, failure class, timestamps, a safe-to-retry flag, and the identity of the external operation.
status: "failed",
failure_class: "transient",
attempts: 2,
retryable: true,
completed_side_effect: false
}
if branch.retryable and budget_remaining:
retry branch
elif branch.requires_human:
escalate
else:
stop safely
Illustrative pseudocode: the structure is intentionally generic and is not a working SDK example.
Your graph has parallel branches, optional enrichment, fallback providers, or recovery routes where a local failure should not automatically destroy valid completed work.
03
Design Retries That Do Not Multiply Side Effects
Imagine pressing an elevator button once and not hearing anything. Pressing it again might help if the first press was missed. But repeatedly pressing the button 200 times does not make the elevator arrive faster. It creates a different problem: you have stopped reacting to evidence and started repeating an action without a boundary.
A retry is useful when the error is likely to be temporary and repeating the operation is safe. It becomes dangerous when the operation has a side effect that can happen twice.
A practical retry decision has at least four questions:
- Is the failure transient? Examples include selected network failures, temporary rate limiting, or service unavailability.
- Is the operation safe to repeat? Read operations are often easier to retry than irreversible writes.
- Is there a retry budget? Bound attempts and total waiting time.
- What happens after the budget is exhausted? The graph needs a declared next state: fallback, escalation, compensation, or stop.
Google Cloud's current retry guidance explicitly connects retry safety with both the error response and operation idempotency. It also recommends exponential backoff with jitter and warns against repeatedly retrying non-idempotent operations. These are engineering practices, not AI-only ideas. Google Cloud retry strategy.
attempt 2 → longer delay
attempt 3 → longer delay
budget exhausted → choose recovery route
The word budget is important. A retry policy is not simply a number of attempts. In production, you may need several boundaries:
| Budget | Question | Why it matters |
|---|---|---|
| Attempt budget | How many times can this node execute? | Prevents loops and repeated external calls. |
| Time budget | How long can the graph wait? | Prevents stale work from surviving indefinitely. |
| Tool budget | How many external actions are allowed? | Controls cost and limits repeated tool use. |
| Business budget | How much risk or partial completion is acceptable? | Connects technical failure policy to business consequences. |
Risk → A retry can repeat an external side effect, such as creating an object, sending a message, or submitting a transaction. Control → Retry only when the operation is appropriate for retry, use idempotency controls where the downstream system supports them, and keep attempts bounded. Remaining risk → A timeout can occur after the external system completed the action but before the caller received confirmation, so “request failed” does not always mean “effect did not happen.”
That last situation is one of the hardest distributed-systems problems: the caller cannot always distinguish “did not happen” from “happened but the response was lost.” A graph that simply retries after every timeout can create duplicates.
A safer design separates the workflow attempt from the business operation identity. For example, a fictional payment-release action might carry an operation ID such as release-2026-00081. A downstream system that supports idempotency can use that identifier to recognize a repeated request as the same business operation.
Do not assume every API supports idempotency simply because your graph has an ID field. The protection must exist in the downstream contract or in a durable deduplication layer that you control.
Retries improve availability; idempotency protects correctness.
A graph depends on remote services, model calls, databases, queues, MCP tools, or APIs that can experience transient failure.
04
Use Escalation as a Deliberate Route
A child trying to cross a busy road should not keep retrying the crossing decision because the traffic light did not look clear. The sensible move is to ask an adult. Escalation is the workflow equivalent: the system reaches a point where another authority should take over.
Escalation is sometimes described as “human in the loop,” but the more useful graph-engineering idea is authority transfer. The system is saying: “The next decision is outside the authority or confidence boundary of this automated path.”
Good escalation has a defined package:
- Reason: why automation stopped.
- Evidence: the inputs, outputs, failed checks, and relevant tool results.
- Requested decision: what the human actually needs to decide.
- Authority boundary: which action remains blocked until the decision arrives.
- Resume rule: what graph state is allowed after approval, rejection, or expiration.
An escalation that merely says “Something went wrong. Please check.” is weak. It moves the problem to a human without improving the decision structure.
Automatic result: “Supplier is known, purchase order matches, but risk verification is unavailable after the allowed retry budget.”
Human receives: invoice reference, supplier reference, purchase-order match result, risk-check status, retry count, and the exact action currently blocked.
Human choices: approve exception, reject exception, or request additional information. The graph resumes only from a state compatible with the selected decision.
This pattern appears in current agent runtimes as well. The OpenAI Agents SDK, for example, documents approval-based human-in-the-loop execution where a tool call requiring approval pauses the run and can later resume from saved run state. The documentation also emphasizes server-side authorization of the reviewer and protection against replayed or substituted approval data. That is a specific SDK architecture, but the underlying graph principle is broadly useful. OpenAI Agents SDK human-in-the-loop guide.
Risk → An approval interface can become a confused-deputy path if a reviewer can approve actions they are not authorized to approve, or if an attacker can replace the pending action before approval. Control → Bind approval to a server-owned workflow state, authenticate and authorize the reviewer, validate the exact pending action, and consume the decision atomically. Remaining risk → A human can still approve an incorrect or unsafe action, so approval is a control boundary, not a guarantee of correctness.
The OpenAI SDK documentation specifically warns that serialized approval state should be treated as untrusted until its integrity, ownership, and replay behavior have been verified. That is a useful reminder that “human approved it” is not the same as “the approval record is trustworthy.” OpenAI Agents SDK approval-state guidance.
Escalation can also be based on uncertainty, not only technical failure. For example, a workflow may complete all technical checks but still route to a human because the financial impact is above an automated approval threshold.
Escalation should identify the exact authority gap, not merely move a failed run into someone's inbox.
The next step requires authorization, missing information, a business judgment, or a higher level of risk acceptance than the automated path is allowed to make.
05
Define Safe Stopping Before You Need It
When filling a bathtub, you need a point where you stop adding water. You do not keep asking, “Should I add one more bucket?” forever. A workflow needs the same idea: explicit stopping conditions.
Safe stopping means the graph knows when continuing is no longer justified. The exact stop conditions depend on the system, but common boundaries include:
- Retry exhaustion: the allowed recovery attempts are consumed.
- Deadline reached: the work is no longer useful after a defined time.
- Budget exhausted: tool calls, compute, or business resources have reached their limit.
- Authorization unavailable: a required approval was rejected or expired.
- Safety condition triggered: a downstream action would exceed the allowed authority boundary.
- Cancellation requested: a user, supervisor, or orchestration system explicitly stopped the work.
A safe stop should also have a reason code. “Stopped” is much less useful than “stopped: approval expired” or “stopped: retry budget exhausted on risk service.” The reason becomes part of observability, incident analysis, and later recovery decisions.
--------------
COMPLETED
REJECTED
ESCALATED
CANCELLED
TIMED_OUT
FAILED
The exact state names are application design choices. Not every workflow needs all of them.
One important distinction is between canceling the workflow and canceling the external action. A graph may stop scheduling new work while an already-running external process continues until it finishes or responds to cancellation. The architecture therefore needs a defined cancellation boundary.
Temporal's current documentation makes this distinction explicit at the orchestration level: workflow tasks, activities, retries, and cancellation are separate concepts, and an Activity has its own execution behavior. Its AI guidance also presents approval workflows, saga-style compensation, long-running activities, and durable state as separate patterns that can be combined when needed. Temporal task execution documentation and Temporal Durable AI guidance.
Safe stopping is also different from an AI model simply deciding to stop. A model can propose that the task is complete, but the graph can still require deterministic checks such as “required fields exist,” “no approval is pending,” “all mandatory branches have completed,” or “the downstream action was confirmed.”
Risk → A workflow may continue simply because the model says “done,” even though a mandatory business condition remains incomplete. Control → Use explicit completion criteria enforced by the graph or application, not only natural-language instructions. Remaining risk → A poorly designed completion rule can still certify the wrong state, so completion checks themselves must be tested and monitored.
In a tool-using system, safe stopping also reduces the opportunity for unnecessary tool use. OWASP's current guidance on excessive agency emphasizes minimizing tool functionality, permissions, and autonomy, with stronger controls around high-impact operations. A bounded workflow therefore helps reduce both failure risk and the amount of damage a compromised or mistaken agent could cause. OWASP LLM06:2025 Excessive Agency.
Your workflow can loop, wait, retry, call tools, or pause for humans. Those systems need explicit boundaries so “keep going” is never the only available strategy.
06
Combine Retry, Recovery, Escalation, and Stopping
The real engineering value appears when the four mechanisms are designed as one failure policy.
│
├─ success ───────────────→ next node
│
├─ transient + retryable ──→ bounded retry
│ │
│ └─ exhausted → recovery / escalation
│
├─ user-fixable ───────────→ pause + human input
│
├─ high-impact / unauthorized → stop or escalate
│
└─ unexpected / unsafe ─────→ terminal failure
Notice what this graph does not say: “If anything fails, send it back to the agent.” Some failures are appropriate for another model attempt. Others are not.
A useful error policy matrix can make the design explicit before implementation begins.
| Failure class | Example | Graph action | Never do automatically |
|---|---|---|---|
| Transient | Timeout, temporary 503/429-style service response | Retry within policy | Retry forever |
| Input/business | Missing supplier reference | Ask for correction or escalate | Repeat unchanged input |
| Authorization | Reviewer not authorized | Stop or find authorized reviewer | Let the model choose a more privileged identity |
| Side-effect ambiguity | Request may have completed before timeout | Reconcile state / use idempotency mechanism | Blindly repeat the write |
| Unknown / unsafe | Unexpected state transition | Stop and record evidence | Continue “to see what happens” |
1. Invoice ingestion succeeds.
2. Supplier validation succeeds.
3. Purchase-order match succeeds.
4. Risk assessment returns a transient timeout.
5. Graph waits using bounded backoff and retries.
6. Risk assessment fails again and reaches its retry budget.
7. Graph packages the evidence and routes to human review.
8. Reviewer approves the exception.
9. The graph checks that approval still matches the pending invoice state.
10. The workflow performs the permitted downstream action and records completion.
The important point is that each stage has a different responsibility. The model may help classify the invoice or recommend a route. The graph decides which transitions are permitted. The harness may enforce runtime limits, tracing, retries, or approvals depending on the chosen architecture. The tool performs the external operation. A sandbox, when present, can isolate certain execution capabilities but does not automatically solve business authorization or downstream side effects.
Risk → A model can be induced by untrusted content to request an unsafe tool action or suggest skipping a required branch. Control → Treat external content as data, enforce permissions and completion rules outside the model, require approval for high-impact actions, and constrain tools to the minimum necessary capability. Remaining risk → Prompt or instruction injection is not eliminated by one filter, approval, or sandbox; defense in depth is still required.
OWASP's excessive-agency guidance specifically recommends minimizing tool functionality, permissions, and autonomy, and using human approval for high-impact operations. Those principles fit naturally into graph design because a route can make authority boundaries explicit. OWASP GenAI security guidance.
You need one coherent failure policy instead of separate, inconsistent retry, error, approval, and timeout rules hidden across many nodes.
07
Make State and Recovery Work Together
Suppose you are building a LEGO model and stop halfway through. A good instruction sheet lets you continue from the last completed step. A bad instruction sheet says only, “Something happened.” Recovery needs enough state to know what was already done and what remains.
A failure-aware graph needs state that answers at least three questions:
- Where was the graph? Current node, branch, or waiting state.
- What has already succeeded? Completed branch results and durable business facts.
- What external effects may already have happened? This is essential when deciding whether a retry is safe.
This is why state boundaries and node boundaries matter. If one giant node performs ten actions, recovery may have to repeat all ten. Smaller, meaningful units can improve observability and make recovery decisions more precise, although excessive fragmentation can add operational complexity.
LangGraph's current guidance, for example, recommends explicit state and uses persistence/checkpointing to support pause-and-resume patterns. Its documentation also notes that node granularity influences how much work is repeated after a failure. LangGraph workflow and state guidance.
OpenAI's current Agents SDK documentation similarly describes durable run state for human approval flows and emphasizes that approval snapshots must be kept under application control and validated before resuming execution. OpenAI Agents SDK durable approval flow.
The general graph-engineering lesson is simple: recovery should resume from trusted state, not from memory reconstructed by guesswork.
run_id: "<RUN_ID>",
current_node: "risk_check",
attempts: 2,
completed_steps: ["supplier_check", "po_match"],
pending_action: null,
terminal: false,
stop_reason: null
}
Notice that state is not just conversational text. It is operational data. That means it deserves schema design, access control, retention decisions, and careful handling of sensitive fields.
Risk → Recovery state can contain confidential inputs, tool arguments, approval decisions, and identifiers that were never intended for end-user modification. Control → Store authoritative state server-side, enforce access control, minimize sensitive fields, and treat serialized state as untrusted unless its integrity and ownership are verified. Remaining risk → Retaining more state can increase privacy and breach impact, so persistence should be purposeful rather than unlimited.
Your workflow can pause, resume, retry after failure, wait for a human, or survive a process restart.
08
Test Failure Paths as Seriously as Success Paths
A graph is not production-ready because its happy path works once. The interesting questions begin when a branch fails on attempt two, a human responds late, a tool succeeds but the response is lost, or cancellation arrives during a long-running action.
A practical test matrix should include:
| Test | Expected behavior | Evidence to inspect |
|---|---|---|
| Transient failure on first attempt | Retry once under policy | Attempt count and backoff |
| Permanent validation failure | No pointless retries | Correct exception route |
| Retry exhaustion | Recovery or escalation | Reason and branch transition |
| Approval rejected | Blocked action does not run | Tool call absence and terminal state |
| Approval replay | Duplicate decision is rejected | Atomic state transition |
| Timeout after possible side effect | Reconcile before repeat | Business operation ID and downstream status |
| Cancellation during execution | No new work after cancellation boundary | Cancellation reason, cleanup, final state |
The graph should also be tested for structural properties rather than only outputs. Examples include:
- Can a retry route loop indefinitely?
- Can a branch reach a privileged tool without the intended authorization checkpoint?
- Can a terminal node accidentally point back to an active node?
- Can two approval submissions resume the same work twice?
- Can a canceled run schedule new side-effecting actions?
- Can an optional branch failure accidentally block a mandatory completion path?
Tracing is particularly valuable here because a workflow failure is often a sequence problem rather than a single-event problem. OpenAI's current Agents SDK documentation describes tracing of agent runs, tool calls, handoffs, and guardrails; other orchestration platforms provide their own histories and event models. The engineering requirement is broader than any one product: you need a trace that lets an operator reconstruct what the graph believed, what it attempted, what failed, and why it chose the next route. OpenAI Agents SDK tracing.
For evaluation, useful metrics include:
| Metric | What it tells you |
|---|---|
| Retry success rate | How often bounded retries actually recover transient failures. |
| Retry waste | How much work is repeated without improving the outcome. |
| Escalation rate | How often automation reaches a human boundary. |
| False continuation | Cases where the graph continued despite incomplete mandatory conditions. |
| Duplicate side effects | Cases where retries or recovery caused an external action more than once. |
Risk → A test suite can confirm that a graph reaches the expected node while missing a security problem such as unauthorized approval, sensitive state exposure, or a repeated external effect. Control → Test route, state, authorization, side effects, and observability together. Remaining risk → Tests sample scenarios; they cannot prove all future model behavior or every future downstream failure.
The workflow has enough operational importance that “it worked in a demo” is no longer an acceptable reliability argument.
09
Enterprise Rollout
Enterprise graph engineering should begin with a failure policy, not with retry configuration buried in code.
Step 1 — Define the workflow states. Write down active, waiting, completed, failed, escalated, canceled, and timed-out states only where they make sense for the business process.
Step 2 — Classify failure types. Separate transient errors, invalid inputs, authorization failures, business rejections, tool errors, unknown exceptions, and ambiguous external outcomes.
Step 3 — Assign an owner to each transition. Some transitions belong to deterministic code. Some depend on a human. Some can be suggested by the model but must be enforced by the application or downstream system.
Step 4 — Set budgets. Define attempt, time, tool-call, and business-risk limits that match the workload.
Step 5 — Define side-effect rules. For every external write, document whether it is idempotent, conditionally idempotent, or unsafe to repeat.
Step 6 — Design the escalation contract. Specify who can approve, what evidence the reviewer sees, how the decision is stored, how long it remains valid, and where the graph resumes.
Step 7 — Instrument transitions. At minimum, record workflow ID, node, branch, attempt, failure class, timestamps, authorization result, stop reason, and downstream operation identifier where relevant.
Step 8 — Test failure deliberately. Inject controlled timeouts, rejected approvals, stale state, duplicate submissions, and cancellation into non-production environments.
Step 9 — Review production policy periodically. Retry behavior that was sensible for one traffic pattern can create waste or overload after scale changes. The same applies to escalation thresholds and budgets.
NIST's AI Risk Management Framework is not a workflow-graph standard, but it provides a useful lifecycle lens for governing and evaluating AI systems. Its Generative AI Profile focuses on identifying and managing generative-AI-specific risks, while NIST's AI Resource Center emphasizes testing, evaluation, verification, and validation. NIST AI RMF and NIST Generative AI Profile.
For every important node, maintain a small contract containing: inputs → success condition → failure classes → retry rule → side-effect rule → escalation rule → stop rule → observable evidence. This turns failure handling into something reviewers can inspect rather than tribal knowledge hidden inside implementation details.
Production reliability improves when failure behavior is treated as part of the workflow contract rather than as an afterthought in exception handling.
10
Common Mistakes
Mistake 1: Retry the whole workflow instead of the failed operation.
The cause is convenience: restart from the beginning. The consequence is duplicated work and possibly duplicated side effects. The correction is to identify a recovery boundary and preserve valid completed state.
Mistake 2: Retry every error.
The cause is treating all failures as temporary. The consequence is wasted time, excess load, and repeated requests that can never succeed without changed input or authorization. The correction is to classify failure types and retry only eligible cases.
Mistake 3: Use the same retry policy for every node.
A document read, an authorization check, and a financial write do not necessarily have the same retry characteristics. The correction is node-specific policy based on operation semantics.
Mistake 4: Let the model decide whether an action is authorized.
A model can propose a route, but downstream authorization should remain enforceable by the system performing the action. OWASP explicitly recommends enforcing authorization in downstream systems rather than relying on an LLM to decide whether an action is allowed. OWASP excessive-agency guidance.
Mistake 5: Escalate without enough state.
The cause is building the human handoff at the end rather than as part of the workflow contract. The consequence is a reviewer who cannot understand why the system stopped. The correction is to package evidence, blocked action, failure reason, and decision choices.
Mistake 6: Treat approval as permanent.
A human decision may be valid only for a specific action, state, time, or record. The correction is to bind approval to the authoritative pending action and validate it again at resume time.
Mistake 7: Forget cancellation.
A workflow that can start work but has no defined cancellation behavior is incomplete. The correction is to specify what stops immediately, what finishes safely, what requires compensation, and what external work may continue independently.
Mistake 8: Log the error but not the transition.
The error message tells you what failed; it does not always tell you why the graph chose its next node. The correction is to trace the decision, route, attempt count, and terminal reason together.
Mistake 9: Allow approval fatigue.
If humans approve dozens of trivial actions, they may pay less attention to consequential ones. The correction is risk-based approval: reserve human attention for actions where human judgment genuinely adds value.
Mistake 10: Assume a sandbox solves workflow safety.
A sandbox can isolate certain execution capabilities, but it does not automatically define business authority, downstream permissions, data segregation, completion rules, or retry semantics. The correction is to treat sandboxing as one boundary inside a larger control design.
You are reviewing an agent workflow that already “works” but has not yet been examined for failure amplification, repeated side effects, stale approvals, or uncontrolled continuation.
11
❓ FAQ
What is the difference between a failed branch and a failed workflow?
A failed branch means one route or task did not complete successfully. The workflow may still recover, use a fallback, wait for a human, or continue through another valid route. A failed workflow means the overall process reached a terminal failure state.
Should an AI agent retry its own tool failures?
Sometimes, but the retry policy should not depend only on the model's judgment. The graph or runtime should define which failures are retryable, how many attempts are allowed, and what happens after exhaustion. Side-effecting operations also need an idempotency strategy or an explicit decision not to retry.
When should a workflow escalate instead of retrying?
Escalate when the issue requires missing information, human authorization, business judgment, risk acceptance, or a decision that is outside the automated path. Escalation is also appropriate when bounded recovery has been exhausted and no safe automated fallback exists.
What does safe stopping actually protect?
It protects the workflow from uncontrolled continuation. Attempt limits, deadlines, cancellation rules, approval expiry, explicit terminal states, and business completion checks prevent a graph from continuing simply because no one programmed a clear stopping point.
Can retries and human approval be combined?
Yes. A common pattern is to retry transient failures first, then escalate when the retry budget is exhausted or when the remaining action requires human authority. The graph should preserve the evidence that led to escalation and resume only from a state that still matches the approved action.
12
🔗 References & Further Reading
- LangGraph — Thinking in LangGraph — current documentation illustrating explicit nodes, state, error classes, retry policies, interruptions, recovery, and checkpoint-oriented workflow design.
- OpenAI Agents SDK — Human-in-the-loop — approval interruptions, resume behavior, and approval-state protection.
- OpenAI Agents SDK — Guardrails — input, output, and tool guardrails and their workflow boundaries.
- OpenAI Agents SDK — Tracing — current tracing model for runs, tool calls, handoffs, guardrails, and custom events.
- Google Cloud — Retry Strategy — retryability, idempotency, exponential backoff, jitter, deadlines, and retry anti-patterns.
- Temporal — Tasks — workflow tasks, activity attempts, retries, cancellation, event history, and recovery behavior.
- Temporal — Durable AI — current durable-AI patterns including approval workflows, compensation, long-running activities, and stateful agent execution.
- OWASP GenAI Security Project — LLM06:2025 Excessive Agency — minimizing tools, permissions, and autonomy and using downstream authorization and human approval for high-impact actions.
- NIST — AI Risk Management Framework — lifecycle risk-management context and links to evaluation resources.
- NIST — Generative AI Profile — generative-AI-specific risk-management guidance.
Vendor and standards names remain the property of their respective owners.
Google's current guidance says structured data does not guarantee a rich result, and FAQ rich results are generally limited to well-known authoritative government and health sites. For a technical blog, keep FAQ structured data consistent with visible content, but do not promise an FAQ rich result. Google Search Central FAQ change guidance.
13
📝 Summary
- Failed branch ≠ failed workflow. Preserve valid work and choose the correct recovery route.
- Retry transient failures, not everything. Consider idempotency before repeating side effects.
- Bound every retry. Attempt, time, tool, and business-risk budgets all matter.
- Escalation is an authority boundary. Give the human the evidence and the exact decision that is needed.
- Safe stopping is part of graph design. Define terminal states instead of assuming the workflow will know when to stop.
- State makes recovery possible. Preserve what succeeded, what failed, and what external effects may already have happened.
- Test the failure graph. Production reliability depends on route behavior, not just successful model outputs.
A well-engineered AI workflow is not the graph that never fails. It is the graph that fails in understandable ways, retries deliberately, escalates when authority changes, and stops before failure becomes uncontrolled action.
Comments
Post a Comment