I let an AI agent flip my circuit breakers (carefully)

Most agentic AI demos stop at the screen: an agent that drafts an email, files a ticket, or summarises a document. I wanted to see what changes when the agent’s output is physical. So I built an agentic workflow in n8n that controls smart MCBs — miniature circuit breakers — in my home, based on email notifications.

It works. More interesting is what it taught me about designing agents that act in the real world.

How does the agentic workflow work?

The pipeline has four stages:

1. Trigger. n8n watches an inbox for incoming notifications.
2. Understand. An AI agent step reads the email and decides whether it calls for an action, and which one.
3. Validate. Deterministic checks decide whether that action is allowed.
4. Act. The approved command is published over MQTT to the smart breaker, and the result is logged and reported back.

n8n is a great fit for this: visual workflows, a solid set of email and MQTT integrations, first-class AI agent nodes, and the ability to drop into Node.js code when a step needs real logic.

The model decides intent. Code decides permission.

This is the most important design decision, and it applies far beyond home automation. The language model is excellent at interpreting messy, natural-language email. It should never be the thing that decides whether a circuit is allowed to switch.

So the agent’s only job is to produce a small, structured intent — something like device, action, reason. Everything after that is plain code:

• An allowlist of devices the workflow may touch, and the actions permitted on each.
• Schema validation — anything that doesn’t parse into a known intent is rejected, not guessed at.
• Rate limits and cooldowns, so a flood of emails can’t toggle a breaker repeatedly.
• A sender check, so only trusted sources can trigger actions.

Treat every input as hostile

An agent that reads email is an agent that anyone on the internet can send instructions to. Prompt injection stops being theoretical when the output is a relay. Because the model only emits an intent and never calls the device directly, a malicious email can at worst produce an intent that the validation layer rejects.

Close the loop

Every action is logged with the triggering email, the parsed intent, the validation result and the device’s confirmed state after the command. When something unexpected happens — and with IoT, something always does — that trail is how you find out whether the model, the rules or the hardware was at fault.

What this taught me about agents

The more real-world power an agent has, the smaller its decision surface should be.

At work and at FinMoon AI, the same principle holds: let the model interpret, let deterministic code authorise and execute, and log everything. My breakers are the low-stakes version of a question every company adopting agents has to answer: what exactly are we letting it touch?