Backplane gives a coding agent a KiCad schematic and a STEP viewer

The interesting part of Backplane is the CAD layer, not the chat box

Backplane is described as a totally open source workspace for agentic hardware development, and the README is unusually direct about where its value sits: in the KiCad and FreeCAD viewers. The idea is that you watch every step the agent takes, and when it touches a specific component you can click on it and reference it in the workbar. That reference step is the part that separates this from a chat window bolted onto a text editor. A schematic is a graph of parts, nets and values, and a language model that can only emit text has to guess what is on screen. Giving the agent a viewer that returns the thing the human is pointing at turns a monologue into a shared session. The project also states that it is created and maintained by real electrical engineers, and that it ships with a full suite of CAD specific skills. The repository itself is mostly TypeScript, while the description notes the work is written in Bend, and the tree carries files named LAWS.bend and PROOF.bend alongside an AGENTS.md and a CLAUDE.md.

A KiCad fork with instrumentation for LLM control

Backplane is a KiCad fork, published separately as Backplane_KiCad. The README states that this fork adds extra instrumentation for LLM control, and names an IPC schematic API as the example. That is the mechanism behind the viewer workflow: a language model needs a programmatic handle on the schematic editor rather than a screenshot, and an IPC API is a way to expose that editor state across a process boundary. The fork approach has consequences. You are not running stock KiCad, so behaviour that differs from upstream is possible and would be hard to distinguish from a bug in the agent. The licence is handled separately for this reason, since the fork retains KiCad's licensing while the surrounding workspace is MIT. The top level tree also carries a patches directory, a tools directory, deploy and scripts directories, and a mobile directory, which together suggest that the fork is maintained as a patched derivative rather than a straight fork with a few edits bolted on.

Install is a curl pipe and a launcher command

The documented install path is two lines. The script comes from the releases of the backplane-bend repository rather than from the Backplane repository itself, and the pipe into a shell is the whole procedure.

curl -fsSL https://github.com/i2cjak/backplane-bend/releases/latest/download/install.sh | sh
backplane

After that, running backplane starts the workspace. There is no documented configuration step, no dependency list to install by hand, and no mention of a Python or Node setup, so the installer is doing the environment setup on your behalf. That convenience is also the thing to think about for a team environment: a remote script executed with your privileges is a supply chain decision, and some organisations will want to download the script, read it, and run it locally instead. The README does not describe what the script installs or how to point it at an existing project directory, so treat the first run as an inspection step rather than a production install.

Projects, threads, bots and an uberbot are four different levels of the hierarchy

The orchestration primitives are where Backplane goes beyond a single agent session. The README describes projects containing threads, bots, and an uberbot that coordinates bots, projects and threads. The claim is that any harness can create subagents with any other harness, and that all harnesses can send messages between threads. The README also states that Backplane works with whatever agent you bring, naming Grok, Codex, Claude, Antigravity and Muse, and noting that OpenCode support exists. Read that as a design intent rather than a tested matrix, since no compatibility table appears. The screenshots show a thread coordinating Claude and Grok subagents, which suggests the delegation is a first class object you can point at rather than a hidden implementation detail. For a team this matters, because it changes the unit of work from one conversation to a tree of conversations that outlive a single prompt.

Catbots carry webhooks, a mailbox and a web app that persists

Persistent agents, called catbots, handle specific tasks. The README describes them as shipping with webhooks and a mailbox system for communication, plus a space in which the bot can create a persistent webapp. The screenshots name the tabs directly: a Webhooks tab on the catbot, a Mailroom holding conversations and an open message, and a Space described as a persistent control desk that can serve a webapp. A mailbox with readable conversations is a deliberate choice, since it means an outside system can hand work to an agent and a human can read what came back without parsing logs. A space that can host a persistent webapp is the more unusual claim, because it turns an agent into something with a durable address of its own rather than a request and response endpoint. The trade off is that these are long lived processes holding credentials for webhooks and model providers, and the README does not document how their state is backed up or reset.

Reference syntax, link cards and inline terminals are the human controls

The interface details are specific enough to be useful. Links to other Backplane items can be made with the characters >, #, %, and @, and the README shows rendered thread, bot and project link chips plus reference menus offering thread, room, project and bot targets. That syntax is how you point an agent at a piece of work without pasting a long identifier. There are also inline terminals for TUIs, with a screenshot of an actual vi session running inside one, which matters for agents that shell out to command line tools and for humans who want to check on a running command. A side question command, spelled /btw, appears in the composer as a way to ask a question without disturbing the main thread. These are small decisions, but they are the difference between a tool that a person uses daily and one that gets abandoned after a week.

Nightly tags, an MIT core and an LGPL STEP pipeline

Two things deserve attention before anyone builds on this. The first is release discipline: the three most recent releases listed are all nightly builds with dates embedded in the tag, v0.11.2-nightly.20261014.1, v0.11.2-nightly.20261013.1 and v0.11.2-nightly.20261012.1. The last push was on 2026-10-20. There is no stable version in that list, so pinning a dependency means pinning a nightly tag and accepting that its contents can change without a version bump. The second is licensing, which is layered rather than uniform. The main project is MIT, the KiCad fork retains KiCad's licensing, and the STEP converter includes OpenCascade and occt-import-js under LGPL-2.1, with a third party licensing note referenced in the tools/step2glb README. Reading those files is a matter for your legal reviewer, but the structure itself means one checkout does not carry one licence, and a distribution that bundles the STEP tooling deserves a closer look than one that does not.

Editorial conclusion

Backplane makes sense for engineers who already work in KiCad and want a language model agent to inspect or edit schematics and boards while a human watches each step in the 3D, PCB and schematic viewers. It does not fit a team that needs a stable, versioned release, because the published versions are nightly builds and the newest one listed is v0.11.2-nightly.20261014.1, nor a team that requires a single uniform licence across the whole tree. Before adopting it, confirm three things: that the KiCad fork at Backplane_KiCad is acceptable to you given it keeps KiCad's own licensing, that LGPL-2.1 obligations around OpenCascade and occt-import-js in the STEP converter are covered by your process, and that piping install.sh into a shell fits your provisioning rules. The last push was on 2026-10-20, so the code is moving quickly, but the rapid nightly cadence means you should pin a specific tag rather than track the latest release.

Frequently asked questions

Official sources

1. i2cjak/Backplane on GitHub
2. License: MIT
3. Project website
4. README
5. Releases