I wired a circuit board whose components reason
When we talk about AI agents, one image dominates: an assistant that responds. You write to it, it responds, you write back. It's a conversation. And a conversation has a flaw that no one names: it cannot be measured. If the answer is good, great. If it's wrong, you start over. There's nothing in between — no point where you can place a probe.
I ended up building something else, without having decided to at the start. Looking at what it became, the right word wasn't "assistant". It was circuit board.
Four parts, and that's it
The component. An agent that does one single thing, and refuses one single thing. Not an agent that "knows how to do everything": an agent that proofreads, or an agent that checks, or an agent that searches. A component that does two jobs can't be tested anymore. You no longer know which of the two failed.
The connection. Between two components, work doesn't flow by itself: the connection has to open. Someone — a person or a component — lets it through, or not. That's the difference between chaining calls and wiring authority. In a conversation, everything said is available immediately. On a board, the signal waits.
The fuse. It doesn't argue, it doesn't offer an alternative, it cuts. A fuse that asked for permission before melting would be useless — the overload would have already passed. Mine are deterministic code: same input, same verdict, twice in a row. Zero model, zero token, zero hesitation.
The signal. A piece of data that advances from one connection to another, and that you can observe at every point along the path. That's the property a conversation never gives.
What this changes, concretely
When an assistant makes a mistake, you rephrase. When a board makes a mistake, you know where. You put the probe on the previous connection: the signal was good before, bad after. The faulty component is named in thirty seconds.
Testing becomes possible. You don't test a conversation: you re-read it and decide it "seems good". You test a circuit: you inject a known input, you look at what comes out, you compare. And above all, you replay — the same test, tomorrow, in a month, after changing a part.
There's a consequence I hadn't foreseen. It became the most useful: the chip is interchangeable. The component that reasons can be replaced by another model — from another provider, another generation — without redesigning the board. What holds the whole thing together isn't the model: it's the connections and the fuses. The day a provider shuts down, closes, or triples its prices, the board keeps working. I verified this by doing it.
Does this already exist? Yes, partly
I'm not going to claim I invented the directed graph. Tools already chain steps and decisions: workflow engines that have existed for years, recent libraries that organize model calls into nodes and edges. The form isn't new. Anyone in the field will see it right away.
What I haven't seen anywhere, however, is the discipline:
- Authority is wired, not requested. Most systems give instructions to the model — "don't do this". An instruction is a prayer. On a board, what a component cannot reach, it cannot reach: it's not written in its prompt, it's absent from its wiring.
- Fuses don't reason. Entrusting safety to a model is asking the one being monitored to keep the register. A fuse is tested, replayed, and gives the same verdict twice.
- There's a test bench. Not a suite of unit tests on the code: a bench that replays the paths, on live pages, and turns red when a point stops responding.
What it costs — because it costs
Writing an instruction takes two minutes. Wiring a board takes days. As long as nothing needs to hold up, the instruction wins, and that should be said.
It flips the day something must not fail without us knowing. The day a job runs while you sleep. The day a silent failure costs more than the wiring time. That's when a circuit is worth more than a conversation — and not before.
The sentence that sums it all up. An assistant that makes a mistake gives you a wrong answer. A board that makes a mistake gives you a false measurement at a specific point — and a false measurement can be fixed.
Why I'm telling this
Because I didn't build this knowing the theory. I built it by fixing, one failure after another, and each time refusing the solution that would have worked "for this time". Each fuse on my board bears the name of something that broke.
If you're connecting agents right now, I have only one thing to suggest: stop writing to them what they shouldn't do, and unplug it. The difference between the two is the whole difference between a promise and a circuit.