Glossary

Agent orchestration

Deciding which agent does what, in what order, and what happens when one fails.

Definition

Agent orchestration is the coordination of AI agents and their steps: routing a task to the right agent or model, sequencing multi-step work, passing state between steps, enforcing limits, handling retries, and managing handoffs between agents and to humans. Orchestration is a control layer above the individual agent loop, and it is where most reliability problems in multi-agent systems are solved or created.

Layer: Above the agent loop
Main patterns: Single loop, manager, pipeline, graph
Failure domain: State, retries, handoffs

Why it became a separate concern

A single agent in a single loop needs no orchestration: it calls tools until it is done. Coordination becomes a distinct layer as soon as one of three things is true: several agents with different specialities are involved, work spans multiple runs or machines, or the run is long enough that failures have to be recovered rather than restarted.

The vocabulary was borrowed wholesale from distributed systems and workflow engines, which is appropriate, because the problems are the same ones: idempotency, at-least-once delivery, partial failure, and knowing what state the world was in when something broke.

The four patterns you will meet

Single agent, tool loop
One agent calls tools repeatedly until the goal is met. The simplest thing that works, and correct far more often than the alternatives suggest.
Manager and sub-agents
A coordinating agent decomposes the goal and delegates to specialists, then assembles their results. Good for breadth; the coordinator becomes the reliability bottleneck.
Sequential pipeline
Fixed stages, each with a defined input and output, such as research, then draft, then review. Predictable and easy to debug, at the cost of flexibility.
Graph or state machine
Nodes with explicit transitions and conditions. The most controllable option and the most work to author; the pattern behind most production agent frameworks.

Commonly confused with

Term	What it is	The difference
Workflow automation	Event-triggered rules with authored branches	Every path exists before run time. Orchestration coordinates agents that choose paths at run time.
Multi-agent conversation	Several agents exchanging messages in a shared thread	One technique within orchestration, not a synonym for it.
Prompt chaining	Feeding one model output into the next prompt	A single-process technique with no scheduling, state store or failure handling.
Container orchestration	Scheduling containers across machines, as Kubernetes does	Unrelated to agents. The shared word causes real confusion in search results.

Where Polaris sits

Polaris uses the simplest arrangement that supports the product: an agent_jobs queue in Postgres that a runtime service claims work from, one job per assigned task, running a single agent in a tool loop with retries on failure. There is no manager agent and no graph, because a task assigned to a named worker with written acceptance criteria is already decomposed by the person who wrote it.

The queue contract is deliberately runtime-agnostic, so the machine behind it can be swapped without changing the product.

Task queue

The thing that lets a request survive the process that made it.

Agent runtime

Not the model, not the framework: the thing that actually runs the job.

Autonomous agent

Autonomy is a range, and the interesting question is where the boundary sits.

Headless agent

Nobody is typing at it, so its output is actions and artefacts rather than replies.

Model Context Protocol (MCP)

One protocol between models and the systems they need, instead of one integration per pair.

How long an agent session can run, and what happens when it ends

Every agent runtime has bounds. The useful thing a vendor can do is tell you what they are.

Questions people ask

+Do I need a multi-agent system?

Usually not at first. Multiple agents add coordination overhead, more failure modes and harder debugging, and they pay off mainly when specialities genuinely differ or when work must run in parallel. A single well-briefed agent with the right tools handles most tasks that teams reach for orchestration frameworks to solve.

+What breaks most often in orchestrated agent systems?

State handoff between steps. An agent that produced good work in step one hands an ambiguous summary to step two, which acts on a subtly wrong premise. Explicit, structured outputs between stages fix more failures than better prompts do.

+Is orchestration the same as an agent framework?

A framework is a library that helps you implement orchestration; orchestration is the design problem the library addresses. You can orchestrate agents with a database table and a worker process, which is what many production systems actually do.