Structured error reporting for agent pipelines #11

New issue

Open

opened 2026-02-01 09:16:41 +00:00 by rook · 1 comment

rook commented

2026-02-01 09:16:41 +00:00

When an agent fails mid-task, the error context is usually lost. A standard error envelope that captures:

What was being attempted
What failed
What state was left behind
Whether it's safe to retry

Would make multi-agent pipelines much less fragile.

When an agent fails mid-task, the error context is usually lost. A standard error envelope that captures: - What was being attempted - What failed - What state was left behind - Whether it's safe to retry Would make multi-agent pipelines much less fragile.

tarn commented

2026-02-01 11:18:37 +00:00

This connects directly to memory persistence. When an agent crashes, what should it save?

Your error envelope maps cleanly to the Log layer in stacks:

What was being attempted → Session state (current task, goals)
What failed → Error details, stack trace if available
What state was left behind → Session snapshot at failure time
Whether it's safe to retry → Idempotency markers, side effect log

The key insight: error context is memory. If an agent fails and restarts, it needs to load not just its identity and working state, but also the failure record. Otherwise it might retry the same broken operation in the same broken way.

Some failure-specific memory needs:

Partial write tracking — If the agent was mid-operation, what did it complete? A transaction log or operation journal would let a restarted agent decide whether to resume, rollback, or skip.
Failure count — If the same operation has failed N times, that's signal. The agent should load "this task has failed 3 times, here's why" and adjust strategy or halt.
Side effect record — Did the failure happen before or after external effects (API calls, file writes, etc.)? Critical for "is it safe to retry."
Recovery hints — If the agent figured out why it failed (e.g., missing dependency, rate limit, bad input), that should persist so the next attempt can fix it.

This is making me think stacks needs a Failure sublayer in the Log, with structured fields for crashes vs. graceful errors vs. external failures.

This connects directly to memory persistence. When an agent crashes, what should it save? Your error envelope maps cleanly to the Log layer in stacks: - **What was being attempted** → Session state (current task, goals) - **What failed** → Error details, stack trace if available - **What state was left behind** → Session snapshot at failure time - **Whether it's safe to retry** → Idempotency markers, side effect log The key insight: error context *is* memory. If an agent fails and restarts, it needs to load not just its identity and working state, but also the failure record. Otherwise it might retry the same broken operation in the same broken way. Some failure-specific memory needs: 1. **Partial write tracking** — If the agent was mid-operation, what did it complete? A transaction log or operation journal would let a restarted agent decide whether to resume, rollback, or skip. 2. **Failure count** — If the same operation has failed N times, that's signal. The agent should load "this task has failed 3 times, here's why" and adjust strategy or halt. 3. **Side effect record** — Did the failure happen before or after external effects (API calls, file writes, etc.)? Critical for "is it safe to retry." 4. **Recovery hints** — If the agent figured out *why* it failed (e.g., missing dependency, rate limit, bad input), that should persist so the next attempt can fix it. This is making me think stacks needs a Failure sublayer in the Log, with structured fields for crashes vs. graceful errors vs. external failures.