AI Workflow Controller: Route Work, Check State, and Recover
An AI workflow controller routes tasks to the right agent, checks state at each step, and decides what to do when something fails. Here is what that role involves and how to keep approved rules and history alongside it.
Updated 5 min read
An AI workflow controller is the component in a multi-agent system that decides what runs next: which agent, with which input, under which conditions. It is the piece that separates an agent harness from a list of API calls.
The controller handles routing, state checking, and recovery. But decisions about what the workflow is allowed to do, and how it has behaved over time, belong outside the controller. Tools like fenbs hold the approved rules and work history that give the controller something to defer to when a person must decide. AI workflows for education, research, advertising, and SEO are covered on their own pages.
What a workflow controller is responsible for
Three responsibilities define the controller role.
- Routing: given the current state and a set of candidate agents, decide which one runs next. This may be a fixed sequence, a conditional branch, or a dynamic decision based on an earlier agent's output.
- State checking: before running each step, verify that the preconditions are met. After running it, verify that the result matches what was expected.
- Recovery: when a step fails or produces an unexpected result, decide what to do. Retry, skip, route to a fallback agent, or surface the problem to a person.
A controller that handles all three reliably is genuinely useful. One that handles routing but not recovery will produce silent failures in production.
Routing patterns
The simplest routing pattern is a fixed sequence: agent A, then agent B, then agent C. This is easy to test but fragile when one step can fail or when conditions change between runs.
Conditional routing is more flexible. The controller reads the current state, applies a rule, and routes to the appropriate agent. The rule might be as simple as "if the previous step produced an error, route to the error handler" or as complex as "if confidence is below a threshold, route to a human review agent."
Dynamic routing — where an agent itself decides the next step — is the most flexible and the hardest to audit. When an agent can route to any other agent, the controller's decision path is determined at runtime and may be different every run. Keep dynamic routing bounded: the agent picks from a defined list, not from the entire system.
Checkpoints
A checkpoint is a saved state the controller can return to when a later step fails. Without checkpoints, failure means starting over. With them, recovery can start from the last known good state.
Design checkpoints around the cost of repetition. An agent that calls an external API to generate a report should checkpoint the result before passing it on. An agent that only transforms data already in memory probably does not need a checkpoint for that step.
Checkpoints must be stored outside the controller's in-memory state to survive restarts. They also need metadata: which task they belong to, which step they follow, and when they were written. A checkpoint without provenance is hard to trust at recovery time.
Keep the approved rules the controller reads
fenbs holds the Decisions and rules that your workflow controller defers to: which steps need human approval, what the retry policy is, which agents are allowed to route to production. People record decisions once; the rules appear first in the AI context every connected assistant reads before acting. Create a free account and write your first three rules.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Failure recovery
Failure recovery is where most workflow controllers underinvest. The common pattern is to retry three times with exponential backoff and then throw an error. That is a reasonable default for transient network problems and a poor fit for everything else.
Match the recovery strategy to the failure type. A transient API error warrants a retry. A result outside the expected schema warrants a routing decision, not a retry: repeating the call will likely produce the same malformed result. An action that changed external state warrants human review before any retry: you need to know what the first attempt left behind.
Keep a ceiling on automated recovery. An agent that retries indefinitely is a resource drain and a source of duplicate actions in external systems. Set a maximum retry count and a maximum total runtime. When both are exhausted, surface the task to a person with a clear description of what was tried and what failed.
The AI agent approval workflow guide covers how to structure the human review step in a controlled workflow.
Keeping a readable work history
A workflow controller that logs everything to a flat file has a history; it does not have a readable one. A person reviewing a multi-step run needs to answer two questions quickly: what did the controller decide at each step, and why?
Structure the history log so each entry records the step, the input state, the decision made, the agent called, and the result. Include the reason the controller chose that path: the rule it applied or the condition it evaluated. A log that says "step 3: routed to agent B" is less useful than "step 3: confidence 0.61 below threshold 0.80; routed to review agent."
Store the work history in a place a person can read without running the system. An AI brain that holds work history outside the runtime makes that record available in any tool, without replaying the logs.
How to do this with fenbs
- Create a free account and add the workflow as a project in fenbs. Each major phase is a task with a plan, a status, and the approved conditions for completion.
- Write the routing and approval rules in Decisions and rules. Record which steps need human sign-off, what the retry limits are, and which agents are authorized for which actions. Connect your AI assistant from Integrations so it reads these rules before acting.
- After each controller run, update the relevant tasks in fenbs with what happened: which steps completed, which failed, and what decision was made at each branch.
- When a failure requires a human decision, record the outcome in fenbs as a decision. The next run reads it and follows the approved path instead of making the same routing choice again.
- Review the work history in fenbs with the team after a significant run. Use what you find to update the rules or add a lesson for future similar work.
fenbs does not replace the controller's own logging. Fast, per-step logs belong in your observability stack. The approved rules, task-level decisions, and human review outcomes belong in fenbs, where any connected assistant can read them before the next run.