Why your smart home breaks the moment you add an AI agent

A developer's DoSync protocol solves the fragility of AI-smart home integrations by having each device publish a "Capability Manifest" that declares its own relevance to intents like emergency response. In a production deployment, a Philips WiZ bulb automatically participates in safety actions through its `emergency_capable: true` declaration, bypassing the need for pre-written rules or developer intervention. The protocol enforces a contractual commitment from emergency-capable devices to respond without confirmation and log actions in a tamper-evident chain.

You add a new smoke detector to your home network. It registers with the hub. Thirty seconds later, when someone fires an ensure safety intent, the detector is part of the response — no automation written, no rule updated, no developer intervention. How is that possible? The answer is capability abstraction. And it's the design decision that separates systems that work with AI from systems that merely tolerate it. Every existing smart home protocol treats a device as a passive endpoint. The device waits. Something external — an app, a rule engine, a developer's script — decides when to call it and what to tell it. The device's only job is to execute. This model has a hidden assumption: that someone, somewhere, anticipated every scenario the device would be relevant for. They wrote the rule. They tested it. They kept it updated as new devices joined the network. That assumption holds when humans are in the loop. It breaks the moment an AI agent enters the picture — because the AI doesn't have the rulebook. It has a goal. And the gap between "I have a goal" and "I know which devices to activate" is exactly the integration problem that makes AI-IoT systems fragile. The fix is to move the knowledge of when a device is relevant from the rulebook into the device itself. In DoSync, every device publishes a Capability Manifest when it joins the network. Here's a real one from the production deployment — a Philips WiZ bulb running on a Raspberry Pi 5: json{ "device id": "wiz-living1-01", "device name": "Living Room — Bulb 1", "manufacturer": "Philips", "model": "WiZ RGBW Tunable", "firmware": "1.0.0", "category": "actuator", "tags": "light", "climate", "smart-plug", "emergency", "wiz" , "actuators": { "id": "wiz-living1-01-turn on", "type": "turn on", "description": "Turn on" }, { "id": "wiz-living1-01-turn off", "type": "turn off", "description": "Turn off" }, { "id": "wiz-living1-01-set brightness","type": "set brightness", "description": "Set brightness 0-100%" }, { "id": "wiz-living1-01-set color", "type": "set color", "description": "Set RGB color" } , "sensors": , "emergency capable": true, "adapter": "wiz", "adapter config": { "ip": "192.168.100.28" } } This isn't an API specification. It's a declaration of identity and relevance. The device is answering three questions at once: emergency deviceThe AI agent never needs to know the device's native protocol. It fires: json{ "intent": "ensure safety", "urgency": "emergency" } The resolver reads every registered manifest, scores each device for relevance — weighting tag overlap, location context, emergency bonus, and actuator match — and builds the action plan. The bulb is included because of its emergency tag and emergency capable : true — not because anyone hardcoded it. Add ten more bulbs tomorrow with the same manifest structure, and they participate immediately in every emergency response. emergency capable is a contract, not a flag This boolean deserves more attention than it usually gets. When a device declares emergency capable: true, it's not filling in a form field. It's making a commitment to the protocol: I will respond to emergency intents without confirmation. I accept being included in the audit trail as a critical actor. I understand that my actions in emergencies will be logged with a tamper-evident SHA-256 chain. The protocol enforces this contract. Emergency-capable devices bypass the normal policy evaluation flow. They're always included as candidates in emergency intent resolution, regardless of tag overlap. And every action they take is logged — precisely because actions taken during emergencies are consequential enough to require a verifiable record. This is the correct place for a safety guarantee to live. Not in a rule written by a developer who may or may not have anticipated the edge case. In the device's own declaration, verified and enforced by the protocol at runtime. Compare the two designs: Rule-based: developer writes "if emergency, unlock frontdoor-01" → breaks when frontdoor-01 is replaced → breaks when a second entrance is added → breaks when the emergency scenario changes Capability: device declares emergency capable: true → protocol enforces the contract → survives device replacement, new entrances, new scenarios → audit trail is automatic Capability abstraction is an old pattern. OpenAPI schemas describe what an HTTP service can do. MCP tool descriptions tell an LLM which tools are available and when to use them. Service registries in microservices architectures let services announce themselves at runtime. DoSync's Capability Manifest is in this family. But there's a specific difference that matters for physical systems. OpenAPI and MCP describe interfaces — the exact shape of inputs and outputs. They're precise but context-free. An OpenAPI schema for a door lock tells you the /unlock endpoint accepts a duration seconds integer. It doesn't tell you that this lock is at the main entrance, that it's relevant in emergencies, or that it should be included in a safety response but not an energy-saving routine. The Capability Manifest adds semantic context on top of interface description. The tags field isn't a type system — it's a declaration of relevance across scenarios. "door-lock", "entrance", "emergency" tells the resolver three things that no API schema can express: what the device is, where it lives, and when it matters. This distinction exists because AI agents reason at the semantic level, not the API level. An LLM detecting an emergency thinks "there's a safety situation" — not "send a PUT request to /api/v1/lock/frontdoor-01/state with body {locked: false, duration: 300}" . The abstraction layer has to meet the AI where it operates — at the level of meaning, not syntax. Here's the shift capability abstraction enables, stated plainly: In the command model, adding a device means updating your automations. The device is inert until a human decides it should participate in something. In the capability model, adding a device is the integration. The manifest is the contract. From the moment it registers, the device participates in every scenario it declared itself relevant for. Before: new device → engineer writes automation → device participates in scenario A new scenario B → engineer writes automation → device participates in scenario B After: new device registers manifest → device participates in all relevant scenarios new scenario added to protocol → device participates automatically This is not a small operational difference. In a home with 40+ devices, maintaining the "before" model means hundreds of automation rules, each one a potential failure point when a device changes or a scenario is updated. The "after" model has one integration surface per device — the manifest — and it never needs to be updated when scenarios change. If you're building a device that will coexist with AI agents, the Capability Manifest is the interface that matters more than your API documentation. A well-designed manifest answers the questions AI systems actually ask: emergency capable : true/false category + semantic tags actuators with meaningful type names sensors with type and unit adapter + adapter config A poorly designed manifest — missing location tags, wrong emergency capable value, generic actuator types — means the device is invisible to the AI in exactly the scenarios where it should matter most. The resolver can only work with what the device declares. Tag your devices correctly. The rest is automatic. Five posts ago, we started with a simple observation: AI agents express goals, not commands. Every post since then has been an answer to the same question — what does a system have to look like, at each layer, to bridge that gap? Semantic intent replaced commands. Policies replaced rules. Events were separated from intents. And now capability abstraction replaces the developer who used to be the translator between device APIs and AI goals. The translator was always the fragile part. Every time a device changed, the translator broke. Every time a new scenario appeared, the translator had to be updated. Every time an AI agent expressed something that wasn't anticipated, the translator failed silently. Capability abstraction removes the translator. The device speaks for itself. The AI listens. The protocol enforces the contracts between them. That's not a smart home feature. That's the infrastructure for any physical environment where AI needs to act reliably. GitHub: https://github.com/giulianireg-spec/dosync-protocol Website: https://dosync.dev License: Apache 2.0