AI Team Orchestration: Coordinate Agents and Shared State

AI team orchestration is the work of coordinating multiple agents around a shared goal: deciding which agent runs, in what order, with what inputs, and what to do when one of them fails. It is the difference between a collection of agents and a system that can be trusted to complete a task.

Getting it right requires separating two things that are easy to conflate: the runtime state the orchestrator manages during a run, and the durable record of what the team decided, what was completed, and where things stand. Tools like fenbs hold the lasting part outside any one run, so any agent on the team starts from the same shared context. AI workflow orchestration patterns are covered separately at their own page.

The two jobs of an orchestrator

An orchestrator has two distinct jobs, and confusing them causes most coordination failures.

The first job is routing: deciding which agent runs at each step, passing the right inputs, and collecting the result. This is runtime work. It happens inside a run, uses the run's in-memory state, and its output is a completed task or an error.

The second job is governance: recording what was approved, what was decided, and what the team has agreed should always happen. This is not runtime work. It belongs in a durable store that survives restarts, model changes, and new team members.

Common orchestration patterns

There are three patterns used in most multi-agent systems.

• Sequential: agents run one after another, each receiving the previous agent's output. Simple and predictable; fails entirely if one step fails.
• Parallel: agents run at the same time on independent subproblems, and the orchestrator collects results. Faster, but requires a merge step and a plan for partial failure.
• Conditional: the orchestrator routes to different agents based on intermediate results or a person's decision. Flexible, but the branching logic must be documented and tested.

Most real systems combine all three. A top-level task fans out to parallel agents, each of which runs its own sequential steps, and a conditional branch routes to a human review agent when confidence is low.

Dependency tracking

When agents depend on each other's outputs, the orchestrator must know which dependencies are satisfied before starting each step. An agent that runs before its inputs are ready either fails immediately or produces incorrect results quietly.

Model dependencies explicitly. A task graph with named nodes and typed edges is harder to build than a flat list of steps, but it makes the order enforceable and the failures readable. When step C depends on steps A and B, the orchestrator can show you exactly which dependency is blocking progress.

Also separate data dependencies from approval dependencies. A step might have its inputs ready but still need a person to sign off before it runs. Those two dependency types need different handling: data dependencies are checked in code, approval dependencies are checked against a human decision record.

Recovering from partial failures

Partial failure is the hardest case in orchestrated systems. Three steps complete, the fourth fails, and now the question is what to do with the work the first three steps produced.

Decide your recovery strategy before you need it. The three main options are retry from the beginning (safe but wasteful), retry from the last successful checkpoint (efficient but requires checkpoint storage), and surface to a person and wait (safest for irreversible actions).

Checkpoints reduce retry cost but must be designed into the task, not added later. A checkpoint captures the state the next step needs to continue: completed outputs, current values of shared state, and any approvals already given. Store checkpoints in the same durable record as the task, not in the orchestrator's in-memory state.

The AI agent governance guide covers how to decide which failures need human review and which the orchestrator can handle automatically.

Shared state in a multi-agent team

When agents share state, writes must be ordered and attributed. An agent that writes without recording who wrote what, and when, leaves the next agent with no way to know whether the current value is up to date.

Use a single canonical store with a schema. Schemaless shared state is the fastest path to an agent reading a stale value and not knowing it. Schema validation at read and write catches the mismatch at the source.

Split state by lifetime. Volatile state for this run lives in the orchestrator's own memory or a short-lived cache. Durable state that must survive restarts lives in an external store. The distinction prevents the common failure of an agent treating a cached value as ground truth after a restart. The AI memory for teams guide goes deeper into shared memory design.

How to do this with fenbs

1. Create a free account and model your orchestrated work as tasks in fenbs. Each agent role in the system gets one or more tasks with a clear plan and owner.
2. Write the approved rules for your orchestration in Decisions and rules: which agent can approve what, which failures need human review, what the retry policy is. Connect your AI assistant from Integrations so it reads those rules before each run.
3. After each run, have the orchestrator update task progress in fenbs: completed steps, checkpoint state, and any decisions made. This is the durable record the next run starts from.
4. When a partial failure occurs and a human decides how to proceed, record that decision in fenbs. The orchestrator reads it on the next run and follows the approved path.
5. After a postmortem, record lessons learned. The next assistant doing similar orchestration work reads them before starting.

fenbs is the record alongside the orchestrator, not a replacement for it. Fast routing, retry logic, and in-run state belong in the orchestrator. The approved plan, the task record, and the handoffs belong in fenbs.