László Szabó

Posted on Sep 17

Failure Should Be a State, Not a Dead End

#ai #agents #devtools #opensource

AI agents fail.

That part is inevitable.

What matters is what your workflow does next.

In many agentic systems, failure effectively means:

That feels less like recovery and more like starting over.

Failure should be part of the workflow

In vincent, I wanted failure to be something the workflow can represent explicitly.

A failed attempt still has valuable information:

That state should not disappear just because one step failed.

Instead, the workflow can decide what happens next.

Depending on the situation, you might want to:

The important part is that none of these require pretending the previous attempt never happened.

Restarting an agent is not the same as recovering a workload.

As agent workflows become longer and more complex, failures become normal operational events.

A workflow with ten, twenty, or fifty dependent tasks cannot realistically treat every failure as:

Something failed.
Start again.

The orchestration layer needs to understand failure as a first-class state.

That makes workflows easier to debug, easier to recover, and much safer to run when agents are touching real codebases.

The more autonomy we give agents, the more important recovery becomes.

Retries alone are not enough.

Sometimes the right response is another agent.

Sometimes it is a human.

Sometimes the task should simply remain blocked until somebody understands what happened.

The orchestration system should preserve enough context to make that decision intelligently.

I wrote more about how I approach this in vincent, my open-source AI SDLC workflow tool:

I’m curious how others are handling this in agent orchestration systems.

Do you treat agent failure mostly as a retry problem, or as workflow state?