Bjarke Ingels Group

Introduction

A lot of a firm's best automation lives in one person's Grasshopper definition. It works, everyone relies on it, and nobody else fully understands it. At Bjarke Ingels Group, the urban-design workflow had grown up that way: a powerful Rhino and Grasshopper script that one expert had built and carried. Over time, it became clear that too much of the workflow's knowledge was concentrated in one person. The script worked, but the firm needed a way to make that expertise more accessible as new people joined the team.

Rather than rely on a lone Grasshopper guru, BIG decided to build something maintainable and scalable. BIG's computational design team, working with Reope, rebuilt the workflow into something robust and owned by the firm, sitting inside the existing design process and making documentation in Rhino easy. The point wasn't only to make it maintainable. It was to get the workflow into as many hands as possible, so any planner benefits from the tool without needing Grasshopper skills of their own. Building on Rhino, a platform BIG's designers already use every day, meant meeting them where they already work rather than asking them to learn a new environment. Planners spend their hours testing options and pushing the idea further instead of on repetitive tasks. Scaled the right way, the workflow extends the team's creativity rather than limiting it.

The Problem

Grasshopper is perfect for getting from idea to working prototype. It's not built for what comes next: stable tools that multiple people develop together, under version control, with documentation someone can actually read. The knowledge isn't written down. It lives in one person's head, in the order they wired things, in the reasons behind a cluster nobody else dares touch.

So when BIG's urban-design expert moved on, the firm hit the problem every studio eventually meets. BIG's urban-design workflow had outgrown the medium it was built in. It still ran, but it couldn't really be changed, extended, or trusted. Fixing a bug meant reverse-engineering someone else's thinking. Adding a feature meant risking the whole thing. A workflow that should have been a firm-wide asset had quietly become a liability. Add the usual fragility of a definition that breaks on a Rhino or Grasshopper version change, and the problem compounds the moment it relies on plugins. Every third-party component is its own dependency, and any one of them updating, breaking, or going unmaintained can stop the whole definition from running. Left as a loose script, the case for it fell apart.

BIG decided not to patch around the gap but to close it properly: turn the workflow into real software the whole urban-planning group could develop and depend on.

What the toolkit does

The Urban Toolkit rebuilds the moves BIG's planners make at the start of every design proposal into a single, guided Rhino panel.

• Site and road networks: define a site and generate a road network.
• Plots: subdivide the network into plots and assign land uses across them.
• Massing: generate building massings.
• Landscape: scatter trees and landscape elements across plots, roads and open areas.
• Context import: pull the real surroundings into the model, neighbouring buildings, roads, green space, water and trees, georeferenced to the design.
• Metrics and checks: live area metrics and a dashboard as the scheme develops.
• Connected to AI: because everything above is structured data, the model is queryable by BIG's AI agents over MCP (the Model Context Protocol) directly inside Rhino, and linked to image-generation services for early-stage exploration.

All of this runs behind a real interface that follows the design sequence, so a planner who never saw the original definition can sit down and use it.

How we built it

We built it together with BIG's computational design team. Reope's Architects who code and BIG's own developers worked side by side, reading the original logic, rebuilding it, and shaping it around how BIG's planners actually work. It started with a workshop across BIG's offices to map the real user journey, name the pain points, and set the roadmap against a shared two-year vision. The goal was never a one-to-one port of one person's definition. It was to grow the workflow, together, adding capabilities the original script never had.

1. From definition to real software: BIG's early work was rebuilt into a structured, maintainable codebase, developed jointly so it no longer depends on any one person to keep running.
2. The interface: the tools follow the real design sequence, so the workflow reads the way architects actually work.
3. Built and extended together: BIG's developers and Reope share the codebase and the roadmap, both actively building on it, delivered through BIG's subscription with Reope.

Outcomes

• Knowledge that stays at the firm: the urban workflow no longer lives in one expert's head or one expert's file. It's software BIG owns, can read, and can hand to anyone.
• Reach beyond the specialists: the toolkit removes the Grasshopper skill barrier, so every urban planner can use it, not just those who could build scripts. Building on Rhino means it meets designers on a platform they already know.
• A tool BIG builds on: the firm's own team develops the toolkit alongside Reope, not just receives it, generating sites, road networks, plots and massing without needing to understand the logic underneath.
• Robust where the script was fragile: moving from a Grasshopper definition to a structured Rhino plugin means the workflow survives version changes, bug fixes and new features instead of breaking under them.
• A roadmap BIG shapes: the workshop turned the next features into a shared, prioritised list, so the tool keeps growing around what planners actually need.

Bringing the toolkit into BIG's AI stack

Rebuilding the workflow as a real plugin did something a Grasshopper definition never could: it made the urban data reachable by everything else BIG is building. The same structured outputs the plugin produces, plots, massings, land-use, site boundaries and area metrics, become data that AI tools can actually query.

We're connecting the toolkit into BIG's wider intelligence stack through MCP (the Model Context Protocol), so the firm's AI agents can call the plugin's tools directly inside Rhino rather than treating 3D work as a black box. API-based and centrally secured, with keys held in BIG's own vault, no personal accounts. The same approach extends across software: a coordinating layer that auto-discovers MCP tools wherever they live, so an agent can reach the right tool in the right application without a person wiring it up each time.

From there the door opens to the rest of the field, connecting the urban data to image-generation services and other AI tools that suit early-stage and research work. One thing we're disciplined about: these tools are strongest at research, early-phase exploration and structured data. We keep them there. Fast outputs that look convincing are not the same as design-grade accuracy, and we don't pretend AI is doing the designing. The planners are. The toolkit and the AI around it just put more within their reach.

Conclusion

Every firm has a script like BIG's: powerful, depended on, and quietly resting on one person. The smart response isn't to hope that person never leaves. It's to build something maintainable and scalable the firm owns and develops. That's what BIG and Reope did together, turning a fragile Grasshopper definition into a robust Rhino plugin in the hands of every urban planner who needs it. A design tool should match your process and feel intuitive, and it should never depend on a single person to survive. That's the difference between a clever script and a real tool.