Building Agentic Pipelines

A pipeline is a workflow you have made repeatable. Instead of sitting down each time and improvising your way through a recurring job - prompting an agent, copying its output somewhere, prompting again - you define the steps once, in order, with the inputs and outputs of each specified, so the whole thing runs the same way every time you feed it a fresh case. The payoff is the payoff of any good process: consistency (the same quality and format every run, not whatever you happened to type that day), speed (no reinventing the flow), scalability (run it across ten projects as easily as one), and debuggability (when it goes wrong, you can point to the step that failed rather than staring at a mystery). For a small studio, a well-built pipeline is leverage - it turns a task that used to eat an afternoon into one you kick off and supervise.

The candidates for a pipeline are the recurring, structured jobs that surround design: a precedent-research pipeline that takes a project type and returns a structured digest; a room-data-sheet pipeline that takes a schedule and returns drafted sheets checked against it; a specification pipeline that takes a set of selected products and returns a formatted spec section; a drawing-QA pipeline that runs a checklist over an issued set and returns a flagged list. What these share is that the flow is stable even though the content changes - the steps are the same each time, only the project differs. That stability is exactly what makes them worth engineering.

What should not be forced into a pipeline is the genuinely creative, one-of-a-kind, judgement-saturated work - the concept, the big design move, the decision about what is right for this place and these people. Those are not repeatable flows and should not be automated into one; the attempt would only produce generic output and a false sense that the thinking was done. The skill is to see which parts of your practice are stable, recurring process (pipeline them) and which are singular judgement (keep them yours). A pipeline is for the reliable grind around the design, freeing your attention for the design itself - not a machine for manufacturing the design.

The most important design decision in a pipeline is made step by step: should this step be deterministic - fixed code that does the same thing every time - or autonomous - an agent using judgement? Getting this right is what separates a reliable pipeline from a flaky one, and the guiding principle is simple: use determinism wherever you can, and spend autonomy only where you must.

Deterministic steps are the parts of the job that can be pinned down to rules: reading a file, reformatting data, running a calculation, sorting or filtering a list, populating a template, calling a defined function, validating that an output has the required fields. These do not need an agent - they need a script or a tool, and using one is better in every way that matters: it is faster, effectively free, perfectly consistent, and it cannot hallucinate. A step that always does the same thing should be code, not a language model asked nicely to behave. Pushing determinism as far into the pipeline as it will go is the single biggest thing you can do for reliability.

Autonomous steps are the parts that genuinely need judgement, language understanding or open-ended handling that you cannot reduce to fixed rules: reading a messy brief and extracting what matters, synthesising precedents into an argument, drafting prose, deciding which of several findings is relevant. Here an agent earns its place, because the step is fuzzy in a way code cannot capture. But autonomy is the expensive, variable, occasionally-wrong ingredient - it costs more, runs slower, and can produce a different or a flawed result on a given run - so you spend it deliberately, only on the steps that truly need it, and you wrap each autonomous step in a check. A robust pipeline typically has deterministic bookends - fixed intake and fixed formatting - around a small number of autonomous steps in the middle where the real judgement lives. When you find yourself using an agent for something a five-line script could do reliably, that is a design smell: replace it. The goal is not an impressively autonomous pipeline but a dependable one, and dependability comes from minimising, not maximising, the parts left to a model's discretion.

Designing a pipeline well is mostly about designing for the runs that go wrong, because they will. Start at the edges. Define the input contract - exactly what the pipeline expects to receive and in what shape - and validate it at intake, so a malformed input is caught at the door rather than corrupting every step downstream. Define the output just as precisely - the format, the fields, what done looks like - so every run produces the same shape of deliverable. Clear edges make the whole flow predictable and testable.

Between the edges, treat each step as a small unit with its own check. After a step produces its output, verify that output before passing it on: does it have the required fields, is it in the right format, does it pass a sanity test. This is how you stop the compounding-error problem from the last lesson - a mistake caught at the seam between two steps never becomes the next step's poisoned input. Where a check fails, decide the recovery explicitly: a bounded retry (try the step again, up to a fixed number of attempts, perhaps with a tweaked instruction) handles the transient wobble that agents sometimes show, but the bound is essential - an unbounded retry is how a pipeline burns your budget in a silent loop at 2am. When retries are exhausted, the step must escalate to a human rather than loop forever or, worse, fail silently and pass junk downstream. A pipeline that fails loudly and safely is worth far more than one that appears to succeed while producing nonsense.

Design in the operational discipline too, because a pipeline runs unattended in a way a single prompt does not. Log what each step did - inputs, outputs, decisions - so that when a run goes wrong you can trace it to the failing step instead of guessing. Cap the cost and the iterations of the whole flow so it cannot run away. Make steps idempotent where you can - safe to re-run without duplicating side effects - so recovery is clean. And test the pipeline on real, varied and deliberately awkward inputs before you rely on it, because a flow that works on the tidy example will meet the messy real case soon enough. None of this is exotic engineering; it is the ordinary care of building something you intend to depend on and answer for. The reliability of a pipeline is not a happy accident - it is designed in, one check and one bound at a time.

Make it concrete with a pipeline a real studio might build: drafting room data sheets from a finishes-and-fittings schedule. Step 1, intake (deterministic): read the schedule file, validate it has the expected columns, and reject it with a clear message if it does not. Step 2, research (autonomous): an agent looks up the relevant standards and product data for the room types and finishes named - a genuine judgement-and-language step. Step 3, check (deterministic): validate that the research covered every room and finish in the schedule; if any are missing, retry step 2 for the gaps, up to a bound. Step 4, draft (autonomous): an agent generates each room data sheet in the studio's template, using the schedule and the researched data. Step 5, format and validate (deterministic): pour the drafts into the exact studio format and check each sheet has every required field. Step 6, the human gate. The pipeline does not issue anything; it presents the drafted, self-checked sheets to a person for review, correction and approval. Only after that sign-off does the output become a deliverable.

Notice the shape: deterministic bookends and checks around two autonomous steps, bounded retries at the seams, and - immovably - a human at the end. That final gate is the point the whole course keeps returning to. However smooth and automated the middle of the pipeline becomes, the output touches a real project - specifications a contractor will price and build to - so it cannot leave the studio on the pipeline's say-so. A person verifies it and signs it, and that person carries the professional responsibility for it. The pipeline made the drafting fast and consistent; it did not, and cannot, take on the accountability.

This is the honest promise of agentic pipelines for practice. They are a powerful way to industrialise the reliable, recurring grind - to get consistent, fast, scalable production of the work that surrounds design - and for a small studio that leverage is real and worth building for. But a pipeline is a production line, not a professional. It runs the process; you own the result. Build pipelines for the recurring, structured work; keep the human gate before anything binding; log, bound and test what you build; and you gain genuine capability while remaining exactly what you were - the designer who directs the flow and answers for what comes out of it.