Michal Gryko, an architect and design technology specialist, posted a reflection on NXT BLD 2026 a week after the event. The whole comment is worth reading. The part I want to pull on is this:
Quite a few [tools] are marketed as next-gen BIM tools yet still plugging into existing deliverables and habits. The result is that models often continue to bounce between multiple tools and formats. For each approach we need to consider - are we genuinely rethinking how AEC workflows should operate in an agentic, data-first, multi-scale world, or just rebuilding the same patterns with more APIs and more complexity?
Michal is asking the question the industry has spent the last two years not answering directly. It is the same question Matt Gough was asking from the Lenovo Stage. It is the same question Martin Fischer of Stanford has been asking for forty years - spend $80 of every $100 rebuilding workflows, not extracting insight from old data, because most of your data is useless and was produced by yesterday's processes. Three different people, three different framings, the same underlying point. You cannot reinvent the construction operating system by making the existing system run faster.
I agree with Michal that we continue to "bounce between multiple tools." I think he is observing this accurately. What I want to add is a structural reason for it - one that is not really anyone's fault, and that explains why every BIM 2.0 player has converged on essentially the same compromise even though most of them started out wanting to do something more ambitious.
The Two Things Going On
Two things make the workflow reinvention everyone says they want extraordinarily hard.
The first is that adoption and change in AEC is slow. This is well documented and well understood. Architecture and engineering firms are conservative by professional disposition and by liability structure. The technology they bet a project on has to be already-proven, ideally already-used by a peer firm, ideally also supported by their insurer's risk framework. New tools earn their way in incrementally, over years, often through a small computational team using them as a side workflow before they become a sanctioned part of project delivery. Anyone who has tried to deploy a new authoring environment across a hundred-architect practice knows the timeline.
The second is that building a genuinely new BIM tool - not a thin layer on top of an existing one, but a properly new authoring environment with its own data model, geometry kernel, parametric system, federation logic, and standards interoperability - is an undertaking measured in many tens of millions of dollars and many years of engineering. Most of the BIM 2.0 challengers are now several years and several tens of millions into the work. They are well-funded, talented, and serious. They are also, depending on which corner of the problem they have picked, somewhere between 25 and 50 percent of the way to something that can carry a real project on its own without leaning on Revit alongside it.
Neither of these is surprising or scandalous. They are the conditions of the market. But together they produce the Catch-22 Michal is observing.
The Catch-22
To rebuild AEC workflows at the level Matt Gough, Martin Fischer, and Michal himself are pointing at, a BIM 2.0 player needs scale - adoption across enough firms and enough projects that the firm-level workflow shift becomes commercially viable and culturally normal.
To get to that scale, the BIM 2.0 player needs revenue, which means it needs customers, which means it needs to be usable inside the workflows those customers already run. That means producing artefacts that flow into Revit, or out to IFC, or alongside Bluebeam, or back to whoever the consultant's coordinator runs the federated model in. Models bouncing between tools is exactly the symptom of the constraint.
And once the BIM 2.0 player has built that interoperability layer - and built the sales motion around firms who buy it precisely because it slots into their existing process - the product strategy starts optimising for that integration. The interoperability becomes the moat. The workflow reinvention becomes the long-promised next phase, perpetually one funding round and one architectural release away.
The result is not bad faith. It is the only rational behaviour given the funding, runway, and market reality of the position. But it does produce, structurally, the outcome Michal is naming: tools marketed as next-gen, plugging into existing deliverables and habits.
The BIM 2.0 challengers, to their credit, have largely stopped using "Replacing Revit" as their pitch. The better version is closer to we are coming at the problem from a specific angle, in a specific phase, with a specific value-add to the existing chain, and over time we hope to broaden that angle until something more like reinvention is possible. That is a much harder story to fundraise on, but it is the true one.
Two Possible Exits
If the Catch-22 is structural, the exits are also structural. I can see two.
The first is the outsider exit. A company that does not see itself as an AEC software vendor, does not see itself as competing with Revit, and is not commercially dependent on slotting into AEC firms' existing workflows, has a freer hand to redesign those workflows. Giraffe is the clearest example I have written about - their public position is AEC is too small a frame, with developers, asset owners, capital managers, and governments as their primary buyers, AEC professionals second. From that position they can ask AEC firms to adapt to a new workflow rather than building a new tool that adapts to the existing one. It is a more defensible commercial posture for the kind of reinvention everyone says they want. I wrote about that pattern in Giraffe - The Right Direction?.
The second is the owner-pays exit. If the owner - who currently appears exactly once in most AEC software theses, as the party who funds the project - starts paying directly for the workflow shift, the BIM 2.0 player no longer needs to slot into the existing delivery chain to survive. The customer changes; the workflow can change with it. This is the thread I pulled on in The Missing Player. It is harder than it sounds, because owners are discontinuous customers and slow to organise. But it is the only path I can see where the workflow reinvention is funded by the party that bears the lifecycle cost of the existing one.
Neither exit is currently dominant. Most BIM 2.0 companies are not pursuing either. They are pursuing the rational AEC-vendor strategy of bolting in to get to scale. That is the structural reason the workflows continue to look the way they look.
What This Means for the Question
So the answer to Michal's question, as honestly as I can give it: the genuine rethinking of AEC workflows is unlikely to come from inside the BIM 2.0 cohort, however much any individual company there would like it to. The cohort is doing exactly what its funding model requires it to do, and that requirement is in tension with the workflow reinvention everyone is asking for.
The companies most likely to drive that reinvention are either non-AEC platforms that do not depend on AEC firms as primary customers, or AEC-adjacent products bought directly by owners and operators. The BIM 2.0 cohort will absorb the patterns that work once they have been demonstrated elsewhere. That is also a reasonable strategy. It is just not the one most of them are presenting in the marketing.
I do not think this is a depressing answer. It is a clarifying one. The Catch-22 is real, but it is escapable. The companies escaping it are mostly the ones not pretending to be inside it.