Edge cells: running AI where the machines are

For fifteen years the default answer to "where should this run?" has been "in a large data centre, a long way away". For many workloads that is still right. For the computers that run buildings, shops, plants and neighbourhoods, and increasingly the AI that runs alongside them, 2025 gave good reasons to ask again.

2025 showed how far a single fault travels

Three incidents in 2025 took large parts of centralised cloud down, each from a fault inside the provider rather than an attack.

On 19 and 20 October, a latent race condition in the automated DNS management for Amazon DynamoDB in AWS's Northern Virginia region left the service's regional endpoint with an empty DNS record. DynamoDB errors lasted about three hours; knock-on failures in EC2 launches and network load balancers stretched the whole event to roughly fourteen and a half hours.

On 12 June, Google Cloud's Service Control system crashed in a loop worldwide after a policy change with blank fields reached code that lacked error handling and was not behind a feature flag. External API requests failed across dozens of products for most of the afternoon, with full recovery after about seven and a half hours.

On 18 November, a database permissions change at Cloudflare doubled the size of a configuration file used by its bot-management system. The file exceeded a hard limit in the proxy, which then failed and returned errors for traffic across its network for close to six hours.

Each provider published a careful account and fixed the cause. The lesson is structural, not a criticism of any one engineering team: when a great deal of the world runs through a few control planes, one bad write in one of them is felt everywhere.

The grid gave the same lesson at a larger scale. At 12:33 CEST on 28 April 2025, the power systems of mainland Spain and Portugal suffered a total blackout, which ENTSO-E calls the most severe on the European power system in more than 20 years. Its final report, published on 20 March 2026, sets out the causes and recommendations.

A cell is a cluster with its own control

An edge cell is a home, a shop, a plant or a city district run as a cluster in its own right. It has its own machines, its own control plane and its own authority, ideally held in hardware keys on site rather than in a remote account. It can connect upward to larger clusters and to other cells, but it does not need them to keep doing its job.

The test of a cell is simple: cut the link and see what still works. A building's access control, a shop's tills, a plant's monitoring and a clinic's scheduling should carry on. When the link returns, the cell reports what happened and takes updates. Cells can nest, so a district can be a cell made of buildings that are themselves cells, each staying in charge of itself.

Energy: the demand is real and it is local

The International Energy Agency estimates that data centres used about 415 TWh of electricity in 2024, around 1.5 per cent of global consumption, and projects that this will more than double to around 945 TWh by 2030. The US accounted for 45 per cent of 2024 use, China 25 per cent and Europe 15 per cent. The IEA warns that about a fifth of planned data centre projects could be delayed unless grid risks are addressed, that new transmission lines take four to eight years in advanced economies, and that waiting times for transformers and cables have doubled in three years.

In the EU, data centres used about 68 TWh in 2024, and the Commission expects 114 TWh by 2030, about 3.2 per cent of the bloc's electricity demand. On 21 September 2026 the Commission adopted a delegated regulation establishing a rating scheme for data centres above 500 kW, with A to G labels for energy and water from August 2027, and indicators for grid flexibility and readiness to reuse waste heat.

Edge cells do not make that demand disappear. They change where some of it lands. Inference that serves a building can run on hardware sized to the building, on power the building already has, with its heat available to the building. It does not need to compete for a grid connection at a single large site. For policymakers working on grid capacity and data centre siting, distributed compute is a planning option, not just a technology choice.

Data locality: keep it where it was made

Much of the data an AI system in a building or district needs (sensor readings, camera frames, meter data, access logs) is produced on site, is most useful on site and is often the data people most want kept on site. Processing it in a cell means less of it travels, fewer copies exist, and the question of which jurisdiction holds it has an obvious answer. That also simplifies compliance work under data protection regimes in the EU, the UK and elsewhere, because the data never leaves the premises in the first place.

Latency, and models that now fit

Physical control loops cannot wait for a round trip to another region. A cell answers in the time it takes to cross a room, and it keeps answering when the wide-area network is slow or down.

What has changed is that useful models now fit on local hardware. The Stanford AI Index 2025 notes that the smallest model scoring above 60 per cent on the MMLU benchmark went from PaLM, with 540 billion parameters, in 2022 to Microsoft's Phi-3-mini, with 3.8 billion, in 2024: a 142-fold reduction in about two years. A model of that size needs a small fraction of the hardware a frontier model does. Larger training and occasional heavy inference can still go to a core cluster; the everyday work can stay in the cell.

What this means for research, policy and CTO readers

For researchers, cells are a system design problem worth real attention: how authority is delegated and revoked across nested clusters, how state reconciles after a partition, and how to measure resilience when the link is cut on purpose, not by accident.

For policymakers, resilience and energy policy can count distributed compute as part of the answer. Grid-flexibility indicators like those in the EU rating scheme could recognise compute that sits next to the load and can ride through a lost connection.

For CTOs, start by listing what must keep working when the link is cut, and run those workloads where the machines are. Hold the keys that govern them on site, in hardware. Keep a single view of what you own across core and edge, so distribution does not become sprawl.

Where Praecise fits

Praecise Furcate is hardware and an open operating system for machines, edge cells and data centres. Praecise designs its own Furcate Leaf, Node and Hub hardware and runs homes, businesses and city districts as cells, each a cluster with its own control and authority held in hardware keys, still working when its link is cut. Cells nest, and each stays in charge of itself. Praecise adds tuned system images, optimised model serving, fleet operations and support.

Underneath is Furcate, the open-source operating system and leaf firmware that Praecise develops and stewards under the Apache-2.0 licence. Everything that makes a trust claim is open, and so is everything a person needs to build a private, local AI system on boards they can buy.

Praecise Metal gives one ownership view of core clusters and edge cells alike: inventory, health, power and cost for every machine and every cell, read from the operator's own chain of keys. It reads ownership and never takes over a cell's control. Nested cells and scoped managers in that view, where a cell and the people who manage it see only that cell and only the owner sees everything, are coming.