There is a version of this story that almost every business has lived through at least once, and it tends to start the same way.
Someone builds an automation; a Zapier flow, a Make scenario, a Power Automate sequence that a team member put together over a weekend because there was a deadline and it seemed to work. And it does work, for a while, sometimes for long enough that people start genuinely relying on it. Then something small changes. An API updates quietly in the background, a field moves, a new team member does things slightly differently to the person who built the original flow. And without any fanfare, the whole thing stops doing what it was supposed to do.
Nobody notices immediately. The automation is still running, still ticking away, still sending the confirmations it was built to send. It is just no longer sending the right information to the right place. By the time someone realises, the wrong data has been sitting in the wrong system for two weeks, and the fix takes a Friday afternoon that nobody had spare.
The conclusion most businesses draw from this experience is that automation is harder than it looks, that it works for other companies but not for theirs, that the technology overpromised and underdelivered. That conclusion is understandable, and it is also the thing that stops otherwise well-run businesses from building something that could genuinely change how they operate. Because the technology was not the problem. The architecture was.
What point-to-point tools were actually built for
Zapier, Make, Power Automate, Claude — these are all legitimate and useful tools, and none of them are the villain of this story. But they are point-to-point tools, designed to connect A to B in a relatively straightforward way. They were not built to handle conditional logic across fifteen steps, or to manage exceptions gracefully when an unexpected input arrives, or to maintain themselves as the environment around them shifts and changes over time.
When you push them beyond what they were designed for, which happens gradually, almost imperceptibly, as the original simple flow gets added to and extended and patched over months — you end up with something that is technically functional and practically fragile. It works until it doesn’t, and when it stops working, it is difficult to diagnose, difficult to fix, and very difficult to trust again. The tool did not fail. It was used for a job it was never designed to do, and nobody stopped to notice the mismatch because the deadline was pressing and it seemed to work.
This is almost always the result of skipping a step that most businesses do not realise they are skipping, and that step is architecture.
What architecture actually means in practice
Architecture is not a term that belongs exclusively to large enterprises with dedicated engineering teams. It is simply a considered answer to a set of questions that should be asked before any automation is built, and that most projects skip because there is pressure to start building quickly.
How does data move through this process, and where are the decisions made? Who is responsible when something unexpected happens, and something always does eventually? How does the system behave when an input arrives that it was not designed for? What changes in the surrounding environment could cause it to break, and how quickly would anyone know if it did? These are not complicated questions, but they are questions that feel abstract when there is a working prototype in front of you and a stakeholder asking when it will be ready.
Drowning in manual, repetitive work? Tell us the task and we’ll show you what to automate.
The result of skipping them is an automation that was built to work in the conditions that existed at the moment of build, and nothing else. In a stable environment, this produces something that is merely inefficient to maintain. In a regulated industry, where the rules, systems, and requirements around a business change constantly and sometimes without warning, it produces something considerably more dangerous. An automation that silently fails in a regulated environment is not just an operational inconvenience. It is a compliance risk, an audit finding, and a conversation with a regulator that nobody planned for and nobody wants.
Why the fix is usually less dramatic than it seems
When businesses finally have the architecture conversation, which most do after something has already gone wrong, the assumption is often that fixing it properly means throwing everything away and starting from scratch. That is rarely true, and it is worth understanding why, because the belief that the fix is enormous is one of the things that keeps businesses stuck with fragile automation for longer than they should be.
What addressing the architecture problem usually looks like in practice is stepping back, mapping what actually exists rather than what was intended to exist, and identifying specifically where the brittleness lives. Often it is concentrated in two or three places; a step that relies on a third-party system behaving consistently, a decision point that was hardcoded for conditions that have since changed, a section that was added quickly under pressure and never properly integrated with the rest. Rebuilding those sections on a proper foundation, with modularity so that one broken part does not bring down the whole structure, and with enough observability that failures surface before they become problems, is usually a much more contained piece of work than a full rebuild.
Sometimes the right answer also involves introducing a human checkpoint. Not because the step cannot be automated in principle, but because it carries enough risk or variability that a person in the loop is the correct design decision for now. This is worth dwelling on, because it runs counter to the way automation projects are usually framed. A human checkpoint is not a failure or a compromise. It is an honest acknowledgement that some steps, particularly in regulated environments, carry consequences that make certainty more valuable than speed. The businesses that build automation well tend to be the ones that are genuinely comfortable making this call, rather than automating a step because automating it feels like the point.
The question that changes what gets built
Most businesses arrive at the architecture conversation reactively, after a broken flow or a compliance near-miss or a client who noticed the error before anyone internal did. The fix at that point is more expensive, more disruptive, and more urgent than it would have been if the question had been asked at the start.
The question is not “how do we build this?” It is “how does this need to behave when the things around it change?” Asked before the build, that question produces something durable. Asked after the build, it produces a rebuild. The technology available for automation today is genuinely powerful, and the businesses that use it well are not the ones that move fastest or automate the most. They are the ones that took the time to understand what they were building, how it needed to hold up over time, and where the limits of the tools they were using actually sat.
Start with the architecture, and the rest of the decisions become considerably easier to make.
This is part of the Where You Don’t Need AI series, which explores what automation and AI actually do well, where they fall short, and how to build operations that are designed to last.
