Every AI automation project has a moment where someone suggests adding one more step. A scraper to gather more source data. A second model to validate the first model’s output. A rules engine to catch the edge cases the model misses. Each step sounds reasonable on its own.
We hit that moment on a project earlier this year, and did the opposite: we deleted steps.
The pipeline that was already “done”
The original design pulled data from multiple sources, ran it through a scraper, chained several processing steps together, and then handed the result to a model. It worked. It also broke in ways that were hard to diagnose — a source website changed its layout, a step timed out, an intermediate format didn’t match what the next step expected. Every failure looked different, and every failure needed its own fix.
We replaced the whole chain with one call to a single model, given the right input and a well-written prompt. Same output quality. A fraction of the failure surface.
Why the complex version gets built anyway
Nobody sets out to build something fragile. The multi-step version happens because each addition is locally justified: “the model might miss this, so let’s add a check” or “we should validate against a second source, just in case.” Every one of those decisions is defensible in isolation. Stacked together, they produce a system where nobody can explain the whole thing anymore, and where debugging means tracing through five components instead of one.
Modern models are also capable of more than most pipelines give them credit for. A well-scoped prompt with good context often replaces two or three of the “supporting” steps that got bolted on to compensate for an earlier, weaker model.
The question that should come before every added step
Before adding a step to an AI pipeline, ask what specific failure it prevents — not in the abstract, but a failure you’ve actually seen or can name concretely. “It might help” is not a reason to add a component. “We saw it fail this exact way twice” is.
If you can’t name the failure, the step is speculative complexity, and speculative complexity is where maintenance cost quietly accumulates. It’s also usually cheaper: fewer components means fewer things that can break, fewer integrations to pay for, and fewer places where a vendor’s API change can take down your workflow.
What we do differently now
On new automation work, we default to the smallest pipeline that could plausibly work, ship it, and only add a step once we’ve actually observed the failure it’s meant to fix — not before. It’s a less impressive architecture diagram. It’s also the one that’s still running unattended six months later.
If you’re looking at an automation that feels more complicated than the problem deserves, that’s usually a sign, not a requirement. We can take a look at it with you.