DEV Community: Rodrigo Giuliani

You learned your hands by using them. An agent gets a paragraph.

Rodrigo Giuliani — Thu, 03 Sep 2026 11:49:39 +0000

A mind discovers its body by moving it, failing, and trying again. An AI agent
controlling physical devices can do neither half of that — which is why the
device has to introduce itself, and why nobody quite agrees on what that
introduction should contain.

You did not learn what your hand does by reading a specification. You spent
about a year dropping things.

Somewhere in that year you worked out that the hand grips, that grip has degrees,
and that a glass held too loosely falls while one held too tightly breaks. Nobody
told you. It arrived through use, through failure, and through a sense that
reports for free, all the time, on where your limbs are and what they touch.

An AI agent connected to a building full of devices has none of that.

It cannot feel that a camera is there. There is no perceptual channel by which a
language model discovers a temperature sensor in the next room the way you
discover your own foot. And more importantly, it cannot afford the other half
either. A mind learns a lock by trying the lock. An agent that tries a lock
has unlocked a door — that is not an experiment, that is an event, and it may be
the wrong one at three in the morning.

So the discovery route is closed at both ends. Which leaves exactly one option:
the device has to say what it is.

That is what a manifest is. Not a convenience, not a config format. It is a
substitute for a developmental process that cannot happen. And once you frame
it that way, the interesting question stops being what format and becomes
what does the introduction have to contain for a mind that will never get to
find out by hand.

What most systems declare

Almost every attempt at this — and there are several serious ones now — answers
the same layer: what the thing can do.

A lock exposes lock and unlock. A light exposes turn_on and a brightness
parameter with a range. A thermostat exposes a target temperature in degrees. It
is the layer that maps most cleanly onto function signatures, which is probably
why it is the one everyone builds first.

It is also genuinely necessary, and it is more than a name. A hand that "grips"
is useless information; a hand that grips with a force between zero and forty
newtons is something a mind can plan with. Types, ranges, units. That layer is
mostly solved, and where it isn't, it's an implementation gap rather than a
conceptual one.

But it is not enough, and you can see why with a thought experiment that has
nothing to do with software.

The layer nobody writes down

Suppose I hand you a tool you have never seen. I tell you it has a lever, that
the lever has two positions, and that moving it takes about two newtons.

You now know exactly what it can do. You still have no idea whether to touch it.

What you are missing is not capability. It is consequence: is this reversible?
If I move the lever and I was wrong, can I move it back? Or have I just done
something that stays done?

Your hands know this about the world and the knowledge is not in the joints. You
handle a glass differently from a rock, and the difference is not grip strength —
it is that one of them is unrecoverable. You learned that by breaking a glass.

A device declaring lock and a device declaring turn_on look identical at the
capability layer. One of them, done wrong at the wrong hour, leaves someone
outside their own house. The other is a light you turn off again. Nothing in
the interface distinguishes them, and an agent reasoning only from capabilities
has no way to be more careful with the first than the second.

And the layer that isn't about the device at all

There is a third thing, and it is the one I find hardest to place.

Knowing what a hand does, and knowing that a broken glass stays broken, still
does not tell you when reaching for something is the right move. That
judgement is not a property of the hand. It comes from the situation.

The same is true of devices, and it produces a problem that manifests handle
badly. A manufacturer can truthfully declare that their product opens and closes.
They cannot declare that it is the door of an operating theatre, or that it
matters during an evacuation, or that this particular one should never be touched
automatically because of what is behind it. That is not information about the
product. It is information about the deployment, and it is known only by whoever
installed it.

When those two get written into the same field — and they usually do, because
it's convenient — something predictable happens. Ask an installer "could this
device matter in an emergency?" and the honest answer for a light is yes. For a
temperature sensor, also yes. For nearly everything, yes. The question invites a
universal affirmative, and a field where almost everything is marked relevant
tells the agent nothing at all.

The question the system actually needs is a different one: not could this
participate, but should it. Those look similar and they behave nothing alike.

Where the analogy breaks, and why that's the point

Bodies do not have this problem, and it is worth being precise about why.

Your hand never declared anything to you. You have no manifest. What you have is
a decade of continuous feedback and permission to be wrong about small things
until you stopped being wrong about them. The analogy holds right up until that
observation and then falls apart completely — a mind and its body co-develop,
and an agent and a device do not.

I don't think that weakens the comparison. I think it locates the actual
engineering problem. Everything a manifest has to carry is there precisely
because the loop that would otherwise teach it is unavailable, for reasons that
are not going away. The perception gap is technical and might narrow. The
prohibition on experimenting with locks and industrial machinery is not
technical, and it should not narrow.

The open question

I don't have a clean answer, and I am suspicious of anyone who presents one,
because these three things are declared by three different parties who never meet:

The manufacturer knows what it does and what it costs to be wrong
The installer knows where it is and what it must never touch
The situation decides which of them matters right now

Most designs I've looked at, including my own, collapse at least two of those
into one field and then wonder why the result is either too permissive or too
brittle.

So the question I'd put to anyone building in this space: what is the minimum a
device must declare so that an agent can act on it correctly without ever having
been allowed to experiment on it? Not the maximum — the maximum is easy and
nobody fills it in. The minimum.

I've been trying to make this concrete in
DoSync (an open protocol I maintain). The practical
version of the question there is more specific and more annoying: I have a field
doing all three jobs at once, and measuring it made clear that it does none of
them well. Which is roughly where the conceptual problem stops being conceptual.

If you've built something in this space and landed somewhere different, I'd
genuinely like to know where.

GitHub: github.com/giulianireg-spec/dosync-protocol

Web: https://dosync.dev/

License: Apache 2.0

DoSync — the semantic layer between AI agents and physical systems.

Four reviewers told me the one thing I couldn't fix by myself

Rodrigo Giuliani — Sun, 30 Aug 2026 01:51:03 +0000

What happens when you submit a solo open-source project to academic peer review:
the reviews were good, the paper was rejected, and the gap they found was the one
I had no way to close on my own.

I've been building DoSync,
an open-source protocol that sits between AI agents and physical devices — I
wrote about
why it exists here
if you want the background.

I tested it the only way I could: on my own hardware, against my own
expectations. Then I sent it to IEEE WF-IoT 2026, because I wanted it examined by
people who weren't me.

Five reviews came back. Four were substantive. It was rejected.

And here's the part that took me longest to understand: the reviews were
good. Two scored relevance 5 out of 5. One recommended minor revisions. The
words included "well-written", "highly pragmatic", "a clear and defensible
architectural stance", and — the one I keep re-reading — "unusually candid about
limitations."

Rejected anyway. Not because the idea was wrong. Because of this, from the most
detailed review:

The evaluation is small and self-judged: 15 scenarios with ground truth
defined by the author alone.

That sentence is correct, and no amount of rewriting section 4 was going to
change it.

I got exactly what I asked for

It took me a few days to notice that the rejection was the thing I'd submitted
for.

I didn't send the paper hoping for a stamp. I sent it because after months of
being the only person who had ever evaluated this, I had no way to tell the
difference between "this works" and "this works the way I expect it to." Four
strangers read it carefully and told me. That is not a consolation prize — it is
the entire reason to submit.

What they said, in summary: the architecture holds up, and the evidence doesn't
reach as far as the claims. One reviewer went further and put the knife somewhere
specific. My central claim is that the project removes the manual burden of
writing device-by-device automation rules. Their objection:

if resolution quality depends on well-curated tags, the manual configuration
burden has not been eliminated, it has moved from rules to manifest curation

I've had months to find a counter-argument. I don't have one yet.

The one thing I couldn't fix by myself

The request that came up in almost every review was for independent annotators.
Not more scenarios — different people. Someone other than me who had read a
scenario, looked at the devices available, and formed their own opinion about
which ones should respond.

I couldn't produce one. Every judgement about what the resolver should pick —
in all fifteen scenarios, in the paper and in the benchmark files — was mine.
When I disagreed with the resolver, I was the one who had decided what the right
answer was in the first place.

Everything else on the reviewers' list, I could work on alone, and did. The
evaluation used to run on a single home registry, which is a poor way to support
a claim of being domain-agnostic; there's now a
multi-domain corpus
covering industrial and clinical registries, published so the numbers are
reproducible by someone who isn't me. The precision/recall conventions that made
two rows of a results table mathematically impossible are defined and the bug is
traced. There's a sensitivity analysis on the scoring weights.

None of that required anyone else. The annotators do. That asymmetry turned out
to be the most useful thing in the whole review packet.

Distribution is harder than building, and worth more

Since the reviews, I've been doing the closest thing to third-party testing that
one person can do: installing my own project on machines that had never run it,
following my own published instructions, on hardware that owed me nothing.

It found more than a dozen defects in a week, on a codebase with about a thousand
passing tests. My favourite: device discovery had been silently dead in
production for days, because a dependency I'd added shipped an event loop that
declares a method and raises when you call it. My check was hasattr. It
returned True. Every test passed and nothing was ever discovered.

Not one of those was findable from the inside. My test suite ran on one operating
system, one event loop, one machine that already had everything configured — it
was measuring a world only I lived in. Which is, word for word, what the reviewer
said about my evaluation.

That's the part I'd pass on to anyone building something alone: the hardest
work isn't the next feature. It's getting the thing into the hands of someone who
doesn't already know how it's supposed to behave — including your own hands, on
a machine that has never seen it.

The protocol is open, the corpus is public, and the one thing it still needs is
an opinion that isn't mine.

GitHub: github.com/giulianireg-spec/dosync-protocol

Web: https://dosync.dev/

License: Apache 2.0

DoSync — the semantic layer between AI agents and physical systems.

(The reviews are summarised faithfully and the reviewers stay anonymous, as they
should.)

MCP Already Connects Your AI to Everything. So What Would DoSync Add?

Rodrigo Giuliani — Sat, 18 Jul 2026 20:17:52 +0000

If you've connected an AI assistant to anything this year, your calendar, your files, a database, GitHub, there's a good chance MCP was doing the connecting. The Model Context Protocol has quietly become the standard way an AI reaches beyond its chat window: one
protocol, thousands of tools, plug and play. It's genuinely good, and it's everywhere.

So when a project like DoSync shows up describing itself as a protocol between AI and physical devices, the fair question is: why would I need that? My AI already calls tools through MCP. Isn't controlling a lamp just another tool call?

That's the right question, people keep searching for the difference between MCP and DoSync as if they were rivals, and I want to answer it honestly, including the part where the answer is "you probably don't need DoSync." Full disclosure before anything
else: I build DoSync. Read everything below with that in mind.

What MCP is, precisely

MCP is an open protocol, introduced by Anthropic, that standardizes how an AI application connects to tools and data. Before it, every integration was bespoke: one connector for your calendar, another for your database, each written against each AI product. MCP replaces that with a single contract, an AI client on one side, any number of "MCP servers" on the other, each server exposing tools the model can discover and call.

The metaphor everyone uses is USB-C, and it's earned: one port, anything plugs in. To say it precisely rather than metaphorically: MCP defines how a model discovers what tools exist and invokes them, it moves the request and the result, faithfully, in both
directions. What the tool actually does when called is entirely the tool's business.
Transport isn't judgment, and that's not a flaw, it's the design. Keep that phrase, the whole rest of this post hangs on it.

When to use it: whenever an AI needs to reach something outside itself. Which today is almost always. If your AI reads your email, queries a database, or files a ticket, MCP is the right layer, and it is complete for that job. Nothing below changes that.

What DoSync is, precisely

DoSync is an open protocol (Apache 2.0) that sits between an AI and physical devices, lights, locks, sensors, alarms. It does one job: it turns a goal expressed in plain terms into a coordinated, supervised, recorded set of physical actions.

The word doing the work there is goal. You don't send DoSync "turn on lamp 3, then lamp 4, then unlock the door." You send it an intent, ensure_safety and a resolver (the part that works out which devices matter) matches it against capabilities the devices
themselves declared when they joined. Then three things happen that no generic tool layer does for you:

The operator's own rules apply. Policies are a space's standing rules, declared in a file its operator controls — "never unlock these doors overnight," "this zone stays out of alarm patterns," "sirens need explicit confirmation." The AI doesn't need to remember these, and can't talk its way around them.
Every action is recorded in a tamper-evident audit log — what acted, when, and why, in a hash chain where altering history is detectable. Not a debug log: a record you could show someone afterward.
Completion is confirmed, not assumed. A command being accepted is not the same as it being done — DoSync waits for the device to confirm reality before calling a step finished.

When to use it: when the "tool" your AI is calling is the physical world, and getting it wrong has consequences beyond a failed API call.

They're not rivals. One literally speaks the other.

Here's the part that dissolves the versus framing: DoSync ships as an MCP server. The way an AI reaches DoSync is MCP.

Picture any building full of devices, an office, a clinic, a warehouse, a store. It's 2 a.m. and something goes wrong. The person responsible types one sentence to an AI: "there's an emergency in the building." Corridor lights go to full, exit doors unlock, the alarm fires, the on-call people get a message, as one coordinated response, not twenty lucky ones. Walk backward through what happened: the model understood the sentence (that's the AI), found and called a tool named dosync_fire_intent (that's MCP doing exactly its job — delivering the call), and that one call became a coordinated, recorded response across every relevant device (that's DoSync). Three layers, one loop, zero conflict. (This isn't hypothetical machinery, to be clear, the reference implementation runs this exact loop 24/7 on real hardware; the scenario is generic because the protocol is: nothing in it assumes what kind of building it's serving.)

Now give the building one rule of its own, because every real one has them. Say it's a care facility, and one wing houses patients who must never be startled by flashing lights — so the operator declared a policy: that wing's lights stay out of alarm patterns. No exceptions. Not even in an emergency. When the emergency fires, the resolver proposes — correctly — every device capable of helping, including those lights: they genuinely can flash, and they truthfully say so. The policy removes them before anything fires, and the record shows both facts: what was proposed, and what the
building's own rules decided. Notice that nobody made a mistake, not the model, not the transport, not the resolver. Everyone did their job right, and the operator's judgment about their own building still had the last word. That's the layer.

At a glance:

	MCP	DoSync
What is it?	A standard for connecting AI to tools and data	A semantic layer between AI and physical devices
What does it solve?	Discovery and invocation — one protocol instead of bespoke integrations	Coordination and judgment — goals become supervised physical action
The unit of work	A tool call	An intent
Who decides what's safe?	The tool being called	The operator's declared policies
Where does it run?	Wherever client and servers live — local or cloud	Locally, in the building it serves — no cloud required
Use it when...	Your AI needs to reach anything external	The thing being reached is the physical world, and mistakes have consequences
Made by	Anthropic (open protocol)	One independent dev (open, Apache 2.0)

What DoSync adds to MCP

If you're building agents that touch the physical world, DoSync makes MCP safer to use seriously:

One tool instead of fifty. Without a coordination layer, an agent controlling a building full of devices needs a tool per device per action, and the model has to orchestrate twenty calls correctly, in order, under pressure. With DoSync, the agent calls one tool with one goal — the orchestration happens below, deterministically, where a language model's bad day can't scramble it.
A place for the owner's rules to live. MCP deliberately has no opinion about what a tool should refuse — that's the tool's job. DoSync is where those refusals are declared once, by the human who owns the space, and enforced regardless of what the AI asks for.
A record. When an agent acts on the world, "what exactly happened and why" stops being a debugging question and becomes an accountability one.

What MCP adds to DoSync

This direction matters just as much, and it's the reason DoSync didn't invent its own AI interface:

Every MCP-speaking AI is already a DoSync client. Claude today; any model or agent framework that speaks MCP, tomorrow, no per-model integration, no SDK to maintain. MCP gave DoSync its entire front door for free.
The intelligence stays where it belongs. DoSync deliberately contains no language model. Understanding "make sure everything's safe for the night" is the AI's craft; MCP is what lets that understanding arrive as a clean, structured intent. DoSync gets smarter every time the models do, without changing a line.

That's the honest shape of it: MCP without something like DoSync can reach the physical world but brings no judgment to it. DoSync without MCP would be a nervous system with no brain attached. Each one makes the other worth more.

And here's the part most projects won't say

For the vast majority of what people use MCP for today — email, calendars, code, files, databases — you do not need DoSync. MCP alone is complete for that, full stop. Even for casual device control — "turn on the porch light" — an MCP server for your smart-home platform covers it, and adding a coordination layer would be infrastructure earning you nothing.

DoSync earns its place only when three things matter at the same time: one goal has to fan out across many devices reliably, the operator's own rules must hold even when the AI is wrong, and you need a trustworthy record of what acted and why. A cold-chain failure in a store at 3 a.m. — the manager woken, the sector locked, maintenance dispatched, before the stock is lost, with proof afterward of exactly what fired and why. That's the narrow set of cases, and it looks the same whether the building is a store, a clinic, or a home. Outside it, stay with MCP alone and enjoy it — that's not modesty, it's me not selling you a layer you won't use.

How they actually fit together

The picture isn't MCP versus DoSync. It's a loop: the AI thinks, MCP connects, DoSync acts with judgment — and telemetry closes the circle back to the AI. If you're building
agents that stop at screens, you already have everything you need. If yours are starting to reach into the world, that last layer is the part I've been building — and if you're not sure which side of the line you're on, open an issue describing your case and I'll
tell you straight.

GitHub: https://github.com/giulianireg-spec/dosync-protocol
Web (with a 2-minute live demo): https://dosync.dev/
License: Apache 2.0

I Gave an AI One Sentence. A Drone Flew the Mission — and When the AI Guessed Wrong, the System Caught It.

Rodrigo Giuliani — Wed, 24 Jun 2026 05:13:48 +0000

A build log: connecting DoSync, an open semantic-intent protocol, to a real autonomous-vehicle stack — then letting an AI model command it in plain language, and watching what happened when the model made a mistake.

I've spent the last while building DoSync, an open protocol (Apache 2.0) that lets AI agents act on physical devices through semantic intent instead of commands. The AI says "there's an emergency"; the devices figure out their own roles, from the capabilities they declared when they joined.

The protocol was designed to be domain-agnostic from the start — nothing in it assumes a house, a vehicle, or a factory. But a design claim is cheap. The only honest way to find out whether "domain-agnostic" is true is to take the protocol to the hardest possible device and see if it holds. So I connected it to a drone — and then I did the thing the protocol was always for but that I'd never actually shown: I let an AI model fire the intents, from a single sentence in plain language.

This post is the build log of both halves — the hard plumbing, and the moment it all closed into a loop. Including the moment the AI got it wrong, which turned out to be the most important part. Because the lesson underneath all of it is a simple one: the AI can be wrong; the protocol does not have to be.

Why a drone is the hard case

A light bulb is the easy case. You say "turn on," it turns on, done. The action is instantaneous and it never fails in a way that matters.

A drone is the opposite on every axis:

Its actions take time. "Go to this point" isn't done when the command is accepted — it's done minutes later, when the aircraft arrives.
It passes through states. Arming, taking off, navigating, holding position in wind.
Silence is not success. If the drone stops reporting, that doesn't mean it arrived. It might mean the radio link dropped while it kept flying.
A human can take over at any instant by grabbing the RC sticks — and when they do, the system must know and back off, not fight them.
Getting it wrong has physical consequences. If an orchestration protocol can handle that, the rest is downhill.

What I had to build

Until the drone, every action DoSync knew was instantaneous — fire it, get a result, done. A vehicle breaks that assumption completely. To speak to one, I built a few new layers — and the interesting part is how few of them are actually about drones.

A general model for long-running operations

First, a state machine for any action that takes time:

pending → in_progress → completed | failed
        + rejected, cancelled, interrupted
        + sub-states: preparing, paused_by_device, reconciling

Crucially, this knows nothing about drones. It's the same model an oven, a 3D printer, or a robotic arm would use. interrupted means a human took control — of a drone or of anything else.

A command channel and a telemetry channel — over one link

A MAVLink adapter translates DoSync's aerial intents (take_off, go_to, return_home, land, loiter) into the drone's native protocol. The key design rule: when the drone accepts a command, that's dispatch acceptance, not completion. "I received the order" ≠ "I arrived." The protocol keeps that distinction honest.

The other half is a telemetry listener that reads the drone's continuous stream and only marks an operation complete on a positive signal — the aircraft actually reaching its target altitude, actually arriving at a waypoint, actually disarming after it lands. Never on the absence of an error.

Getting these two channels to share one connection turned out to be the whole game, and it's worth being honest about why. My first instinct was two connections — one to send commands, one to listen. It fails immediately: a real drone over a serial radio is a single bidirectional link. A serial port can't be opened twice. Trying to fake two channels over UDP produced a cascade of subtle failures — a port bind conflict, then lost acknowledgements, then commands addressed to "system 0" because the command channel never heard the heartbeat that identifies the vehicle. Each one looked like a different bug. They were all the same bug: a blind command channel. The fix was to stop pretending. One connection, owned by the listener (the single reader); the command writes on it and waits for its acknowledgement through the listener. That's exactly how a real ground station handles a single radio link — it's the architecture a physical aircraft demands, not a shortcut that only holds up in simulation.

Safety policies that filter intent

Two policies, both absolute (they don't bypass even in an emergency):

A geofence that blocks any destination outside a permitted perimeter. An emergency is never a reason to fly somewhere dangerous.
A manual-control lockout that blocks commands to a vehicle a human is flying. An emergency is very likely why they took control — it must never wrestle it back. These filter the intent before dispatch. They are not the flight safety system — that lives in the drone's firmware and acts on its own, even if DoSync vanishes. DoSync coordinates; it is never the failsafe. That boundary is the whole philosophy.

Testing it without risking a real aircraft

I validated everything against ArduPilot SITL — the same software-in-the-loop simulator the drone industry develops against. A complete virtual drone, speaking real MAVLink, that you can command and that reports real telemetry.

(A note on honesty: this is validated in SITL, not yet on physical hardware. SITL is serious validation — it's what the industry builds against — but a real aircraft flying is the next step, not a claim I'm making today.)

And here's where the build log stops being about plumbing and starts being about the point.

The part that matters: an AI commands the drone

For most of this build, I was the one firing the intents — a POST to the hub, by hand. The loop worked, but there was a quiet gap between what DoSync is and what I'd actually shown. DoSync's whole premise is that an AI expresses a goal and the physical system figures out the rest. Yet if the "AI" is a curl command I type, a reader can't tell it apart from a scheduled task. The essence — a model deciding to act — wasn't on screen.

So I closed the gap. DoSync ships a native MCP server, which means any LLM that speaks MCP can use the hub as a tool. I pointed a model at it — a small, fast one, Claude Haiku — and, in plain Spanish, told it:

"Use the drone to inspect the perimeter of the area centered at latitude -35.3632, longitude 149.1652, with a 50-meter radius at 30 meters altitude."

I never named an intent. I never gave a waypoint. I described a goal.

The model did the translation itself: it recognized that "inspect the perimeter" maps to the inspect_area intent, built the structured context (the center, the radius, the altitude, the target vehicle), and fired it at the hub. It even inferred the city from the coordinates and chose a priority on its own. That translation — from a human goal to a semantic intent — is the entire reason DoSync exists. And notably, it didn't take a frontier model to do it: a small, fast model handled the mapping cleanly, because the hard part isn't raw reasoning — it's having a protocol with a vocabulary the model can target.

One detail worth highlighting for anyone building on MCP: the model didn't have inspect_area hardcoded anywhere. The MCP server reads the available intents from the hub at runtime — the hub is the single source of truth. I had declared inspect_area on the hub earlier in the day; the model simply saw it appear as an available capability. Declare a new intent on the hub, and the AI layer can use it with no code change. That's the protocol's "everything is declared" principle reaching all the way up to the model.

Watching the loop close

The moment the intent fired, the hub composed the route — take off, fly the four corners of the perimeter, return home — and drove it step by step. Each step waited for confirmed arrival before the next began.

Here is the hub's own log. Notice that every go_to accepted (the command was received) is followed, seconds later, by a reached go_to target — FINISHED (the aircraft actually got there). Command acceptance and completion are kept distinct, exactly as designed:

And here is the drone itself, in SITL — arming, taking off, climbing, flying the pattern, switching to RTL, and landing under its own firmware:

DO_SET_MODE → ARM → NAV_TAKEOFF → height 25 → RTL → Hit ground → DISARMED. (That Hit ground at 0.5 m/s is SITL's blunt way of logging a normal touchdown — a controlled landing, not a crash.) A complete autonomous mission, from a sentence spoken to an AI.

The last link took the most care. A take_off confirms by reaching its commanded altitude. A go_to confirms by reaching a position. But return_home? RTL ends when the aircraft lands and shuts its motors down — so it confirms by the disarm. Three different real-world signals for "done," each one a positive fact pulled from telemetry, none of them an assumption. Silence completes nothing.

When the AI gets it wrong — and why that's the good part

The first time I asked, I gave no coordinates. The model, trying to be helpful, filled the gap with my location — Córdoba, Argentina — and fired the intent. The drone in SITL starts in Canberra. So the AI had just ordered an aircraft to fly to a waypoint 11,000 km away.

Here's what I care about: the system did not pretend that worked. The command was accepted, the supervisor waited for a confirmed arrival, none came, and after its timeout it aborted the mission with a clear diagnosis — go_to stalled (no positive signal).

That's the whole safety posture in one event — the lesson from the intro, now with a drone behind it. The AI can be wrong. The protocol does not have to be. An LLM filling a missing parameter with a plausible guess is exactly the kind of failure these systems will have in the real world — and the right answer is not to trust the model harder. It's to build a substrate that confirms physical reality and refuses to fake success. DoSync coordinates; the drone's firmware flies; the telemetry tells the truth; and when the truth is "it never arrived," the mission stops.

What it actually revealed

Here's the thing I didn't fully expect. Of everything I built, almost none of it is drone code.

The state machine is generic. The telemetry reconciler is generic. The supervisor that waits for confirmed arrival is device-agnostic — an oven finishing a bake would use it identically. The manual-control policy applies to anything a human can grab. Only the MAVLink adapter and its message parser are drone-specific — and those are exactly the pieces a new device would swap out.

So the same infrastructure already reaches:

A robotic arm — reach, grip, move, release; an operator can take physical control.
A 3D printer — hours-long jobs with phases that can fail midway.
An EV charger — "charge to 80%," interruptible, reporting state.
A ground rover — the same go_to, the same geofence, without the flying. The drone didn't expand DoSync's scope. It proved the scope the protocol was designed to have all along. It was the hardest test, not the origin.

The takeaway

DoSync is an orchestration layer for cyber-physical systems — an AI expresses what should happen, the device executes with its own safety reflexes, a human can always take over, and the telemetry never lies about what actually occurred. The lights and sensors it can also drive are just the easy end of that same spectrum; the drone is the hard end.

The drone was simply the hardest way to prove it. And the proof isn't that a drone flew a square. It's that a sentence to a model became a confirmed autonomous mission — and that when the model guessed wrong, the system caught it.

The protocol is open. The hard case works. The next case is whatever device you have that does something that takes time.

GitHub: github.com/giulianireg-spec/dosync-protocol
Web: https://dosync.dev/
License: Apache 2.0

DoSync — the semantic layer between AI agents and physical systems.

Home Assistant Already Talks to Your Devices. So What Would DoSync Add?

Rodrigo Giuliani — Tue, 16 Jun 2026 03:00:49 +0000

If you run Home Assistant, you've already solved the hardest problem in the smart home: talking to three thousand kinds of device. Lights, locks, sensors, vacuums, obscure Zigbee gadgets from a brand that no longer exists — HA speaks to all of them. And since 2025 it ships an MCP server, so an AI assistant can already reach in and control them.
So when a project like DoSync shows up describing itself as a protocol between AI and physical devices, the fair question from anyone in the HA community is: why would I need that? I already have HA, and now AI can talk to HA directly.
That's the right question, and I want to answer it honestly — including the part where the answer is "you probably don't."

What Home Assistant is, precisely

HA does three jobs: it integrates with devices, it runs automations, and it gives you a UI. The first job is the one that matters here, and it's genuinely excellent. HA is the richest device-integration layer that exists. Nothing should try to replace that, and DoSync doesn't — it reads devices from HA through a bridge that's already in the repo.
But notice what HA's model is, underneath: it's still commands. "Turn on light.living_room." "Set climate.bedroom to 21." The HA MCP server exposes those same commands to an AI. The intelligence about what to do — what should happen when there's an emergency, when nobody's home, when a sensor reads something strange — lives either in an automation you wrote in advance, or in the AI sending the commands. HA executes; it doesn't decide.
That's not a criticism. It's just the layer HA operates at: it aggregates devices and gives you a uniform way to command them.

Where a different layer might sit

DoSync operates one layer up, and only does one thing: it turns a semantic intent into a coordinated, auditable set of actions.
You don't tell it "turn on these ten lights, unlock that door, send this SMS." You express a goal — ensure_safety, away_mode — and a resolver decides which devices are relevant based on what they've declared they can do, executes the actions, and writes every one of them to a tamper-evident SHA-256 audit log. The devices can come from HA, or from a direct adapter (WiZ over UDP, GPIO on a Pi, BLE, MQTT). HA is one source of "bodies," not the center.
Three things distinguish that from sending commands through the HA MCP:

Intents, not commands. The AI says what it wants to achieve; the resolver works out the rest from declared device capabilities. Add a device and it participates automatically — no automation to rewrite.
An audit log built for accountability. Every action and the reason it fired, in a SHA-256 hash chain: each entry includes the hash of the previous one, so editing or deleting a past entry breaks the chain and is detectable on verification. To be precise about what that buys you — it protects against undetected after-the-fact modification of the history, not against an attacker with root on the hub (who could rewrite the whole chain). HA's recorder and logbook give you a searchable history, which is great for "what happened"; the hash chain adds "and you can show it wasn't altered" — which matters when an auditor, an insurer, or an incident review needs a record they can trust, and matters not at all for everyday automation.
Multiple sources under one contract. DoSync coordinates devices from HA and from other adapters under a single semantic model with policies and certification. HA is one especially rich source among several.

And here's the part most projects won't say

For the vast majority of what people use Home Assistant for — "turn on the porch light when I get home," "set the thermostat back at night" — you do not need DoSync. HA's own automations and its MCP server cover that completely. Adding a coordination layer would be extra infrastructure earning you nothing.
DoSync earns its place only when two things are true at once: coordination matters (one goal has to fan out across many devices, reliably, possibly in an emergency) and traceability matters (you need an auditable record of what acted and why).
A concrete home example: an elderly parent lives alone, and you've built a fall-response setup — a sensor trips and the home should unlock the door for paramedics, turn every light to full, and message the family, all at once, and you need to be able to say afterward exactly what fired and when. That's coordination plus traceability in a house, not a factory. Outside cases like that — most of what HA does day to day — the extra layer earns you nothing.
If that's not your situation, stay with HA and enjoy it. That's not me being modest; it's me not wanting to sell you a layer you won't use.

How they actually fit together

The honest picture isn't DoSync versus Home Assistant. It's DoSync using Home Assistant — treating HA as one of the best places to source devices, and adding a semantic, auditable coordination layer above it for the narrow set of cases that need one. HA keeps owning its integrations. The connecting AI stays where the intelligence belongs — outside, expressing intent. DoSync is just the nervous system in between.
If you're in that narrow set of cases, it's worth a look. If you're not, you already have what you need — and if you're genuinely not sure which side of the line you're on, open an issue describing your setup and I'll tell you straight whether it's worth the trouble.

GitHub: https://github.com/giulianireg-spec/dosync-protocol
Web: https://dosync.dev/
License: Apache 2.0

When Automatic Failover Is More Dangerous Than No Failover

Rodrigo Giuliani — Sun, 14 Jun 2026 15:25:07 +0000

Here's a counterintuitive thing I ran into building redundancy for DoSync, an open protocol that lets AI agents act on physical devices: the obvious failover design can hurt you more than having no failover at all.
Let me show you why.

The setup

DoSync runs a hub — the process that turns a semantic intent ("there's an emergency") into coordinated device actions, and writes every action to an audit log. That log is a SHA-256 hash chain: each entry includes the hash of the previous one, so any edit to history breaks the chain and is detectable. It's the part of the system that lets you answer "what happened, and when?" with confidence.
One hub is a single point of failure. So the natural move is to add a standby that takes over when the primary dies. The naive design writes itself: the standby pings the primary every few seconds, and after N missed heartbeats it promotes itself to primary.
It works perfectly in a demo. It's dangerous in a house.

The trap: split-brain

Picture two hubs on your LAN. The network partitions — not the primary crashing, just the link between the two going away. The primary is alive and well, still serving its devices. But the standby can't see it.
So the standby promotes itself. Now you have two primaries, both convinced they're in charge, both writing to the audit log. The hash chain that made that log tamper-evident diverges into two incompatible histories. The one guarantee the whole system is built on — you can always reconstruct what happened — is gone.
A missed heartbeat doesn't tell you "the primary is dead." It tells you "I can't reach the primary." Those are very different statements, and the naive design treats them as the same.

The fix is mostly about honesty

The real solution to split-brain is a quorum — three nodes voting, à la Raft. But for a home or a small building, that's overkill, and you usually don't have a third node anyway.
So I went with something simpler and more honest: assisted failover. Two changes.
First, before the standby concludes anything, it runs a second probe against an independent target on the LAN (the gateway):

primary unreachable + gateway reachable  → primary is probably down
primary unreachable + gateway also down  → *I* am probably the problem

That one extra check separates two failure modes the naive design conflates. It is not a substitute for quorum — it doesn't help in every partition (if both hubs can still see the gateway but not each other, the probe tells you nothing). What it cheaply catches is the most common home case: the standby itself losing its network. When that happens, the standby enters an UNCERTAIN state and refuses to act.
Second — even when it does think the primary is down, it doesn't promote itself. It proposes promotion to a human. A person can glance at the situation and see whether the primary is actually alive. A 5-second heartbeat timeout cannot.
(To be clear, this whole multi-hub layer is opt-in. A single hub runs exactly as before — redundancy is for people who want it, not a requirement.)

Testing it on real hardware

I ran this on two real machines — a Raspberry Pi (primary) and a laptop (standby) — because this is exactly the kind of behavior that only shows up with real network conditions, not in unit tests.
Killing the primary process: standby detected it, gateway probe still succeeded, proposed promotion. Good.
Pulling the standby's network while the primary stayed up: standby saw both targets go dark, went UNCERTAIN, and stayed quiet. In that test, the only difference between "propose promotion" and "stay quiet" was the gateway probe — one bit of extra information deciding between a safe outcome and a corrupted log.

The takeaway

Availability features have a failure mode of their own. An automatic action taken on bad information can be worse than no action plus a clear signal to a human. For anything writing to physical state — locks, alarms, logs you can't afford to corrupt — "fail loudly and ask" is often a better default than "fail over silently," at least until you have real consensus to back automatic promotion.

DoSync is open source (Apache 2.0). If you want to poke holes in this design — and I'd genuinely like that — it's at dosync.dev. The failover logic is a small, dependency-free state machine; criticism welcome.

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

Rodrigo Giuliani — Wed, 03 Jun 2026 01:27:33 +0000

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.

The device that knows its own role

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.

The Capability Manifest — a declaration, not an API

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:

What can I do? — turn on, turn off, set brightness, set color
Where do I fit? — I'm a light, I'm a smart plug, I'm an emergency device
When do I matter? — I'm emergency-capable; include me when safety is at stake

The 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

Why this is different from OpenAPI, MCP, and service registries

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.

The device as a participant

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.

What the manifest teaches manufacturers

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:

Will this device respond in an emergency? → emergency_capable: true/false
What kind of device is this? → category + semantic tags
What can it physically do? → actuators with meaningful type names
What can it sense? → sensors with type and unit
How does the protocol talk to it? → 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.

The idea worth keeping

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

Rules Aren't Enough Once an AI Is in the Loop

Rodrigo Giuliani — Sat, 30 May 2026 03:06:15 +0000

Picture this: it's 03:00. A camera detects that an elderly person has fallen in the bedroom. The AI agent fires ensure_safety [emergency]. The action plan includes unlocking the front door so emergency services can get in.
But someone wrote a rule three months ago: never unlock after midnight.
The rule wins. The door stays locked. The paramedics arrive and can't get in.
This is not a bug in the AI. It's not a bug in the rule — in any other context, locking the door at night is exactly right. It's a design problem — and it's the exact problem that appears when you build physical AI systems on top of automation logic that was never designed for an AI to act on.
The difference between a rule and a policy looks small from a distance. Both constrain behavior. Both say "don't do X in situation Y." But they operate at different levels of the system — and getting this distinction wrong in a physical environment has real consequences.

What a rule is

A rule is a static, pre-written instruction that maps a condition to an action.

if time > 22:00:
    lock.lock()

if motion_detected and away_mode:
    alarm.activate()

if temperature > 28:
    ac.turn_on()

Rules live in the automation layer. They're written by a human, at configuration time, for a specific scenario that was anticipated in advance. They're deterministic in the right circumstances: given the same input, they always produce the same output.
Rules work well when the world is predictable, the device set is stable, and a human is always the one deciding what to do. They've been the foundation of home automation for fifteen years for exactly this reason. Nothing in this article argues that rules are wrong or should be replaced — they're the right tool for scheduling, thresholds, and simple automations that a human configured deliberately. A rule that turns on the porch light at sunset doesn't need a policy — it has no safety implications, no edge cases, and no AI acting on it. Rules fail not because they're a bad idea, but because they were never designed to compose with an autonomous agent that can fire arbitrary intents at arbitrary times.
But rules have a structural weakness: they can only respond to situations that were anticipated when they were written. And when an AI agent starts firing intents, the space of possible situations grows faster than anyone can write rules for.

What breaks when AI enters the picture

An AI agent doesn't write rules. It fires intents.
When a vision model detects someone who has fallen, it doesn't execute alarm.activate() and phone.call("911") — it fires ensure_safety [emergency]. When a model infers that nobody is home, it doesn't iterate through a list of devices and turn them off one by one — it fires save_energy [info].
The intent expresses a goal. The protocol figures out how to achieve it.
But here's the problem: once you have an AI agent firing intents, you need a way to constrain what it can and can't do — without writing a rule for every possible scenario. You need something that can evaluate intent against context at runtime, not something that was pre-written for a specific situation.
You need a policy engine.

The difference that matters

A rule answers: what should happen when X occurs?
A policy answers: is this action permitted, given who's asking, what they want to do, and when?
The distinction is not cosmetic. It changes the entire structure of how you think about safety in a physical system.
Consider a front door lock. With rules:

# Rule 1: lock at midnight
if time == 00:00:
    lock.lock()

# Rule 2: unlock for delivery window
if time > 14:00 and time < 16:00 and delivery_expected:
    lock.unlock()

These rules handle the scenarios they were written for. But what happens when an AI agent fires control_access [emergency] at 03:00 because it detected an intruder? What happens when a different AI agent fires away_mode which includes an unlock action? What happens when two intents fire simultaneously and both want to act on the lock?
Rules don't compose. Each rule was written in isolation, without knowledge of the others. In a system where an AI can fire arbitrary intents at arbitrary times, the rule surface grows unbounded — and the gaps between rules are exactly where accidents happen.
A policy is different:

pythonNeverAfterHoursPolicy(
    actuator="unlock",
    device_ids=["lock-frontdoor-01"],
    blocked_hours=range(0, 6),      # never unlock 00:00–06:00
    except_urgency="emergency",     # unless it's an emergency
)

This policy applies to every intent that would unlock the front door, regardless of which AI fired it, regardless of what scenario triggered it. It's declared once. It evaluates at runtime. It composes with other policies automatically.
And it has an explicit emergency exception — because in a physical system, the rule "never unlock after midnight" has to be breakable in genuine emergencies. Rules can't express that nuance cleanly. Policies can.

What a policy engine actually does

In DoSync, every intent passes through the PolicyEngine before execution. The engine evaluates the action plan against all configured policies and returns one of four verdicts:

ALLOW — proceed as planned
BLOCK — reject the intent entirely
CONFIRM — hold execution and request human confirmation
MODIFY — allow execution but remove or adjust specific actions

This happens between the resolver (which decides what to do) and the executor (which actually does it). The AI never bypasses this layer — not even for emergency intents, which bypass policy constraints at the urgency level, not by circumventing the engine entirely.
In DoSync, this looks like:

python# An AI fires save_energy at 02:00
intent = Intent(
    intent=IntentClass.SAVE_ENERGY,
    urgency=Urgency.INFO,
    context={"trigger": "occupancy_inferred_empty"},
)

# The resolver builds an action plan:
# → turn_off: wiz-living-01..10
# → turn_off: wiz-hallway-01       ← this one is excluded by policy
# → set_temperature: thermostat-01

# The PolicyEngine evaluates:
# DeviceExclusionPolicy: hallway light excluded from save_energy → MODIFY
# ContextualWeightingPolicy: 02:00 on a weekday → weight reduced but ALLOW

# The executor receives the modified plan:
# → turn_off: wiz-living-01..10
# → set_temperature: thermostat-01

The AI expressed a goal. The protocol decided how to achieve it. The policy engine ensured the result was safe — without the AI needing to know anything about the hallway light policy, or the time-based weighting, or which devices are excluded from which intents.

Why this matters beyond the home

The rule/policy distinction becomes critical at scale and in regulated environments.
In a hotel, a rule that says "turn off lights when nobody is in the room" works until a guest leaves their laptop charging and the system decides the room is empty. A policy that says "never cut power to outlet circuits in occupied rooms regardless of occupancy inference" handles the edge case — without needing a rule for every possible device state.
In a hospital, a rule that says "lock all doors at 22:00" breaks the moment a crash cart needs to move between floors. A policy that says "door locks revert to unlocked state on emergency_capable override, regardless of schedule" is robust to the scenario that matters most — the one nobody wanted to think about at configuration time.
In a factory, a rule that says "shut down line B if temperature exceeds threshold" doesn't compose with the rule that says "never shut down line B during a shift change handover." A ConflictResolutionPolicy that assigns priorities to intents and resolves contention explicitly is the right abstraction — not an ever-growing set of conditional rules that interact in unpredictable ways.
The pattern is always the same: rules break at the boundaries between anticipated scenarios. Policies compose across all of them.

The audit implication

There's one more difference that matters in regulated environments: auditability.
A rule that fires an action leaves a trace, but the reasoning is implicit — buried in the automation logic that evaluated the condition. If something goes wrong, you can see what happened, but reconstructing why requires reading the rule code.
A policy verdict is explicit. Every intent execution in DoSync's audit log records what happened, what the resolver decided, and what the executor did — in a tamper-evident SHA-256 chained record. The reasoning is in the system's configuration (which policies are active, with what parameters), not buried in conditional logic that has to be reverse-engineered after the fact.

json{
  "type": "intent_executed",
  "intent": "save_energy",
  "urgency": "info",
  "actions": 9,
  "failed": [],
  "success": true,
  "hash": "a3f7...",
  "prev_hash": "9c12..."
}

This matters for post-incident analysis. It matters for regulatory compliance. And it matters for the fundamental accountability question in any AI-augmented physical system: when something goes wrong, can you reconstruct exactly what the system decided and why?
With rules, the answer is usually "mostly." With policies, the answer is "yes, completely."

The deeper point

Rules encode what to do. Policies encode what's permitted.
When a human is always in the loop, rules are enough — the human's judgment fills the gap between what the rules say and what should actually happen. When an AI agent is in the loop, that judgment gap has to be filled by the infrastructure.
That's what a policy engine is for. Not to constrain the AI arbitrarily, but to make the system's safety model explicit, configurable, and auditable — so that the AI can act autonomously within a boundary that a human defined deliberately.
The AI expresses goals. The protocol executes them. The policy engine ensures the result is safe.
That's the contract a physical AI system needs.

DoSync Protocol: https://github.com/giulianireg-spec/dosync-protocol
License: Apache 2.0

How I Used GitHub Copilot to Turn a Half-Finished Protocol Into a Certified Standard published

Rodrigo Giuliani — Wed, 27 May 2026 02:23:47 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

DoSync Protocol is an open-source communication protocol (Apache 2.0) that lets AI agents control physical devices using semantic intentions instead of commands. Instead of lock.unlock(), an AI agent says ensure_safety — and every registered device figures out its own role automatically.
The Python reference implementation was running in production on a Raspberry Pi 5. But a protocol with only one implementation isn't a standard — it's a library. The unfinished piece: a second independent Node.js implementation that could pass the DoSync certification suite.

Demo

GitHub: https://github.com/giulianireg-spec/dosync-protocol

── Tier BASIC ─────────────────────────────────────────────
  ✓  Hub reachable — version 0.1.0
  ✓  Protocol version declared — dosync/0.1
  ✓  Device can register — registered
  ✓  Device appears in registry — 1 device registered
  ✓  Hub returns device detail — status=200
  ✓  Capability manifest has all required fields — all present
── Tier STANDARD — Intents and events ─────────────────────
  ✓  Hub accepts notify_family intent — 4 actions executed
  ✓  Intent resolves correctly — 4 actions processed
  ✓  Device can send event — received
  ✓  Hub rejects unknown intents with 422 — status=422
  ✓  Hub rejects unregistered device events with 404 — status=404
── Result ──────────────────────────────────────────────────
  Tests passed: 11
  Tests failed: 0
  ✓ CERTIFIED — DoSync STANDARD

The Comeback Story

Before: The Node.js implementation (implementations/dosync-node) passed Basic certification (6/6 tests) — it could register devices and handle simple queries. But Standard tier was failing at test 1 because the server was missing GET /v1/status, the endpoint the certification suite uses to verify hub identity and protocol version.
Additionally, the certification CLI (certify.py) only supported HTTP — but the production hub runs on HTTPS with a local PKI. Running Standard tests against real infrastructure was impossible.
What changed:
certify.py — fixed to support real deployments:

HTTPS support with CA certificate validation via DOSYNC_CA_CERT
Bearer token injection via DOSYNC_TOKEN
Localhost detection: HTTP for local dev, HTTPS for remote
Connectivity test fixed to use /v1/status instead of / (which returns the HTML dashboard)

dosync-node — the missing endpoint, added with Copilot:

GET /v1/status — the single endpoint that unlocked Standard certification

After: dosync-node passes DoSync Standard certification (11/11). Two independent implementations in different languages, same protocol, same certification suite — the minimum criterion for an open standard.

My Experience with GitHub Copilot

Copilot contributed in two ways during this session.
Inline suggestions while editing certify.py. As I was modifying the HTTP helper to support HTTPS and token injection, Copilot's inline suggestions consistently anticipated the next line — the SSL context setup, the os.environ.get() calls, the exception handling pattern. It didn't write the logic, but it reduced the friction of writing boilerplate correctly on the first pass.
The endpoint that closed the gap. Once I identified that GET /v1/status was the missing piece, I asked Copilot Chat:

"I'm implementing the DoSync Protocol in Node.js. The certification suite requires a GET /v1/status endpoint that returns name, version, protocol, status, devices count, and audit_entries count. The existing code uses Fastify. Please add this endpoint following the same patterns already in the file."

Copilot read the existing file, identified the right variable names (registry, auditLog, VERSION, PROTOCOL), and generated:

javascript// GET /v1/status
app.get('/v1/status', async () => ({
  name:          'DoSync Hub',
  version:       VERSION,
  protocol:      PROTOCOL,
  status:        'running',
  devices:       registry.size,
  audit_entries: auditLog.length,
}))

Correct variable names. Correct Fastify pattern. No hallucinations. The key was giving Copilot the right context: the spec requirement, the existing code pattern, and the constraint. It didn't need to invent — it needed to synthesize what was already there.
After accepting the suggestion, the certification run went from 0/11 to 11/11. GitHub Copilot helped close the gap between "protocol with one implementation" and "protocol with a certified standard."

Repository: https://github.com/giulianireg-spec/dosync-protocol
License: Apache 2.0

Why AI Agents and IoT Protocols Speak Different Languages

Rodrigo Giuliani — Tue, 26 May 2026 13:21:13 +0000

There's a distinction that comes up constantly when designing systems that connect AI to physical environments, and it's one that most protocols blur or ignore entirely.
The distinction is between an event and an intent.
They look similar on the surface. Both are messages. Both carry information about the world. But they describe fundamentally different things — and building a system that confuses them leads to brittleness, fragility, and automation that breaks exactly when it matters most.

What an event is

An event is a description of something that happened.

json{
  "device": "pir-sensor-01",
  "type": "motion_detected",
  "timestamp": 1748000000,
  "location": "entrance"
}

An event is past tense. It's factual. It carries no opinion about what should happen next. The PIR sensor doesn't know whether this motion means "the kids just got home" or "there's an intruder" or "the cat walked by again." It just observed something and reported it asynchronously — fire and forget.
Events are the raw material of a physical system. Sensors generate them constantly — temperature readings, contact closures, power measurements, motion pulses. They are objective and dumb, in the best possible sense.

What an intent is

An intent is a description of something that needs to happen.

json{
  "intent": "children_arrived_home",
  "urgency": "info",
  "context": {
    "trigger": "motion_detected",
    "time": "18:45",
    "day": "monday"
  }
}

An intent is future tense. It carries meaning. It encodes a goal — what the system should achieve — without specifying how to achieve it. The intent doesn't say "turn on lights 3, 7, and 9 at 80% brightness." It says "the kids are home." The infrastructure figures out the rest.

The leap from event to intent requires reasoning. Something has to look at the motion event, consider the time, the day, the history, and decide: this event means the kids just arrived. That reasoning is exactly what AI agents are good at.

Concretely, that transition looks like this:

[PIR fires motion_detected at 18:45 on Monday]
        ↓
  AI agent reasons:
  - time: 18:45 → within arrival window
  - day: Monday → weekday
  - location: entrance → consistent with arrival
        ↓
  fires: children_arrived_home [info]
        ↓
  hub resolves against device registry:
  → 5 lights turn on
  → SMS sent to parents
  → audit log updated

The agent handled the meaning. The protocol handled the coordination.

Why conflating the two breaks systems

Most smart home platforms today — Home Assistant automations, Matter scenes, Zigbee rules — are built on a hidden assumption: that the translation from event to action is a simple, static mapping.
IF motion_detected AND time > 18:00 AND day IN [Mon, Tue, Wed, Thu, Fri]
THEN turn_on(light_1), turn_on(light_2), send_sms("kids home")
This works until it doesn't. Add a new light and the rule doesn't know about it. Change the schedule and you rewrite rules. Move to a new home with different devices and you start over. The rule hardcodes both the reasoning ("this motion means the kids arrived") and the execution ("these specific lights, this specific message").
Separating events from intents breaks this coupling.
The AI agent handles the reasoning layer: event → intent. It observes the motion, considers the context, and decides what's happening. That reasoning can be as simple or as sophisticated as needed — a time-based rule, a learned pattern, or a full LLM inference.
The protocol handles the execution layer: intent → actions. Once the intent is declared, every device that registered as relevant participates automatically. Add a new light and it joins the response. Remove a device and the system adapts. No rules to rewrite.

Why this matters beyond the home

The event/intent separation is not a smart home concept. It's an architectural pattern for any system where AI needs to act on physical infrastructure.
In a factory: a temperature sensor fires threshold_exceeded on a critical component — that's an event. The AI reasons about it: abnormal reading, production line active, no scheduled maintenance — and determines execute_safe_shutdown. That's an intent. The execution is then coordinated automatically across the line: equipment powers down in sequence, the supervisor is paged, a maintenance request is logged, cooling activates. None of those responses were hardcoded for that specific sensor reading. Each system declared what it could do, and the protocol assembled the response.
The pattern is always the same: the AI reasons about meaning, the infrastructure handles coordination. The temperature sensor does not know about the cooling system. The cooling system does not know about the sensor. The protocol coordinates both.

How DoSync implements this separation

In DoSync, the separation is structural. Events flow in from sensors and adapters — raw, factual, carrying no prescription. Intents flow out from AI agents — meaningful, goal-oriented, carrying no implementation.
The hub sits in between: it receives intents, resolves them against every device's declared Capability Manifest, and builds an action plan at runtime. The resolver never sees the original event. The sensor never sees the resulting actions. The layers are cleanly decoupled.
That decoupling is what makes the system extensible by design. A new device joins the network, declares its capabilities, and automatically participates in every relevant intent — without any rule being written, without any configuration being changed.
That's the architectural difference that matters.

DoSync Protocol: https://github.com/giulianireg-spec/dosync-protocol
License: Apache 2.0

Why AI Agents Like Hermes Need a Semantic Execution Layer for the Physical World

Rodrigo Giuliani — Sat, 23 May 2026 16:20:14 +0000

This is a submission for the Hermes Agent Challenge: Write About Hermes Agent

Most AI agents interact with the world through APIs, databases, and web services. The feedback loop is fast and forgiving — if something goes wrong, you retry.
Physical environments are different. A light that turns on twice isn't a problem. A door that unlocks at the wrong time is. An agent operating in the physical world needs not just reasoning capability, but a clear contract between what it decides and what actually executes.
This post is about that contract — and why Hermes Agent's architecture makes it a natural fit for physical systems.

What makes Hermes Agent relevant here

Hermes Agent has three characteristics that matter specifically for physical environments:
Native MCP support. Hermes connects to external systems via Model Context Protocol natively. Any hub or device layer that exposes an MCP server becomes immediately accessible — no custom integrations, no bridges.
Multi-step tool use with context. Hermes doesn't just call tools — it reasons about which tool to call, in what order, based on context. For physical systems where the right action depends on time, location, and state, this matters.
Open weights and local execution. Physical environments often have strict privacy requirements. A system that can run fully local — without sending home sensor data to a cloud provider — is architecturally different from one that can't.
These three properties together describe an agent that can act on physical systems in a way that's both capable and auditable.

The gap it needs to cross

Every physical device protocol was designed around one assumption: a human decides what to do, and a device executes it. The protocols speak in commands — lock.unlock(), light.set_brightness(100).
An AI agent doesn't produce commands. It produces understanding. "The kids just arrived home" is not a command. The translation from that understanding to the right set of device actions — for the specific devices available, in the right context — still has to be written by someone, in advance.
This is where most physical AI integrations break down. The agent reasons correctly and the devices exist, but the translation layer between them is a pile of hardcoded rules that grows more fragile with every new device.
A semantic execution layer inverts this. Instead of the agent knowing how to act, devices declare what they can do and when they're relevant. The agent expresses goals. The infrastructure handles translation at runtime.

An experiment: Hermes + DoSync
I tested this with DoSync Protocol, an open-source hub (Apache 2.0) that implements this semantic layer. Devices register with a capability manifest. The hub exposes a native MCP server.
Connecting Hermes to DoSync required three lines in ~/.hermes/config.yaml:

yaml
mcp_servers:
  dosync:
    command: python3
    args: [/path/to/dosync/mcp_server.py]
    env:
      DOSYNC_HUB_URL: http://localhost:47200
      DOSYNC_TOKEN: <token>

I gave Hermes a single prompt:
It's 18:45 on a Monday. The PIR sensor at the entrance just detected motion.
What does the system do?

Hermes queried the hub state, reasoned about the time and day, identified the appropriate semantic intent (children_arrived_home), and fired it once. Five physical lights turned on. An SMS was sent to the family. The audit log updated with two new SHA-256 chained entries.
What Hermes didn't need to know: which specific bulbs to address, the SMS provider, or the schedule policy restricting this intent to weekday evenings. That knowledge lived in the hub. Hermes expressed a goal — the infrastructure handled execution.

The open question

This experiment raises a boundary question that physical AI deployments will have to answer: where does agent reasoning end and infrastructure policy begin?
Should Hermes decide which intent to fire, or should context mapping be pre-configured? When an agent acts in a physical environment with real consequences, how much autonomy is appropriate before a human needs to confirm?
Hermes Agent's transparency — open weights, observable tool calls, local execution — makes it the right kind of system to explore these questions. You can see exactly what it reasoned and why. In physical environments, that auditability isn't a nice-to-have. It's a requirement.

DoSync Protocol (open source): https://github.com/giulianireg-spec/dosync-protocol
Hermes Agent: https://hermes-agent.nousresearch.com

Why Hardcoded Automations Fail AI Agents

Rodrigo Giuliani — Fri, 22 May 2026 12:39:00 +0000

DoSync Concepts — Part 2 of 5

There's a rule every smart home developer has written at least once:

if motion_detected and time > 22:00:
    turn_on(hallway_light)

It works. It's simple. And it's the foundation of how every major home automation platform thinks about intelligence today.
The problem isn't that the rule is wrong. The problem is what happens when you add an AI agent to the system — and why rules, no matter how many you write, are the wrong abstraction for that job.

The rule-writing problem
Rules are commands in disguise. "If X happens, do Y" is just a delayed command — the human still decided what Y should be, they just decided it in advance.
That works perfectly when you can anticipate every scenario, your device set never changes, and the AI's job is simply to trigger pre-approved responses. None of those assumptions hold in a real AI-augmented environment.
Consider what happens when you add a new device. A smart lock arrives. You register it with your platform. Now you have to go back through every relevant rule and add the lock. Miss one and the system silently does nothing in exactly the scenario where you needed it most.
Or consider an AI that detects unusual temperature patterns in the kitchen — a sensor reading that might mean the fridge compressor is failing. The AI knows something is wrong. But there's no rule for "fridge compressor anomaly," because nobody wrote one. The system does nothing.
This is the brittleness problem: hardcoded automations only respond to situations that were anticipated when the rule was written.

Why AI agents make this worse, not better
The intuitive solution is to write more rules, or smarter rules. Use the AI to generate them. Inspect logs and auto-suggest new automations.
But this misses the architectural problem.
An AI agent doesn't produce rules. It produces understanding. When a vision model detects a fall, it doesn't know it needs to call phone.call("911") and lock.unlock() and alarm.activate("emergency"). It knows there's an emergency. The translation from understanding to commands still has to be written somewhere — by someone — in advance.
The more capable the AI, the more situations it can detect. And every new situation the AI can detect is a new set of rules that needs to be written to respond to it. The rule surface grows faster than anyone can maintain it.

What capability-based discovery changes
The alternative is to shift where the knowledge lives.
Instead of centralizing the response logic in rules, distribute it to the devices themselves. Each device declares what it can do and in what contexts it's appropriate to act:

json{
  "device_id": "lock-frontdoor-01",
  "tags": ["door-lock", "entrance", "emergency"],
  "actuators": [
    { "type": "unlock", "emergency_capable": true }
  ],
  "emergency_capable": true
}

This manifest is not a rule. It's a declaration. The device is saying: I can unlock. I'm relevant in emergencies. I'm at the entrance.
When the AI fires a semantic intent — ensure_safety / emergency — the resolver reads every registered manifest and asks: which devices declared themselves relevant to this situation? It builds the response at runtime, from what's actually available.
ensure_safety [emergency]
→ lock-frontdoor-01 unlock (emergency_capable, entrance tag)
→ alarm-main-01 activate (emergency_capable)
→ wiz-living-01..10 turn_on (light tag, full brightness)
→ notifier-sms-01 notify (communication tag)
All in parallel. No rules written for this scenario.
Add the smart lock tomorrow — it participates automatically in every relevant scenario. No rule rewriting. No code changes. The device brought its own knowledge.

The difference that matters
Hardcoded automations are fragile because they encode knowledge in a central place that can't keep up with change. Every new device, every new scenario, every new AI capability requires human intervention to update the rules.
Capability-based discovery distributes that knowledge to the edges. Devices own their context. The system is resilient to change because adding new capabilities is additive, not a rewrite.
For AI agents specifically, this is the difference between a system that only responds to situations you anticipated and a system that responds to situations the AI can detect — whether you anticipated them or not.

GitHub: https://github.com/giulianireg-spec/dosync-protocol
License: Apache 2.0

DoSync Concepts is a series exploring the ideas behind the DoSync Protocol — the semantic layer between AI agents and physical systems.