Building Arbor · Part 4

One Conductor, Many Surfaces

Steven Neamonitakis

One low building drawn five times side by side in five different architectural notations: plan with hatched wall poché, section with hatched cut walls, plank elevation with a square window, axonometric wireframe, and dense cross-hatched silhouette with a window opening left as paper. A continuous vermillion datum line and dimension chain run below all five, unifying them.
Five ways of describing one building, none of them wrong. The line along the bottom is what makes them agree. Made for this series with an image model, not a historical drawing.

Part 4 of Building Arbor. A series about my design-system work on Arbor at Linktree.

Here’s the part I find genuinely exciting, and it’s bigger than any one of the tools in the earlier posts.

Each surface (the design tokens in Figma, the component specs, the specs plugin, the design-system research) knows something different and true. On their own, they’re separate places a person has to know to go look. The unlock was giving Arbor an MCP server that acted as a conductor over all of them.

Routing, not remembering

Instead of a human deciding “for this question I should check Figma, but for that one I need the specs, and for this other thing I should go read the research,” the MCP made that routing decision itself. Ask it something, and it dispatches: this part goes to Figma to check the live token values, this part goes to the specs to check the component contract, this part goes to the specs plugin, this part goes to the research corpus for how the frontier handles it. Then it composes the answers back into one coherent response.

That’s the difference between a pile of good tools and a system. A person shouldn’t have to hold the whole map of where every kind of truth lives in their head just to ask a straight question. The conductor holds the map. You ask; it knows who to ask, and it comes back with an answer that’s already reconciled across all of them.

The docs write themselves from the same well

And once you have that front door, everything can walk through it. The documentation site itself consumed the same MCP — so the docs weren’t a separate artifact someone had to remember to update; they were another view of the same reconciled truth. When the system’s answer changed, the docs changed with it, because they read from the same place the agents did.

Documentation that can’t drift from the thing it documents is a rare and good property. Most teams treat docs as a maintenance tax and lose the fight to rot. Making the docs a read-only view of live state is how you stop losing it.

The same instinct, at its conclusion

It’s the Figma plugin and the researcher taken all the way: don’t make people go find the knowledge — put a single front door in front of all of it, and let the system route.

There was one surface left to reach, though — the one where engineers actually decide. That’s the last post.

Up
Next