That familiarity is not accidental. Organisations and home automation systems obviously differ enormously in scale, consequence and complexity, but they share some structural challenges. Both contain multiple sources of information, overlapping responsibilities, competing signals and decisions that depend on context rather than isolated events. Both also tend to become harder to manage as new capabilities are added without a corresponding improvement in architecture. What interested me was not the technology itself, but the way complexity accumulates once individual automations begin to interact.
From simple automation to stateful systems
Most automation starts with an event. A sensor detects motion, a button is pressed, a battery reaches a threshold or a device changes status, and the system responds. This model works well when each decision can be made independently, but it becomes less reliable once the same event can mean different things depending on what is already happening elsewhere.
The home therefore needed a way to maintain state, not merely respond to triggers. It had to distinguish between device state, derived state, user intent, historical context and temporary control conditions. A presence event, for example, should not always produce the same lighting response, because the appropriate action may depend on time of day, ambient light, current home mode, a manual override or the recent movement of occupants between rooms. In practical terms, the system had to stop treating every event as isolated and begin interpreting it within a wider operating context.
That change sounds technical, but the principle is broader. A useful system often needs to answer two questions at once: what has just happened, and what is already true. Once decisions depend on both, the quality of the underlying model becomes far more important than the sophistication of any individual automation.
The same problem appears in business systems
This is where the connection with AI becomes more interesting. Much of the current discussion around AI remains focused on isolated capabilities: generating a document, summarising a meeting, analysing a dataset, writing code, researching an account or producing campaign material. These applications can create real value, but they still operate largely at task level.
The more difficult opportunity is to connect AI to the wider context in which those tasks sit. An AI system working inside a commercial organisation should ideally understand which customer segments matter, which positioning has been agreed, what product constraints are in place, which opportunities are active, what sales has learned from the market, what marketing is testing and which systems should be treated as authoritative for each type of information. Without that context, even highly capable AI can end up accelerating disconnected activity rather than improving the system as a whole.
The home project made this problem unusually visible because the consequences of poor system design showed up quickly. When different automations interpreted the same state differently, when two variables gradually came to represent almost the same thing, or when several flows implicitly competed for control, the resulting behaviour became inconsistent. Adding more automation did not solve those problems because the weakness was architectural rather than functional.
Sources of truth matter more as complexity grows
One of the design principles I adopted was that every important state should have an authoritative source. If the question is whether audio is physically playing, the audio system itself should answer that question. If the question is whether automated movement of that audio is allowed, that belongs to a different piece of state representing user intent. If the question concerns which room currently owns the automated session, responsibility belongs to the audio service rather than to whichever sensor most recently detected presence.
These distinctions are deliberately explicit because ambiguity becomes expensive as systems grow. The same principle applies inside companies, where customer information may be distributed across CRM platforms, marketing systems, product analytics, finance tools, support systems and individual spreadsheets. Strategy may live in presentations, campaign decisions may evolve elsewhere, and important market information learned by sales may never influence product or positioning decisions because no reliable mechanism exists for carrying that information across the organisation.
Before AI can act reliably across such an environment, the organisation has to decide where different forms of truth live, which systems or teams own particular decisions, and how information should move between them. That work is less glamorous than deploying another AI tool, but it is often more important. In practice, it is an operating-model problem before it is a technology problem.
Useful systems also need memory
Another lesson emerged from automations that had to operate across time. Some decisions depend on historical context, such as which room previously owned an audio session, whether an occupant has moved through a transition zone, whether a particular state was manually overridden, or what the system believed before the most recent change. Without that limited memory, the system can misinterpret the meaning of a new event.
Organisations have the same problem at a much greater level of complexity. A customer journey is not a collection of independent interactions, and neither is a sales opportunity, product launch or market strategy. What a signal means today often depends on decisions, conversations and assumptions that originated weeks or months earlier. If AI is expected to participate meaningfully in those processes, it needs access not only to current information but also to the relevant context that gives current information meaning.
This is one reason I am more interested in AI systems that operate with persistent organisational context than in isolated productivity tools. The larger opportunity lies in making enough of the organisation's logic explicit that both people and machines can reason about it consistently. That requires clear definitions, traceable decisions, coherent data ownership and a shared understanding of how important parts of the system relate to one another.
Using AI to inspect the system, not merely operate it
AI also became part of how I maintain the home itself. The architecture is documented in a public engineering handbook, while the live implementation runs separately. In September 2026, I connected an AI assistant to the running automation platform and used it to review the live system against the documented architecture, including flows, variables and relevant scripts.
The exercise uncovered several genuine inconsistencies. Two switch-off paths had been connected to the wrong result of a presence re-check, duplicate state values had evolved over time, a ventilation path could reduce its setting while CO2 remained high, a brightness script still referenced a sensor that had been removed, and several routine flows used toggle actions where explicit states were safer. It also revealed that parts of the documentation had fallen behind the running implementation.
What made the exercise useful was not that the AI could make decisions autonomously, but that it could inspect a large amount of structured information and compare implementation with documented intent. Several apparent anomalies were deliberate choices rather than errors, which meant human judgement was still necessary to interpret the findings. That boundary matters because the system can help surface inconsistencies, while the person responsible for the architecture still has to understand intent, trade-offs and operational context.
Documentation becomes part of the architecture
The project also changed how I think about documentation. I originally treated documentation mainly as a record of what had already been built, but over time it became part of the architecture itself. The handbook now defines concepts, ownership, state models, design patterns, verification standards and operational practices, while examples are distinguished according to whether they are tested, reusable patterns or proposed ideas.
That shift matters because reliable AI systems need more than access to raw data. They also need access to the rules, definitions and relationships that make the data intelligible. In many organisations, important operational knowledge remains embedded in individual experience, scattered across presentations or encoded in habits that have never been made explicit. The more organisations expect AI to participate in real decision processes, the less sustainable that implicit model becomes.
AI readiness therefore has a significant organisational dimension. Definitions need to become clearer, decision rights need to be visible, assumptions need to be recorded and important processes need enough structure to be inspected. Documentation stops being an administrative afterthought and becomes part of the mechanism through which the system remains understandable.
The home is simply a contained example
A home automation environment is obviously not a company, and the comparison should not be pushed too far. Businesses contain more people, more ambiguity, more conflicting incentives and far higher consequences when decisions are wrong. What makes the home useful as an experiment is precisely that it provides a contained environment in which the effects of growing system complexity can be observed directly.
As more automations accumulated, familiar failure modes appeared. Local improvements created hidden dependencies, naming conventions became architectural decisions, exceptions multiplied, ownership became less obvious, documentation drifted and individually sensible automations began to interfere with one another. At a certain point, the problem could no longer be solved by adding another clever rule because the underlying model had become the limiting factor.
Commercial organisations encounter the same pattern in more consequential forms. Marketing automation does not resolve unclear positioning, a better CRM does not settle disagreement about the customer, AI-generated content does not create a coherent market strategy, and additional sales tooling does not automatically improve the connection between product, marketing and sales. Technology can improve the performance of a coherent system, but it can also make fragmentation move faster when the architecture underneath remains unclear.
Why this matters for how I think about AI
The home project has made me increasingly interested in what happens when AI is treated as part of a system rather than as a collection of standalone tools. The meaningful questions are no longer limited to which tasks AI can complete, but extend to how context is represented, how state is maintained, how ownership is defined, how decisions are coordinated and where human judgement remains essential.
Those questions are directly relevant to the way organisations will have to evolve as AI becomes more deeply embedded in their operations. The challenge is not simply to automate more work, but to make enough of the operating model explicit that automation can be applied without creating additional confusion. In that sense, the value of AI depends partly on the clarity of the system it enters.
The domain in this case happens to be home automation, but the underlying lesson is much broader. Systems become more useful when they understand context, preserve relevant state, respect clear ownership and remain inspectable as they evolve. Building those properties deliberately has become one of the most useful ways for me to think about how AI can contribute to better business systems rather than simply produce faster output.
