In The Backyard

There is a pattern in every technology cycle that changes how industries operate: early adopters look foolish, then prescient, then inevitable. The businesses that moved early didn’t just save time — they built capability. And capability compounds.

In automation, that compounding is unusually potent. An organisation that has spent two years building intelligent workflows has two years of contextual data, exception-handling rules, and system-learned preferences. A competitor that starts today doesn’t just face a cost gap — they face a knowledge gap. You can buy the same software. You cannot buy the accumulated operational intelligence already embedded in a competitor’s system.

We speak to operations leaders every week who describe automation as something they are “evaluating” or “piloting.” This is the wrong frame. Evaluation implies a choice that remains open. In most industries — logistics, professional services, financial operations, client management — that choice is closing. The signal isn’t that automation is better. The signal is that businesses operating without it are beginning to show it in their margins, response times, and ability to scale without proportional headcount growth.

The window isn’t closed yet. But it is measurably narrower than it was twelve months ago. That is the signal worth paying attention to.

The shift is visible in the questions operations leaders ask. Two years ago, the conversation was about whether automation was worth the investment — ROI, payback periods, implementation risk. Today the conversation is different: which processes should we automate first, what does good look like, how do we avoid the mistakes early adopters made?

That transition — from “should we?” to “how?” — is the most important signal in the market right now. It means the category has moved past justification and into execution. And execution moves faster than evaluation, because the competitive pressure is now real and visible, not theoretical.

What is being automated at this scale isn’t glamorous: invoice processing, CRM data hygiene, onboarding sequences, compliance documentation, support ticket routing. The unglamorous, repetitive, judgment-light work that consumes enormous operational bandwidth and produces nothing differentiated. When that work is automated well, the organisation has a fundamentally different capacity — not just more time, but more attention for the things that actually require human judgment.

The term “business operating system” is usually used metaphorically — a set of principles or a management framework. We mean it literally. A business’s competitive position will increasingly be determined by the quality, coherence, and intelligence of the operational software layer that coordinates everything beneath the surface of human work.

That layer today is fragmented: a CRM here, a project management tool there, an accounting package, an email platform, a support desk. These systems share data imperfectly, if at all. They require human operators to function as translators — moving information between systems, making decisions that the systems cannot make themselves, maintaining coherence that no single tool provides.

The Business Operating System of 2028 will maintain coherence automatically. Not by replacing specialist tools, but by sitting above them — understanding how they relate, what they contain, and what should happen in one system as a result of events in another. It will be an intelligent coordination layer with institutional memory.

We are building toward this. Not by trying to be everything — but by being the intelligent layer that makes everything work together. That is a harder problem than building another CRM. It is also a more important one.

Ambient intelligence is a term from architecture — the idea that a well-designed environment responds to human needs without explicit instruction. A building notices occupancy patterns and manages its own energy. The environment becomes an active participant in efficiency, not just a passive container for human activity.

We think about business automation the same way. The goal isn’t software you tell what to do. The goal is a system that has learned enough about how your business operates to anticipate operational needs and handle routine ones autonomously.

This is not as far away as it sounds. The components exist: large language models that understand business context, workflow automation that can act across systems, persistent memory that accumulates organisational knowledge over time. What’s missing isn’t technology — it’s the design discipline to combine these components into something coherent, trustworthy, and genuinely useful.

The answer requires as much thinking about trust architecture — how a business decides what a system can act on autonomously versus what requires human review — as it does about the intelligence itself. That is the design challenge we are working on.

The first layer is data: knowing what is happening. Dashboards, reports, CRM records, transaction logs. Most businesses have this, though often in silos. It answers the question: what happened?

The second layer is process: doing things automatically as a result of what’s happening. When a form is submitted, trigger a workflow. When a payment clears, update the record. When a support ticket is created, route it to the right team. This is what most people mean when they say “automation.” It answers: what should happen as a result?

The third layer is intelligence: learning from patterns across data and process to make better decisions over time. Not just routing a ticket — routing it better than last time, based on how similar tickets resolved. Not just triggering a follow-up — choosing the optimal follow-up based on the customer’s engagement history. This layer answers: what is the best way to handle this, given everything we know?

Most automation tools operate at Layer 2. The value proposition is efficiency: fewer manual steps, faster execution, fewer errors. This is real value. But it is table stakes in 2026. The competitive advantage now belongs to Layer 3 — and Layer 3 requires architectural decisions that most Layer 2 tools were never designed to enable. This is why we build the intelligence layer before the workflow layer. Getting to Layer 3 later is much harder than designing for it from the beginning.

Time-saving calculations measure what automation replaces. They don’t measure what automation enables. And the enabling value is almost always larger — and harder to see in an ROI spreadsheet.

When invoice processing is automated, the operations team doesn’t just save time. They shift from processing to oversight. From routine execution to exception management and process improvement. That shift changes the nature of the role — and the quality of the person you can attract to it. The ROI calculation that shows “we saved 40 hours per week” doesn’t capture the strategic value of an operations team now thinking about the business instead of processing paperwork.

The more sophisticated ROI question is: what does the organisation do with the headspace that automation creates? If the answer is “the same things, just faster,” the automation has been implemented without transformation. If the answer is “things we couldn’t do before because we were too busy,” the automation has fundamentally changed the business’s capacity.

We advise clients to measure automation success not by hours saved but by decisions improved, errors eliminated, and capabilities unlocked. Those metrics are harder to calculate and easier to verify. They also produce substantially higher business cases — because they’re measuring the right thing.

On the word “automation.” We have started to find it insufficient. It implies mechanical repetition — taking a human action and making it happen automatically. What we are building is closer to operational judgment at scale. The system doesn’t just repeat a step; it decides whether and how the step should be taken. “Automation” undersells that. We don’t have a better word yet.

On context windows vs. institutional memory. Large language models have context windows. Businesses need institutional memory. These are different things. A context window is how much the model can see at once. Institutional memory is the accumulated knowledge of how a business operates — not just what happened, but why, what worked, what failed, and what the organisation learned. We are spending significant engineering effort on the bridge between these two things.

On trust as a design problem. The biggest barrier to autonomous operation isn’t technical. It’s trust. Businesses will let a system do more when they understand what it is doing and why. Explainability isn’t a feature — it’s the prerequisite for expanding a system’s autonomy over time. We are building explainability in from the start, because adding it later is almost impossible.

We have deployed versions of our system for over forty clients. We knew the onboarding process well — or thought we did. The first three steps were largely unchanged across every engagement: a discovery call, a workflow audit, and a system scoping document. Standardised. Repeatable. Automatable.

We built the automation in two weeks. The system would automatically schedule discovery calls based on incoming enquiries, compile background research on the prospective client, generate a structured workflow audit template customised to their industry, and produce an initial scoping document draft for our team to review and refine.

What worked: The research compilation was excellent — better than what our team was manually producing, because the system cross-referenced more sources consistently. The template customisation saved two to three hours per engagement. The scheduling automation eliminated entirely a back-and-forth that had been consuming two to four days of calendar coordination time.

What didn’t: The scoping document drafts required more revision than expected — not because the information was wrong, but because scoping documents carry a tone and framing that communicates confidence and expertise. The system produced accurate content in a generic voice. Our clients are paying for judgment, not just information. The document needed to sound like us.

The lesson: automation excels at the information layer. It struggles with the judgment layer — not because the technology isn’t capable, but because judgment requires knowing what matters most in a specific context. That knowledge has to be designed in deliberately. It doesn’t emerge automatically from good data. We rebuilt the scoping module with a richer context layer. The second version is substantially better. We are still using it. That is the point of eating your own cooking: the discomfort tells you where the recipe needs work.