Here's the moment that made the whole thing click for me.
My Samsung TV, a 50-inch QLED sitting in the living room, showed up as "Offline" in the SmartThings app. According to Samsung's own software, the telly was unreachable. At the same time, Enki asked it directly, on my home network, whether it was on. It answered instantly: on.
Both things were true at once, and the gap between them is the entire argument. SmartThings wasn't reporting the TV. It was reporting what Samsung's cloud believed about the TV. The cloud was out of date, so the app was wrong. Enki skipped the cloud entirely and talked straight to the set on the local network. The TV was never offline. The vendor just didn't know.
That's why I built Enki its own Connection Centre.
The problem with renting your senses
If Enki needs the Tuya app to reach a lightbulb, or a SmartThings account to reach a television, then it isn't sovereign. It's renting its senses from whoever made the gadget. Every command detours through someone else's servers, subject to their uptime, their account, their terms, and their idea of what's happening in your room. The "offline" TV is the small, perfect example: a company's cloud stood between me and my own furniture, and got it wrong.
So I did what I always do first: ask whether it can be sovereign at all. Here it could. Don't lean on Tuya or SmartThings or Smart Life for anything, just study how those hubs are shaped, and build our own. Speak to devices directly, on your own network, and own the layer that does it.
How it's built (the shape, not the plumbing)
The Connection Centre is a pluggable driver layer, and it runs on one rule I'm quite proud of:
**The driver declares what a device can do. The gate decides what Enki is allowed to do. And a driver can only ever narrow that, never widen it.**
A driver is basically an untrusted plugin that speaks to some third-party hardware. It's allowed to claim capabilities ("this TV can change channel, adjust volume, power on/off"), but it has no vote on whether any of that is permitted. Policy lives on the far side of the layer, past a human-confirm step, and it can only ever intersect with what the driver claims. A plugin can't grant itself more authority than it's given. That asymmetry is the safety property, and it's deliberate.
Adding a whole new ecosystem (a brand, a protocol, a thousand devices) is write one driver, add one line to the registry. Nothing else in Enki changes: not the gate, not the airlock, not the interface. That's the whole reason the layer exists.
Nothing happens without a yes
Enki doesn't get to fire commands into your house off its own back. Every consequential action runs through an airlock: Enki proposes an action in chat, that turns into a request, the gate validates it and shows you a human-confirm card, and only when you say yes does a scoped, checked command reach the specific device, and nothing wider. Safety-first, human-in-the-loop, by construction. Enki asks first, every time.
And so you can feel that airlock before wiring up anything real, there's a simulated home (a zero-setup, fictional demo house) so you can watch Enki propose an action and confirm it, with no hardware and nothing to lose.
Honest ledger, because I always post it
This is early. Right now there are exactly two drivers: the safe simulated home, and local Samsung TV control. That is not a house full of lights and locks and thermostats dancing to Enki's tune. I'm not going to pretend it is. What I've built is the architecture, plus the one real driver that proves the sovereignty claim isn't hypothetical. Every other ecosystem (the bulbs, the plugs, the Zigbee gear, the open-standard hubs) is a future driver written to the same one-rule pattern. The point of today isn't breadth. It's that breadth is now a small, repeatable job instead of a rebuild.
One more bit of honesty on what this is and isn't: the Connection Centre is not a patent claim, and I'm not dressing it up as one. Enki's memory engine is patent pending; this device layer is just good, boring, sovereign architecture. Studying how a hub is shaped and building your own is allowed: it's ideas and interfaces, not anyone's code.
Two learners, one curve
This week Enki got its own way to reach the physical world without asking a vendor's permission. I learned that "sovereign" isn't a slogan you put on a slide. It's the moment your smart-home app insists the television is offline while your own software is already talking to it. Own the engine, own the connection, and the room stays yours.
To be clear, as always: this is Enki reaching devices under a human's confirmation, not Enki wanting anything. It's plumbing you control, not a will of its own.
Try the memory engine that sits behind all of it, live: try.enkilabs.co.uk. Building sovereign, local-first AI, or a device integration you'd want Enki to speak to? I'm at [email protected].
The engine is patent pending. I'll talk about what it does; I won't discuss what's under the hood.