Local Intelligence: A Stage Pipeline for AI-Orchestrated Grasshopper Workflows

We have recently been experimenting with AI and Grasshopper to better understand the limits of the technology. When people think of AI-powered design tools, they often imagine heavy computation taking place in remote data centres. This experiment inverts that assumption: we break user intent into blocks of execution simple enough to be performed on a laptop with a free, open-source LLM.

Grasshopper is particularly well-suited to this because the action space is discrete — you're picking from known components — and the output is verifiable: the graph either solves or it doesn't.

Breaking intent into stages

To achieve this, the system uses a curated stage pipeline to translate natural language into executable Grasshopper workflows. When a user types "create a box from the origin to 100,100,100," the pipeline breaks this into discrete stages.

Prompt Rewrite — Normalise informal language into precise geometry operations.

AI: The task is to create a box from the origin (0,0,0) to point (100,100,100).

Tool Discovery — Query a local RAG index to find relevant Grasshopper tools.

AI: Total tools: 20

Tool Selection — Choose which tools match the user's intent.

AI: Selected Tool: Box2Pt

Graph Generation — Build a connection graph specifying how tools wire together.

AI: 1 Valid Graph

Execution — Run the graph using Grasshopper's solver.

Tool Call: Calling Box2Pt… Tool Result: Box2Pt: Success

By simplifying each operation the LLM needs to perform into discrete tasks, the pipeline enables a less capable AI to do more — and ensures the output is usable.

Why running locally matters

This matters for several reasons.

Running locally eliminates per-query API costs, making experimentation effectively free and removing the financial friction that often discourages designers from iterating.

It also broadens access: anyone with a modest laptop can use AI-driven design workflows without subscriptions, accounts, or even an internet connection.

Sensitive client work and proprietary geometry never leave the user's machine, addressing the privacy concerns that have kept many firms cautious about cloud-based AI.

And by decomposing complex intent into small, well-defined stages, smaller models can punch above their weight — showing that capable AI design assistance doesn't require frontier-scale infrastructure.

The scaffolding scales upward

Pipeline scaffolding also scales upward. The same infrastructure that makes a small local model usable allows us, at the flip of a toggle, to start burning credits and route any stage to a frontier model instead. The architecture doesn't change — only the endpoint.

Each stage — prompt rewriting, RAG-based tool discovery, tool selection, graph generation, verification — becomes more reliable when handed to a more capable model. And the evaluation surfaces built to coax a small model into behaving give us measurable benchmarks for confirming where that upgrade is actually worth paying for. The work invested in making this run locally isn't wasted as models improve; it's what lets us take advantage of them, stage by stage.

A deliberately simple example

Whilst the example is deliberately simple — and would be faster to wire manually — the value of the experiment lies elsewhere. As local models continue to improve in both capability and efficiency, the same pipeline begins to handle progressively more complex intent without changing shape. It offers an early sense of how this kind of tooling could empower future designers as the underlying models catch up.

The animation above is a proof of concept. It shows a crude Grasshopper component with a chat interface. The model being used is the tiny Gemma4-E4B from Google, and we are running it on a laptop. Do note that the footage has been sped up slightly for the article. To set this up, all the native Grasshopper components have been extracted into their own MCP tool with a description, along with their required inputs and outputs, and all the tools have been loaded into a RAG server (a database-like framework for the LLMs to use). The RAG can then be queried to retrieve the correct tool, which can then be used to generate new geometry. Manually wiring a two-point box in Grasshopper is quick, but using a local LLM to automate the process sets the stage for future AI-assisted CAD. The MCP tool in this example is just a box, but there is nothing stopping the tool from being any existing large or complex GH definition — the subject of an Insight we have coming in two weeks. This experiment shows where design technology might be going:

• Local is viable: Shifting AI processing from cloud servers to a local machine is not only about saving money, but also about keeping control over your data. For architecture and engineering firms working with sensitive designs, preventing data leaks is essential.
• The power of modular scaffolding: Smaller open-source models struggle to "build a parametric tower" all at once. But if we break down complex design tasks into clear, separate steps (Rewrite → Discover → Select → Graph → Execute), these models can handle much more complex logic.

This work explores the challenges between natural language and parametric logic. As local models become faster and more powerful, the framework shown here will be able to handle more complex, multi-step design tasks, changing how we work with design tools.