Your AI CAD agent doesn't have a reasoning problem. It has a context problem.

In the last two weeks, three separate builders independently hand-built the same thing: a way to give AI agents shared product context before asking them to do engineering work.

Not better prompts. Not bigger models. A document the agent can actually read — board, enclosure, BOM, design intent — in one place.

That's the tell. When three unrelated engineers hit the same wall and build the same workaround, the wall is the product.

Builder 1: a shared project file for agents (ForgeLab)

ForgeLab is a JSON intermediate representation plus MCP server that lets AI agents generate KiCad PCBs and FreeCAD enclosures from the same project document. The author's own framing: "Tie board, enclosure, and render documents together with shared dimensions as a single source of truth."

Read what that implies. The ECAD tool knows the board. The MCAD tool knows the enclosure. Nobody knows both — so the builder invented a third format, a neutral JSON file, to be the place where the truth lives. The agent doesn't work in KiCad or FreeCAD. It works in the JSON, and the tools consume it.

It's pre-alpha — 5 stars, self-described as early. But the instinct is the important part: the builder's first move was to create a shared context document, then give the agent tools. Context first, reasoning second.

Builder 2: ECO-drift detection the vendor never shipped (eda-agent)

eda-agent is an open-source MCP server — ~400 tools on the Altium backend — that drives a live Altium Designer session. An electronic design engineer in Malta built it because the official APIs didn't expose what he needed, so it "drives the GUI where there is no API."

And then he built this: crossref_net, a function that compares the schematic pin list against the PCB pad list for the same net. "Catches ECO drift, stale post-fabrication routing, phantom nets." In plain terms: the board was fabricated from an earlier schematic revision, a later edit broke the post-ECO merge, and nobody noticed. He hand-built the change-impact detection the tool should have had.

Here's the honest part — his own admission, in the project's known limitations: "ECO (sch → PCB update) is not reliably scriptable." Altium's ECO process command sometimes runs silently without applying changes; sometimes it pops a modal dialog. You cannot reliably automate a change through UI automation, no matter how good the model is.

That sentence is the whole thesis. The reasoning is fine. The model can read the design, ask questions, modify it in place while you watch. What breaks is the change itself — propagating it reliably across representations. That's a context and change-management problem, not an intelligence problem.

Builder 3: the design-review agent that had to add a context subagent (kicad-happy)

kicad-happy (1,188 stars) turns an AI coding agent into a PCB design reviewer — deterministic analyzers extract facts into auditable JSON, the agent reasons over schematics plus downloaded datasheets and writes severity-ranked reviews, a GitHub Action runs it on every PCB PR.

And in v2.0, the author added something telling: an optional design_context subagent whose only job is to "supply schematic and design-intent context as input."

That's the concession. The review agent had the schematic facts. It had the datasheets. It still needed the design intent handed to it separately — the why behind the layout, the constraints, the decisions that don't live in any single file. So the author built a subagent whose entire purpose is carrying context.

The pattern

Three builders, three workarounds, one diagnosis:

Builder	What they built	What the agent was missing
ForgeLab	Shared JSON project file	Cross-discipline truth (board + enclosure)
eda-agent	ECO-drift detection	Change propagation across schematic ↔ PCB
kicad-happy	design_context subagent	Design intent as review input

None of them upgraded the model. All of them upgraded the context.

This is also what the benchmarks are starting to measure. RealCADBench found that stronger models produce CAD that runs more often but is less semantically correct — more executable, less right. Capability is not the constraint. And Andrew Ng's team put the human-loop version of the same point bluntly: "A human approval prompt is useful only when the reviewer has enough context to review the change."

Humans, agents — same rule. Review without context is rubber-stamping, whether the reviewer is a person or a model.

So build the context layer

The market is converging on a product-context layer from below: hand-rolled, per tool pair, per builder. ForgeLab's JSON file. eda-agent's drift checks. kicad-happy's context subagent. Each one is a fragment of what should be infrastructure — a versioned graph of the product that every agent and every human reviewer reads from the same place.

That's the layer ProductFlo is building. The builders are proving the need, one workaround at a time.

---

Sources: ForgeLab ("The LLVM of design"); eda-agent by George Saliba / Salitronic, incl. known limitations; kicad-happy by Andrew Klofas, how-it-works; RealCADBench; Andrew Ng on coding agents.