← Back to Journal

AI agents need editable geometry

A useful design assistant must work with units, object relationships and changes that a designer can inspect.

Concept illustration of a wireframe surface beside a connected node graph
Concept image: parametric geometry and connected nodes.

A convincing canopy image tells us little about the curves, units or connections behind it. To continue designing, we need geometry we can identify, measure and change. Rhino’s object model provides geometry together with attributes and identifiers; these are useful starting points for an assistant’s task.

Define the operation before running it

Consider a row of facade fins. We would provide guide geometry, a working plane, units and spacing, then identify the windows, doors and structure to preserve. The assistant should inspect those inputs before proposing a change.

Function calling connects a model to operations that an application actually executes. Mentioning Rhino in a prompt does not supply that connection. The available tools and the information they return determine what the assistant can do.

Make a small, reversible trial

  1. Generate a few fins on a separate layer, keeping the source geometry.
  2. Test a reversed guide curve and a boundary that cannot fit the requested spacing.
  3. Run a revision and check whether the intended objects update or duplicate.

For a Grasshopper definition, the same discipline applies to slider ranges, data trees and named inputs. A short frontage and a changed bay count should produce an understandable result or an explicit failure.

Leave a definition someone can continue

Falcon is our working research prototype for assistance with Grasshopper definition context and validation. FraktalMCP is a separate published plugin. Neither changes the need to review architectural decisions.

Our proposed handover would include the editable objects, the task’s assumptions and a small check. Another designer should be able to tell which decision a parameter controls before changing it.