IKEA hacking is the closest thing consumer culture has to a working model of composable agent architecture, and the design community figured it out before we did.
That sounds like a stretch. It isn’t. Look at what’s actually circulating right now. Apartment Therapy has a roundup of ten places to shop for parts to modify IKEA furniture. Man of Many published sixteen hacks. The Spruce collected eighteen ways to convert an IKEA cabinet into a greenhouse for houseplants. Dengarden covered four techniques for making flat-pack pieces read as more expensive than they are. Livingetc went further and wrote about outsourcing the modification entirely to brands that specialize in it.
Five separate publications, one pattern: a small set of standardized base units, an open interface, and an ecosystem of third-party modifications that the original manufacturer never specified. If you have spent any time thinking about how agent systems get built, that description should feel uncomfortably familiar.
Standardization is what makes modification possible
The reason there are sixteen notable IKEA hacks and not sixteen thousand notable Random Furniture Store hacks is constraint. IKEA sells a limited catalog of units with predictable dimensions, predictable materials, and predictable joinery. Because the base is boring and fixed, the modification space becomes legible. A hacker can reason about it. A brand can build a business on top of it, as Livingetc’s piece describes.
Agent architecture keeps relearning this lesson the hard way. Every team that builds a bespoke tool-calling format, a custom memory schema, a one-off orchestration protocol, is building furniture nobody can hack. It might be better furniture. It is definitionally less composable, because no third party can predict its interfaces well enough to build against them.
The tension is real, and I do not think it resolves cleanly. Standardized interfaces are lowest-common-denominator by construction. A protocol that any agent can speak is a protocol that constrains what any agent can express. IKEA’s cam locks are not the best joinery available; they are the joinery that works when the assembler is a stranger with an Allen key and no training. The engineering question is whether your system’s value lives in the joinery or in what gets built on top of it.
The greenhouse cabinet problem
The greenhouse hack is the interesting one. Someone took a glass-fronted display cabinet, a product designed to hold objects and be looked at, and turned it into a controlled environment for growing plants. That requires humidity, light, air circulation, and drainage — none of which the original product accounts for.
This is emergent repurposing, and it is the thing agent designers both want and fear. We want systems flexible enough that users find applications we never planned. We also want systems that fail predictably. A cabinet full of standing water and grow lights is a product operating well outside its tested envelope, and the manufacturer has no visibility into it at all.
Agent systems face the same asymmetry. A tool interface designed for one purpose gets composed into a chain the designer never modeled. Sometimes that produces the greenhouse. Sometimes it produces a warped particleboard shelf that collapses in six months, except the shelf in question is handling someone’s financial data. The difference between those outcomes is not creativity. It is whether the base unit’s actual tolerances were documented rather than assumed.
The Dengarden observation
Four hacks to make IKEA furniture look more expensive. I keep returning to that framing because it names a failure mode precisely.
The hacks in question are cosmetic — surface treatments, hardware swaps, finishing touches. They change perceived quality without changing structural quality. The piece still has the same particleboard core and the same load limits. It just reads differently.
A large share of agent demos are exactly this. Better prompt phrasing, more confident output formatting, a polished interface layer over the same underlying reasoning limits. The system reads as more capable. Its actual tolerances are unchanged. And unlike a bookcase, where you find out about the limits when the shelf sags, an agent’s structural failure often surfaces as a plausible, well-formatted wrong answer.
The distinction between cosmetic and structural modification is one the DIY community makes fluently and casually. They know which changes affect load-bearing and which affect appearance. We do not consistently make that distinction about our own systems, partly because we lack the vocabulary and partly because the cosmetic changes are the ones that demo well.
What to take from this
Three things transfer directly. Constrain your base units so others can reason about them. Document real tolerances, not intended use cases, because your users will build greenhouses. And be honest with yourself about which of your improvements are structural and which are hardware swaps.
The furniture people are not thinking about agents. They have just been doing composable systems design long enough, at consumer scale, to have developed instincts we are still arguing about in design documents.
🕒 Published: