Konnect puts agents on the KiCad controls
Konnect 0.13.0 is a beta KiCad 10 plugin and Model Context Protocol server. Its README lists 228 tools across 21 toolsets. Those tools cover schematic edits, board layout, routing, electrical checks, design review, parts search, and manufacturing exports.[1]
The project uses two write paths. It edits schematic files with its own S-expression engine and atomic file replacement. It edits a live board through KiCad's inter-process communication API. The README says live board edits join KiCad's undo and redo history.
KiCad's own documentation explains a limit that every agent client must respect. API events run through the application's event loop. KiCad can block or time out a request while the user is doing other work. The documentation also says several connections gain nothing because KiCad orders the requests anyway.[3]
A transport success proves that a message arrived. It does not prove that the intended copper, net, footprint, or rule changed.
The repository names five outcomes
Konnect's reliability contract separates complete work, partial work, refusal before mutation, uncertainty after possible mutation, and an unavailable check. That split matters because each state has a different recovery route.[2]
A partial batch should identify applied, failed, and unattempted items. A refusal permits a corrected retry only when evidence shows that nothing changed. An uncertain write demands inspection before retry. Repeating the whole request can duplicate the work that already landed.
The contract also separates a completed check from a clean design. A design-rule check can complete and report violations. A valid search can complete and return no matches. A missing or undecodable result is neither one.
Readback needs an independent witness
The project tells callers to bind the exact document, identify whether each result came from the live editor or the saved file, and await state-changing prerequisites. Save and design-rule-check calls issued at the same time do not create an order.
Then comes the important part. Read the changed state through another route. Compare the netlist, electrical or design-rule output, and rendered board with the request. A handler that repeats the requested coordinate has echoed intent. It has not measured the result.
The repository is candid about unfinished coverage. At revision 9488e5f, the shared outcome envelope covers three named handlers. The contract lists design-rule-check source authority, explicit configuration fallback, and mixed live or saved readers as tracked gaps. The beta label is doing honest work here.
A passing check still needs taste
The exact Hacker News thread includes first-person reports of functional boards, poor automatic routes, useful parts research, and layouts that still needed human correction. Those comments are field reports, not controlled benchmarks. They agree on one practical point: rule checks and visual review catch different failures.[4]
An electrical-rule check can catch missing or conflicting connections. A design-rule check can catch clearance and geometry violations. Neither decides whether a trace snakes through a cramped area when a cleaner route exists. Rendered inspection and engineering review remain separate gates.
The safe route is ordered: bind the exact project, apply one bounded change, read it back, run the relevant check, inspect the rendered result, and record who accepted the release. Keep the error and the board untouched when persistence is uncertain.