Why pipeline is not enough

The first diagram on many whiteboards is a straight line: fetch recipes, rank, format plan, display. Teams ship it, attach an LLM to each box, and declare victory. The demo works for happy paths. It fails quietly when critique must loop, authority must gate a purchase, or one evening needs local repair instead of full regeneration.

Pipelines are legitimate implementation shapes. They are not complete architecture when outcomes require review, delegation, and designed stopping. The gap is not "missing intelligence." The gap is missing ownership vocabulary for goals, judgments, and sufficiency. A team can fill every stage in the pipeline with a capable model and still lack architecture, because model quality cannot substitute for the design decisions that determine when to stop, when to revise, and when to return leadership to a human.

Helpful context: Pipelines are not agents names the fixed-path case. What is a skill packages known capabilities with contracts. What is an agent adds goal pursuit and loops.

Pipeline versus Meal Companion loop

A pipeline sketch for meal planning might read: fetch recipes, emit text, show UI. Same path every run. "Done" implicitly means the last stage completed. Judgments stay unnamed inside stages. Critique, if it exists at all, is another box with no transition vocabulary.

Meal Companion architecture looks different. An agent owns accepted weekly plan as a declared goal. Critique leads to patch, fetch, ask, or escalate transitions. The minimum sufficient loop and stop rules define when pursuit ends. cognitive units and skills expose contracts and suites at named boundaries.

Recipe fetch, plan text, and display can remain linear inside perform work. Critique, RecommendMealSubstitution, deterministic patch apply, and escalation when constraints conflict are skill and agent work. The pipeline pieces did not disappear. They stopped being the whole story.

What pipelines omit

Even sophisticated DAGs often lack architectural elements production systems need. Goal ownership is missing: who declares success? A pipeline ends at the last stage without owning whether the user accepts the result. Review decisions are missing: accept, patch, replan, ask, escalate, and stop are how pursuit stays accountable. Authority grants are missing, especially before acting on the world, where recommend versus purchase remains invisible. Procedure versus judgment evaluation stays conflated when everything is a stage name. Working state disappears when each stage forwards text to the next, and accepted partial work gets lost.

Those omissions are not fixed by adding another box to the DAG. They require cognitive orchestration: named cognitive units for decide work, skills for perform work, agents for pursue work, and code for exact gates.

A pipeline executes. A skill performs a capability. An agent pursues a goal.

The cognitive unit · Ch. 16

When a pipeline is enough

A linear path belongs when transforms are stable, failure modes are local, and no one must pursue an outcome across changing evidence. Extract text from PDF. Normalize a date field. Render a template. These are honest pipelines.

Promotion to a skill happens when the capability deserves reuse and measurement as a procedure. Named inputs and outputs, seam tests, and recovery paths belong at the skill boundary even if the internal shape stays a DAG. Promotion to an agent happens when case shape requires discovery, revision, and designed stopping. When evidence can change what work happens next, a linear executor is the wrong owner. The promotion path is not automatic: a pipeline earns skill status through evidence that the procedure recurs and evaluation will benefit from seam tests, and a skill earns agent status through evidence that cases diverge enough to require goal ownership and designed revision.

Pipelines often live inside skills as perform steps. Sequential retrieve, interpret, validate, and persist may be a pipeline implementation. The skill adds the capability contract, procedure evaluation, and explicit dependency declarations. The architectural mistake is stopping at the DAG label on the whiteboard. The fix is naming the capability, binding cognitive units at judgment edges, and letting an agent own pursuit when required. Many teams stop at the DAG label because it ships. Thoughtware asks what happens on the second week, the eleventh invoice, and the case where Tuesday fails after variety passed.

Second-week failures and misleading metrics

Pipelines fail quietly on the second week when constraints interact. Tuesday becomes busy after the plan shipped. Spinach timing shifts. A household member adds a temporary allergy. Linear executors have no vocabulary for patch versus replan versus ask. Adding another stage to the DAG does not add review. Review is a transition owned by pursuit with working state that remembers what was already accepted.

Pipeline metrics often measure throughput and latency while hiding quality and authority failures. A fast linear plan generator can produce unacceptable weeks quickly. Thoughtware asks whether the outcome is accepted, not whether bytes arrived at the last stage. Pursuit metrics like patch rate, ask rate, escalation rate, and stop reason distribution belong to agents and loops, not to DAG executors alone. A production dashboard that reports only stage completion and latency will appear green on the same week a household discards the plan because nobody measured whether the result was practical under real constraints.

Invoice intake demos love linear success paths. Production queues live in pursuit: contested readings, policy changes mid-batch, human review slots, and stopping when confidence is too low for posting. The pipeline pieces remain as fetch and transform steps. The architecture names who owns the queue goal and which transitions apply when evidence shifts.

Sometimes a pipeline is secretly one composite cognitive units per stage: unnamed judgments stacked in sequence. That combines two anti-patterns. The response is to split judgments into cognitive units, compose in a skill, and add pursuit where case shape requires it. See not a composite cognitive units.

From pipeline sketch to architecture

Starting with a pipeline sketch in discovery is fine. Stages rename as judgments appear. Return paths appear when critique arrives. Skill and agent labels take over when ownership vocabulary becomes load-bearing. The sketch was a thinking tool, not the final boundary map.

Cognitive orchestration names how decide, perform, and pursue layers cooperate across a run. Pipelines describe shape. Orchestration describes ownership. When teams say "we need better orchestration," the translation is missing goals, missing skills, or missing cognitive unit boundaries rather than another DAG executor. Whiteboard reviews end with three lists: cognitive units to name, skills to package, and agent goals to declare. If the lists are empty, the pipeline sketch probably stopped too early. A useful check at this stage is to ask what the system does when the third stage fails and the answer requires looping back: if the pipeline has no vocabulary for that return path, orchestration is missing.

Pipelines that never surface abstention treat every stage as if it always produces a candidate worth passing downstream. Abstention at a stage is often the correct output when terrain is genuinely open.

What to do next

The goal owner comes first when pursuit exists, because pipelines alone cannot hold that role. Reusable linear work becomes skills with procedure evaluation. Review transitions and stop rules precede the "agent" label. Honest pipelines remain for stable transforms without pretending they are architecture-complete.

See not a composite cognitive units and acting is not agency.

Read next: Two different boundaries.