Every mechanical engineer knows the sickening feeling of opening an assembly in SolidWorks or Inventor on a Monday morning only to find half the feature tree glowing bright red. You change an extrusion depth from 12 mm to 15 mm on an upstream bracket. The fillet on edge 42 loses its topological reference. The downstream hole pattern loses its sketch plane. Three mates fail in the top-level assembly, and the drawing views lose their associative dimensions. You spend forty-five minutes repairing sketch relations and re-selecting edges just to get back to where you started.
This persistent brittleness is the topological naming problem. Traditional direct-manipulation CAD systems assign internal, volatile IDs to vertices, edges, and faces. When you alter the underlying topology, those internal IDs scramble, severing downstream references.
Zoo.dev has taken an entirely different angle on this problem. Instead of forcing engineers to manually untangle broken feature trees inside a heavy GUI, their CAD agent, ZooKeeper, operates directly on KittyCAD Language (KCL), an open-source, code-driven geometry representation. By treating mechanical geometry as executable code paired with an agentic feedback loop, ZooKeeper attempts to do what human designers do: write geometry, test-compile it, inspect the visual snapshots for degenerate surfaces, and repair the syntax or geometric constraints until the solid model compiles cleanly.
To understand whether this actually works on the shop floor or if it is just a party trick for simple brackets, we have to look closely at programmatic B-Rep generation, the mechanics of KCL, and what happens when an automated agent tries to fix broken constraints.
Why GUI Feature Trees Break Down
Traditional parametric modeling kernels, like Siemens Parasolid or Dassault Spatial ACIS, maintain a directed acyclic graph (DAG) of features. When you sketch a rectangle, extrude a boss, and place a 3 mm fillet along an intersection, the CAD engine tracks the fillet not by an explicit geometric definition in space, but by referencing the edge ID generated by the extrusion operation.
If you modify the initial sketch to add a cutout that intersects that edge, the edge splits into two distinct segments. The CAD kernel cannot automatically determine which new segment should inherit the 3 mm fillet. If it guesses wrong, you get a self-intersecting surface, an invalid boundary representation (B-Rep), or a hard rebuild error.
In standard engineering teams, the overhead of maintaining these brittle trees is massive. Revision control is practically non-existent. You cannot run a git diff on a proprietary binary .sldprt or .ipt file. If two engineers modify the mounting flange of an aluminum housing simultaneously, you cannot merge their changes. One engineer has to discard their file and manually recreate the geometry inside the other engineer's version.
Code-driven CAD tools like OpenSCAD, CadQuery, Build123d, and now Zoo's KCL attempt to eliminate binary opacity. Geometry is expressed as human-readable, declarative, or procedural code.
// Basic KCL example for a simple mounting plate
const width = 120
const height = 80
const thickness = 10
const holeRadius = 3.5
const basePlate = startSketchOn('XY')
|> startProfileAt([0, 0], %)
|> line([width, 0], %)
|> line([0, height], %)
|> line([-width, 0], %)
|> close(%)
|> extrude(thickness, %)
In plain text, changes can be tracked line by line. More importantly, references can be explicitly named rather than implicitly assigned by a background kernel process. But writing pure code for complex 3D geometry is painfully slow for most mechanical designers who think spatially rather than syntactically. This is the bottleneck ZooKeeper targets.
Under the Hood of ZooKeeper
ZooKeeper is built on a simple premise: LLMs struggle to output flawless, production-ready 3D B-Rep kernels in a single zero-shot text-to-CAD prompt. A prompt asking for "a NEMA 23 stepper motor bracket with 4 mm wall thickness and slotted mounting holes" might yield code that parses syntactically, but produces an inverted normal, a 0.1 mm paper-thin web, or a bolt pattern that overlaps the structural ribbing.
Instead of treating model generation as a one-shot translation, ZooKeeper implements an iterative execution and validation agent. The architecture relies on three primary tools:
- A Documentation and Syntax Retriever. The agent searches KCL documentation to understand function signatures, plane definitions, sketch tools, and spatial transformation utilities.
- A Headless Geometry Engine. The agent feeds the generated KCL to the Zoo engine, which compiles the script into exact mathematical surfaces (NURBS boundaries and topological entities).
- Multi-View Visual Inspection. If the script compiles, the engine renders orthographic snapshots (top, front, side, isometric) and passes these images back to the multimodal vision agent to inspect the resulting geometry against the user prompt.
+-------------------------------------------------------------+
| User Prompt |
| "NEMA 23 bracket with 4mm wall and slotted mounting holes" |
+-------------------------------------------------------------+
|
v
+-------------------------------------------------------------+
| ZooKeeper Agent |
| 1. Formulate parametric strategy |
| 2. Query KCL documentation API |
| 3. Generate procedural script |
+-------------------------------------------------------------+
|
v
+-------------------------------------------------------------+
| Zoo CAD Engine Runtime |
| (Parse KCL -> Compile B-Rep) |
+-------------------------------------------------------------+
| |
[Syntax Error] [Valid B-Rep]
| |
v v
+-----------------------+ +---------------------+
| Feed compiler error | | Capture multi-view |
| log back to ZooKeeper | | visual snapshots |
+-----------------------+ +---------------------+
| |
+-------------------+------------------+
|
v
+-------------------------------------------------------------+
| Multi-Modal Visual & Logic Check |
| Does geometry match functional requirements & clearances? |
+-------------------------------------------------------------+
| |
[Issues] [Satisfied]
| |
+--> Re-enter Agent Loop +--> Final Output
When a compile error occurs, such as an unclosed sketch loop or an impossible fillet radius on an acute edge, the CAD engine produces a stack trace. ZooKeeper captures that error message, analyzes the failing line of KCL code, checks the constraints, and re-executes the script.
This cycle continues entirely behind the scenes before the user sees the first iteration. It replaces the traditional human workflow of clicking rebuild, reading an opaque warning dialog, editing the sketch, and clicking rebuild again.
The Reality of Agentic Debugging: Three Real-World Failure Modes
To evaluate whether this approach holds up in practical mechanical design, we need to examine how code-driven agentic systems handle the specific failure modes that plague machine shops and fabrication facilities.
1. The Zero-Thickness Geometry Problem
One of the most frequent rebuild bugs in standard CAD is non-manifold geometry, often caused by tangency conditions. Suppose an engineer defines an extruded cylinder tangent to a flat plate. At the exact line of contact, the material thickness is mathematically zero. Standard CAD kernels will either throw a non-manifold topology error or create invalid solid bodies that crash downstream CAM software.
// Problematic: Tangent cylinder creating non-manifold geometry
const plate = startSketchOn('XY')
|> startProfileAt([0, 0], %)
|> line([100, 0], %)
|> line([0, 50], %)
|> line([-100, 0], %)
|> close(%)
|> extrude(10, %)
// A cylinder whose perimeter exactly touches the plate edge
const boss = startSketchOn('XY')
|> circle([50, -25], 25, %)
|> extrude(10, %)
When ZooKeeper encounters this in KCL, the compiler returns a boolean failure. An agent cannot simply shift coordinates randomly. To fix the bug correctly, it must understand engineering intent.
Does the user want the boss merged into the body with an intentional overlap (say, 0.5 mm), or should the boss remain an isolated body for an assembly mate?
Currently, agents tend to resolve these issues by introducing arbitrary small offsets. While that satisfies the compiler and clears the error flag, an arbitrary 0.2 mm shift on a mounting datum will ruin an interference fit or misalign an O-ring groove. The geometry is syntactically valid, but physically ruined.
2. Edge Filleting Chains and Curvature Continuity
Fillets are the bane of procedural geometry. Applying a constant radius fillet along a chain of edges requires continuous tangent boundaries. If an edge transitions from a straight line to a high-order spline without G1 or G2 continuity, the fillet tool will self-intersect at the transition point.
In KCL, filleting is handled by referencing tagged paths or specific vertex selections within the script. If the agent modifies an underlying sketch dimension, say, widening an internal pocket from 20 mm to 35 mm, the fillet might now exceed the pocket wall length, causing a geometric collision.
When an LLM agent debugging KCL sees Error: Fillet radius 5mm exceeds maximum allowable edge length 3.2mm, its simplest mathematical path to resolution is to drop the fillet radius to 2 mm.
In a real-world CNC milled part, dropping that internal corner radius might force the machinist to swap out a standard 6 mm endmill for an expensive 3 mm micro-tool, doubling machine cycle time and tool deflection. The agent solved the geometric constraint, but spiked the manufacturing cost. Engineers using agentic CAD must pay strict attention to how these tools automatically resolve out-of-bounds parameters.
| Mechanical Constraint | How Human Engineers Fix It | How Current Agents (ZooKeeper) Fix It | Shop Floor Impact |
|---|---|---|---|
| Pocket corner fillet too large | Increase pocket dimensions or split fillet into variable radius | Lowers fillet radius to fit available edge | Forces smaller cutter diameter; increases machining time |
| Non-manifold tangent boss | Adds intentional material overlap (0.5 mm) or defines separate component | Offsets sketch location by small floating-point value | Alters critical center-to-center datum dimensions |
| Broken sketch plane reference | Re-anchors sketch to a stable primary datum plane | Re-anchors sketch to nearest active face | Creates nested dependencies that break on subsequent edits |
| Thread clearance interference | Adjusts hole diameter to standard tap drill size (e.g., 4.2 mm for M5) | Modifies hole to arbitrary float (e.g., 4.31 mm) | Strips threads or prevents standard tap engagement |
3. Datum Management and Downstream Stack-ups
Good CAD hygiene demands that critical functional dimensions reference a common primary datum, usually the primary locating face or tooling reference point. Poor CAD modeling chains dimensions from feature to feature, causing tolerance stack-ups that make parts impossible to inspect on a CMM.
When ZooKeeper builds or repairs KCL scripts, it frequently defaults to procedural relative movements: line([x, y], %) starting from the end of the previous line. This creates a chain of dependencies. If line 2 breaks, lines 3 through 10 lose their coordinate base.
For simple sheet metal brackets or 3D printed enclosures, chained definitions work fine. But for a gearbox housing where bearing bore centerlines must be held within 0.015 mm relative to a precision dowel pin, code-driven agents must be instructed to define geometric constraints relative to explicit coordinate systems, not sequential sketch segments.
The Advantage of Code: True Parametric Version Control
Despite the current edge cases, the pairing of an agent like ZooKeeper with a programmatic language like KCL solves the single largest structural problem in mechanical design teams: collaborative revision control.
Consider an engineering team designing an articulated robotic arm. The controls engineer needs to alter the internal servo mount geometry to accommodate a larger encoder. The thermal engineer needs to add cooling fins along the outer casing.
In a standard SolidWorks or CATIA environment, one engineer must lock the file. If both work on copies, someone has to spend a day manually reconciling the geometry. With KCL, the geometry lives in Git.
--- a/motor_casing.kcl
+++ b/motor_casing.kcl
@@ -12,7 +12,8 @@ const wallThickness = 3.0
const motorDiameter = 35.5
-const casingLength = 65.0
+const casingLength = 72.0 // Extended for optical encoder
+const encoderClearance = 8.0
const baseExtrusion = startSketchOn('XY')
|> circle([0, 0], (motorDiameter / 2) + wallThickness, %)
When a merge conflict occurs, or when a parameter change causes a feature failure on a different branch, an agentic debugger does not need to parse opaque binary blobs. It simply reads the Git diff, parses the compiler errors, and proposes a clean syntax resolution that satisfies both parameter changes.
This workflow brings mechanical engineering into alignment with modern software development practices. Teams can run automated Continuous Integration (CI) pipelines on physical hardware designs. Every pull request can compile the KCL, run headless geometric checks, generate step files, compute mass properties, and verify that bolt holes align across mating parts before a human lead engineer even looks at the PR.
Platforms operating in the generative mechanical space, including Mexaio AI, highlight this transition: moving away from slow, manual B-Rep tweaking toward automated, constraint-driven geometry generation that allows engineers to focus on performance requirements rather than feature-tree maintenance.
Scripted B-Rep vs. Generative Meshes: Why Exact Geometry Matters
Many recent AI CAD tools have relied on neural signed distance fields (SDFs) or polygon meshes, producing .stl or .obj outputs. These are completely useless for precision manufacturing.
You cannot send an STL file to a 5-axis CNC mill and expect the CAM programmer to extract clean cylindrical features for bearing bores with H7 tolerances. Mesh files lack topological intelligence; they are simply clouds of triangular facets. A cylinder in an STL file is an approximation composed of hundreds of flat faces. If you try to dimension the center of that cylinder on a manufacturing drawing, there is no center axis to snap to.
Zoo's commitment to compiling KCL directly into exact B-Rep geometry (NURBS surfaces, bounded analytical planes, cylindrical primitives) is what makes ZooKeeper relevant to working engineers. When ZooKeeper writes KCL, the engine outputs valid STEP files containing true analytical geometry. A bore remains an exact mathematical cylinder. A plane remains a flat surface with a defined normal vector.
This distinction is critical for shop-floor viability. If an automated design tool cannot export clean STEP, IGES, or native kernel formats with true topological faces, it is a concept generator, not a CAD tool.
How to Structure Geometry for Agentic Workflows
If you are planning to test code-driven CAD platforms or incorporate tools like ZooKeeper into your prototyping pipeline, you have to adjust how you structure your modeling logic. Agents operate best within well-bounded constraint frameworks.
Parameter Isolation at the File Header
Never allow an agent to write hardcoded numeric literals inside sketch operations. Force all dimensions into an explicit constants block at the very top of the script.
// Clean structure for agentic maintenance
// --- PARAMETERS ---
const shaftDiameter = 8.0 // Tolerance: +0.00 / -0.013
const bushingOD = 12.0
const pressFitAllowance = 0.02
const housingWidth = 45.0
const housingLength = 60.0
const wallMin = 4.0
// --- DERIVED DIMENSIONS ---
const boreDiameter = bushingOD - pressFitAllowance
When parameters are explicitly named and derived, the agent can alter overall form factors simply by adjusting root constants without touching the sketch logic, drastically cutting the risk of compilation errors.
Decouple Structural Geometry from Finishing Geometry
Keep fillets, chamfers, thread reliefs, and cosmetic drafts isolated at the bottom of the script. Do not interleave filleting operations inside intermediate sketch extrusions. Build the entire structural manifold body first. Once all boolean additions and subtractions are complete, apply finishing edge operations in a final pass.
This modular approach allows the agent to disable or adjust cosmetic features if a global dimensional change temporarily breaks an edge reference, preventing the entire model compilation from failing.
Use Explicit Planes Over Derived Faces
Avoid starting new sketches directly on the dynamic faces of previous extrusions if those faces might shift or vanish during parameter sweeps. Instead, construct explicit reference planes offset from the primary XY, XZ, and YZ coordinate systems.
If an agent modifies an internal pocket that eliminates face #12, a sketch built on an explicit offset datum plane will not crash. A sketch mapped directly to face #12 will break every single time.
What to Watch Next
The gap between text-to-CAD marketing and practical mechanical engineering reality is narrowing, but it is not closed. ZooKeeper demonstrates that conversational, agent-driven geometry generation is viable when it is bound to a strict, code-based language like KCL and backed by automated visual and compiler feedback loops.
For engineering leads and machine shop owners, the immediate value is not in letting an AI design an entire robotic chassis unsupervised. The real leverage lies in eliminating the mundane maintenance burden: automating standard hardware variations, setting up programmatic parametric part libraries, and using text-driven diff tools to debug broken geometry without losing half a day to sketch repair.
Keep an eye on how KCL develops its assembly mate constraints and GD&T (Geometric Dimensioning and Tolerancing) primitives over the coming months. Once code-driven engines can robustly enforce true position, flatness, and perpendicularity callouts directly within the script runtime, agentic CAD will shift from an interesting prototyping experiment to a fixture of the production engineering office.