Sequential Is the Default

Most teams should ship sequential first. The graph is code. You can put HITL after the worker and before apply. You can unit-test “billing tickets never skip policy.” You can explain the path to a regulator without a transcript of a model arguing about VIP exceptions.

Sequential is a workflow that happens to contain agents. Each node might be a specialist policy, a rules function, or a human form. The order is not a specialist’s job. If billing can skip HITL “because the user is VIP,” your graph is a suggestion box. Suggestion boxes do not pass audits.

The previous lesson compared three modes. This lesson is why the default is the boring one. Fancy peer handoff feels more “agentic.” It is more expensive to test. Stable graphs do not need it.

The pipeline list is the product

PIPELINE = ["intake", "policy", "hitl", "apply"] is not a sketch. It is the allow-list of order. Intake may classify. Policy may score. HITL may set approved. Apply may move money only if approved is true. No node inserts itself. No node deletes HITL.

Workers inside a node still have tool isolation. Sequential does not mean one allow-list. It means the next node is not elected. The coder node still cannot refund if refund lives in apply. The critic still cannot write. You compose this track’s roles inside nodes.

Do not let workers vote on orchestration. A model output skip_hitl: true must be ignored or rejected. The function in the box refuses that flag. In production, do not even parse a skip field. If the field does not exist, it cannot be set.

HITL is a node. A human in the loop is not a critic with writes and not a chat reaction emoji. It is a step that waits, records approved_by, and only then allows apply. Timeouts on HITL are a stop: escalate or cancel, do not auto-approve because the model is impatient.

Tests without tokens. run_pipeline("refund 99") must include hitl in the path. skip_hitl=True must error. Illegal tickets can still run the list and fail at policy. That is a policy fail, not a graph fail.

Walkthrough: refund 99 cannot skip HITL

Happy path: intake sets category billing, policy sets ok, HITL sets approved, apply sets done because approved is true. Path is the four names. Done is true.

Skip attempt: the runtime does not even start the loop. It returns skip_hitl_not_allowed and the original steps. World unchanged. This is the same spirit as critic-cannot-write: the control plane is not a tool the model holds.

If apply ran without HITL because a developer commented the node out, that is a code review failure sequential is good at catching — the list is in git. Handoff graphs hide the same bug in a prompt that “usually” visits HITL.

VIP customers still hit HITL. If legal wants a faster path, that is a different subgraph with its own review, or a higher-trust HITL queue — not a boolean the billing worker sets. The subgraph lesson will keep HITL inside the billing list. This lesson is the list itself.

Sequential also makes latency honest. You can time each node. You can budget tokens per node. Peer handoff hides latency in a soup of hops. When a PM asks why refunds take 40 seconds, sequential answers “HITL wait.” Handoff answers “they were talking.” Operators can staff HITL. They cannot staff a conversation.

Run to execute this in your browser. Nothing is sent to a server.

What printed: the happy path is path of four names and done: True. The skip flag is an error with the pipeline list still shown, no done. The model does not get a vote. A worker cannot skip HITL with a flag from the model — the function refuses.

Apply in this toy does not check state["ok"] from policy. Production should. Sequential makes that check local to the apply node: if policy failed, apply must not run, which you enforce by breaking the loop or by a gate before apply. Do not rely on the billing worker to remember.

Sequential is not “no LLMs”

Intake can be a small classifier model. Policy can be retrieval plus a rubric. The writer node can be an LLM. Sequential only forbids those models from rewiring the list. You still use specialists. You still use typed handoffs into each node (the node’s input is a payload, not a novel). You still keep a single-agent baseline for tickets that never needed two nodes.

If the graph changes every ticket in ways you cannot encode as a finite set of pipelines, you may need a supervisor picking subgraphs, or — rarely — peer handoff with caps. Prove that with failed sequential goldens, not with a slide.

How agents use this

Orchestration policy belongs in code and flags, same as authz. Trace orchestration.mode=sequential. Trace the path. Alert if apply runs without a prior hitl event on billing jobs.

When a product manager asks for “more autonomy,” translate: which node should the model own, and which nodes stay code? Autonomy on intake classification can be fine. Autonomy on skipping apply gates is not.

Keep the pipeline list in config so you can add a notify node without teaching workers a new social protocol. Review diffs to PIPELINE like you review diffs to IAM.

If you later wrap this pipeline in a supervisor, the supervisor only picks billing vs tech. It does not get a skip_hitl tool. The next lessons are hop limits for the day you do use peers, then the star so workers cannot rewrite the graph in DMs.