Skip to main content
Non-fatal errors expose callback and memory failures that used to be silently swallowed, so your agent can see what went wrong without crashing the workflow.
The user runs a workflow; callback or memory failures surface on the task output without stopping the run.
Important Change: LLM errors are no longer non-fatal by default. They now raise LLMError exceptions instead of being captured as non-fatal errors. See Structured LLM Errors for details.

Quick Start

1

Simple Usage

2

With Configuration


How It Works


Error Classification

Non-Fatal Errors (Captured)

These errors are captured and stored in non_fatal_errors without stopping task execution:
  • Callback failures: Exceptions in task callback functions
  • Memory operation failures: Memory storage, retrieval, or quality check failures
  • Non-critical integrations: Optional service failures

Fatal Errors (Raised)

These errors now raise exceptions and stop task execution:
  • LLM errors: Chat completion failures (now raise LLMError)
  • Tool execution failures: Critical tool failures (raise ToolExecutionError)
  • Validation errors: Configuration or input validation failures

Common Patterns

Pattern A: Skip to next task only when callback succeeded

Pattern B: Route failures to alerting system


User Interaction Flow


Best Practices

Always inspect the output before chaining tasks. A task that completed with non-fatal errors may not have produced the expected result.
If quality_check=True was requested but the memory adapter isn’t ready, the task still completes. Check non_fatal_errors for memory-related issues.
If a callback must block the workflow on failure, re-raise inside it. The framework currently captures the message but does NOT re-raise automatically.

Display System

TaskOutput fields and terminal display hooks

Structured LLM Errors

Fatal LLM errors that stop task execution