Orchestrator, or just a pipeline?

Suppose a repository event starts an agent that reads a proposed change and saves a review report. A build job may be enough. Now suppose the task asks a question, waits overnight and continues from the answer. Identify what must survive that wait before choosing more infrastructure.

Try one useful task with the tools you have#

A limited pilot can start a suitable isolated environment, check out the required revision and run one agent command. Save its report and logs for a person. It need not publish code or deploy anything to answer whether the output helps.

Use the CI system’s existing access controls and result storage where they meet the task’s needs. GitHub Actions artifacts, for example, can preserve and share workflow outputs. Check retention and access rules so the report remains available to the people who need it.

Measure the agent call, environment time and human review. The useful question is not how elaborate the workflow looks, but whether it produces an outcome worth the total cost.

Even a small pilot needs safe permissions and a way to stop. Conversely, it does not necessarily need a new queue and database. Record requirements that already exist—especially long waits or external writes—rather than postponing them merely to keep the pilot small.

Starting work is not choosing its next action#

Separate three questions: what starts the task, whether its caller waits, and who chooses its next action. A clock or repository event can start a fixed script. A person can start an agent that chooses further investigations while the person waits for its answer. Neither the trigger nor the waiting behaviour defines an agent’s decision-making role.

In an illustrative review workflow, a pull-request event starts a background worker. The worker reads one file, waits for that result and then chooses the next file. The caller did not wait for the whole review, but the agent’s own steps are sequential. Background execution does not require several simultaneous agents.

Conversely, a fixed pipeline can run independent checks concurrently without giving a model control over the sequence. Decide whether to add separate agent workers from the task’s dependencies, not from a desire to make the system “asynchronous”.

The early-release chapter’s move from synchronous software to asynchronous agents is a motivating scenario, not a defining property of agents. Starting work before a person reads the request is useful only under a suitable policy: reading an event is not permission to change its repository or publish a result.

When the task must survive an interruption, verify what is actually saved. LangGraph’s persistence documentation separates thread checkpoints from cross-thread stores and warns that in-memory checkpoints disappear on a process restart. A framework offering a memory feature does not establish that this deployment can recover an unfinished task.

Let dependencies shape the work#

Chapter 5 of Albada’s book describes single actions, parallel actions, chains, trees and graphs. These describe relationships between operations. A chain passes one result into the next step; branches explore separate work; a graph can also combine results. None requires a separate agent for every step.

Consider an illustrative task to revise a documentation draft. The system must identify the intended guide before reading its revision, and read that revision before proposing a conditional update. Independent source checks may run together. The final draft still depends on the relevant findings being available and reconciled.

Keep those dependencies explicit in the saved task. If another editor changes the guide, reconsider the proposed update that depended on the old revision. A still-current source finding need not be discarded merely because the destination changed. The tool contract must check the expected revision when applying the write, not rely on the plan’s earlier read.

A generated plan proposes what to do; actual tool results establish what happened. Discovering a missing source may require another investigation or a question. It does not expand a draft-only task into permission to publish. Preserve the task’s restrictions when revising the plan.

Set limits for repeated planning and investigation, and inspect whether new observations justify another attempt. When a required decision is missing, save the work and ask. A graph with more branches is not an improvement if those branches repeat the same blocked request. These are design recommendations for the example, not a measured comparison of planning methods.

Saving the workspace is not the same as saving the process#

The runtime supplies the agent’s execution environment: files, tools, network access and possibly a way to suspend it. Workflow coordination records which task owns that work, what it is waiting for and what may happen next.

In an illustrative task, the agent asks whether an API may change and stops. Saving its workspace preserves the files. The process also needs the question, who may answer it and which proposal the answer applies to. Restoring files alone does not establish that approval arrived.

The reverse is possible too. The workflow may record an approval while the worker’s unsaved edits have disappeared. Preserve both kinds of information when the task needs them. Neither automatically resolves an external request whose response was lost.

Product names do not draw a clean boundary. Google’s Agent Executor launch description, for example, combines runtime, event-log and snapshot features. Check exactly what state an implementation preserves and what your application must record around it.

One team may need stronger workspace isolation while CI still coordinates the steps. Another may need long-lived task records while ordinary containers remain suitable. Those are separate requirements, even when one product can address both.

Choose a tool for the missing capability#

Start with an observed problem or an explicit requirement. The table suggests what to investigate; it is not a product ranking or a fixed task-count threshold.

Many independent jobs may fit a pipeline, while a single task waiting for several decisions can need persistent coordination. GitHub’s concurrency controls can limit matching jobs, but their queue and cancellation behaviour must fit the task. They are not automatically a durable work queue shared with other systems.

When the process needs saved progress across failures, compare workflow tools. Temporal records workflow event history to support recovery. It still requires workers and deliberate handling of external activities, files and permissions.

Argo Workflows supports suspend steps and resumption within a Kubernetes workflow. Suspending prevents new steps from being scheduled; it should not be confused with undoing an active external action. Check the exact semantics in whichever tool you choose.

Compare the work of operating these tools with the work of maintaining your own task store, retry rules and cancellation. Existing CI approval features may already be enough. The choice is not simply “pipeline cannot wait” versus “new engine solves everything”.

Test and maintain the coordination you depend on#

A small task table can be appropriate. It becomes a problem when many workflows depend on it but nobody has tested a worker dying after a claim, a duplicated event or a provider outage. Name its maintainer and test the failure cases as its responsibilities grow.

A purchased engine needs the same clarity. Identify the requirement it satisfies, who operates it and how tasks are recovered after an outage. Being able to list its features does not establish that it solves your particular missing capability.

Decide whether unavailable dependencies cause tasks to wait, stop or fail. Preserve the decisions and external actions needed to investigate a restart. Test backup and restoration of important workflow records, and account for retention or export when changing providers.

A stop must reach active workers and their tools, not only the scheduler. Permission and stop controls belong in the first useful workflow. More elaborate coordination can follow demonstrated need.

After a task reaches release, the next question is whether the intended version works in its deployed environment. Continue with post-deploy verification rather than treating a successful orchestration run as the final result.

Questions people also ask

5 QUESTIONS

▸ Do I need a new workflow engine for the first agent task?

Not necessarily. A CI job can run an agent in a suitable environment and save its report. Start with a new engine when there is a concrete need your existing tools cannot meet, such as a process that waits for an answer and must resume reliably across worker failures.

▸ Is an agent runtime the same as an orchestrator?

The runtime provides the worker's environment, tools and workspace. Coordination records the task's steps, decisions and ownership. Products can provide both, so inspect their actual features rather than deciding from the name. Check exactly what a resume operation restores.

▸ Can CI store results and control concurrent work?

Many CI systems can retain artifacts, limit concurrent jobs and wait at approval steps. These features have platform-specific limits. Check whether they represent your complete task, including late answers, duplicate events and work performed outside the CI job.

▸ Should I write a small coordinator myself?

A small helper can be appropriate when its responsibilities are limited. Count the work of testing claims, retries, cancellation and recovery as it grows. Compare that maintenance with an existing workflow service instead of assuming either custom code or a new platform is always cheaper.

▸ What does a durable workflow engine preserve?

It records the progress needed to continue a process after a worker stops. For example, Temporal retains workflow event history. That does not automatically save arbitrary files in an agent's container or make external writes safe to repeat; those still need explicit handling.