AI is rapidly becoming another feature inside BIM software, with every major vendor racing to deliver increasingly capable assistants and copilots. Yet focusing solely on those features risks missing the bigger shift. Martyn Day explores why the future of AI in AEC could depend less on software vendors and more on firms turning decades of accumulated expertise into an asset they own, refine and control
I suspect most firms believe their ‘AI fixes’ will arrive in the next release of Revit, Rhino, Vectorworks or Archicad. Wait long enough, install the update, and intelligent design assistance will arrive as another feature of the software they already rent. Copilots will become more capable, repetitive tasks will disappear and productivity will steadily improve. It is an understandable assumption, but I think it is the wrong one.
The catalyst for this article is an opensource project from ALPA (AlpacaLabs LLC), the design technology consultancy led by Federico Negro. Called Skills for Architects, it is one of the clearest public demonstrations yet of how an architectural practice can package its knowledge into reusable AI workflows. On the surface it looks like a GitHub repository containing dozens of Claude Skills. Look a little deeper and it hints at something much bigger. It suggests the next competitive battleground in AEC AI will be who owns the intelligence that sits outside the BIM software, rather than who has the smartest features inside it. That represents quite a departure from how most firms currently think about AI.
Today, almost every conversation revolves around software vendors. Autodesk adds another assistant to Revit. Graphisoft extends AI inside Archicad. Bentley introduces another Copilot. Vendors compete on features because that is what software companies have always done. There is nothing wrong with that, and in fact it is inevitable. AI is becoming another capability expected inside professional software, much as rendering, clash detection and cloud collaboration became expected before it. Every major BIM platform will continue embedding more intelligence, and practices should absolutely take advantage of it. The mistake is assuming that this is the destination.
Discover what’s new in technology for architecture, engineering and construction — read the latest edition of AEC Magazine
👉 Subscribe FREE here
Part of the explanation is timing. Foundation models, agent frameworks, MCP servers, cloud APIs and structured data platforms are all maturing at roughly the same moment. Taken individually, each looks evolutionary. Taken together, they point towards a different software architecture for AEC, one in which the intelligence is no longer inseparable from the authoring application.
The more interesting question is where the real intellectual property sits once every vendor offers capable AI. If every practice has access to broadly similar language models, and every BIM platform ships its own assistants, where does competitive advantage come from? I think the answer comes down to judgement, the reasoning a practice wraps around whatever AI it uses.
That distinction is what makes ALPA’s repository interesting. There is more here than a collection of prompts or AI utilities. It demonstrates one possible way for a practice to begin capturing decades of knowledge and making it executable. Its specific implementation matters less than what it proves, which is that architectural expertise itself can become part of the software stack. That is a very different proposition from waiting for your software supplier to deliver another AI feature.
Automation versus judgement
The distinction worth drawing is between automation and judgement, because the industry continues to conflate the two. Automation is the repetitive execution of a known task. It is exactly the sort of thing software vendors can generalise across thousands of customers and ship as a product feature. Placing doors, laying out stairs to code, tagging rooms, generating schedules, running clash detection, producing specifications, these are all obvious candidates for AI assistance. They are common enough that every major BIM platform will eventually provide some version of them. Firms should embrace these capabilities, because they remove repetitive work, improve consistency and free architects to spend more time designing.
However, the most valuable knowledge inside an architectural practice has never been how to place a door or number a room. It is the accumulated judgement that determines why that door belongs there in the first place, how circulation should work, which adjacencies are non-negotiable, when building regulations should be interpreted conservatively and where experience says there is room for flexibility. That knowledge is rarely documented in one place. It exists in conversations around desks, technical reviews, office standards, project templates and lessons learned over hundreds of projects. Most importantly, it lives inside experienced people.
This is what Dustin Schafer, head of research at Henderson Engineers, describes as ‘the judgement stack’, the accumulated reasoning that makes one practice fundamentally different from another. It is also where competitive advantage now resides. Two firms may use exactly the same BIM software, the same AI model and the same hardware, yet produce very different buildings because they apply different judgement throughout the design process.
That is why skills matter. A skill takes a piece of that judgement and documents it, structures it and makes it executable. It captures how your practice performs a task, not how a software vendor thinks every practice should perform it.
Imagine a healthcare specialist that has spent twenty years refining operating theatre layouts and clinical circulation. Or a laboratory designer that understands containment strategies, servicing requirements and equipment adjacencies better than almost anyone else. Perhaps it is a workplace practice that has developed a unique methodology for translating client headcount, occupancy data and hybrid working policies into successful floorplates. None of that expertise appears on a software vendor’s roadmap because it is unique to the practice.
Historically, it has also been difficult to scale. Senior architects mentor younger staff, office standards evolve and templates accumulate, but much of the firm’s expertise remains tacit. AI changes that equation because, for the first time, practices have a practical mechanism for turning judgement into something reusable.
Vendor-supplied automation will continue improving because it must, since it represents the knowledge every customer has in common. The more valuable opportunity lies elsewhere, capturing the knowledge that only your practice possesses and making it available whenever it is needed.
This is why ALPA’s Skills for Architects repository deserves attention, because more than demonstrating another AI assistant, it shows that a firm’s expertise can itself become software. The obvious question then becomes, what exactly does that software look like?
Whether firms adopt ALPA’s implementation is beside the point. The significance lies in demonstrating that the intelligence shaping a project does not have to reside inside the BIM monolith. It can belong to the practice
What is an AI Skill?
ALPA deserves considerable credit because it has done something few organisations have been prepared to do. Where others talk about AI, ALPA has published a working reference architecture under an open licence. Anyone can inspect it, understand how it works, adapt it and build upon it. That makes ‘Skills for Architects’ one of the clearest public examples available for explaining what an “AI Skill” actually is.
The repository is a collection of reusable architectural knowledge organised into a modular system that firms can extend as their own expertise evolves. Strip away the AI terminology and what ALPA has really published is a framework for organising professional judgement.
At its simplest, a Skill is a reusable piece of professional judgement. Most are straightforward. They consist largely of carefully written instructions, supporting reference material and whatever contextual information is needed to complete the task successfully. Rather than asking a large language model to improvise, a Skill gives it boundaries, context and a defined objective.
The distinction is subtle but important. A prompt asks AI to perform a task. A Skill captures how a practice wants that task performed every time. That makes it repeatable, reviewable and, crucially, improvable.
The current ALPA repository contains thirty-nine individual Skills organised across the lifecycle of a project, from due diligence through to delivery. They cover everything from zoning analysis and occupancy calculations to parsing Environmental Product Declarations, generating specifications, researching materials and producing furniture schedules. Individually they are deliberately focused components, each solving one clearly defined problem.
That modularity is intentional. ALPA has avoided the temptation to build one monolithic architectural AI, adopting instead an approach familiar to software developers for decades. Small components perform individual tasks, making them easier to understand, test and improve. As new capabilities emerge, they can be added to the library without redesigning the entire system.
One of the more interesting aspects of the repository is that the intelligence remains readable. It is not buried inside thousands of lines of source code where only software developers can maintain it. Much of the knowledge is expressed in natural language that architects themselves can inspect, debate and refine. That changes the ownership equation. Instead of translating decades of professional experience into software through lengthy development projects, practitioners can participate directly in shaping the intelligence that represents their expertise.
Of course, Skills alone are only part of the architecture. Above the Skills sit the agents, the orchestration layer responsible for interpreting a broader request and deciding which Skills need to be called and in what sequence. If a Skill behaves like a specialist consultant, the agent acts more like an experienced project architect, deciding who to involve, coordinating the work and assembling the final output.
Supporting both are shared rule sets that establish consistent conventions across every Skill. These cover everything from terminology and units to citation standards and professional disclaimers. Event hooks provide another level of governance, automatically checking outputs before they are committed or passed further down the workflow, ensuring required information has not been omitted and obvious errors are identified early.
Individually, none of these concepts are new. Software engineers have long separated business logic, orchestration and validation into distinct layers. What ALPA has demonstrated is how those same principles can be applied to architectural practice itself.
This is perhaps the repository’s most important contribution. The architecture surrounding the Skills matters more than any individual Skill. Skills contain professional judgement. Agents coordinate workflows. Rules enforce consistency. Hooks provide governance. Each layer can evolve independently without forcing the entire system to be rebuilt.
That modularity is likely to matter more and more as practices move beyond a handful of experimental Skills towards hundreds of components spanning healthcare, laboratories, hotel, education, workplace and residential design. Very few firms are likely to build one AI that understands everything. Most will develop growing libraries of specialist expertise, organised by sector, geography, discipline or client, continuously refined as projects are completed.
The repository also illustrates something more fundamental. Architectural knowledge is becoming portable. Historically, expertise lived inside experienced people, office manuals, CAD standards and proprietary software. ALPA demonstrates that it can now exist as modular, version-controlled components that are readable, reusable and continuously improved. Firms can stop viewing knowledge management as a collection of documents and best practice guides and start treating it as a library of executable professional judgement that grows alongside the practice.
There is also an important distinction between creating ‘Skills’ and creating ‘AI’. ALPA is not attempting to build a new foundation model. Instead, it is building the layer above it, the professional knowledge, workflows and governance that make a general-purpose language model useful in architectural practice. As foundation models continue to improve, that knowledge layer only becomes more valuable, because it is portable in a way the underlying model is not.
Building the judgement stack
Does building those libraries require a team of software developers? Probably not. The move from experimenting with someone else’s Skills to building your own is far smaller than many practices imagine, and it is here that the strategic question changes. Building a Skill bears little resemblance to a traditional software project. The difficult part is rarely the programming. It is clearly articulating how the practice already works.
Every successful firm has accumulated hundreds, if not thousands, of repeatable decisions. Some are technical, others procedural, many are almost subconscious. They determine how projects begin, how planning policy is interpreted, how laboratory containment is organised, how specifications are assembled, how quality reviews are conducted and what checks happen before information leaves the office. They have evolved over years of projects, often refined through experience rather than documentation.
Traditionally that knowledge has been transferred through mentoring, office standards and repetition. AI offers another route. Instead of leaving expertise locked inside senior architects’ heads, practices can begin capturing it as structured, executable judgement.
The healthcare specialist encodes clinical adjacencies, infection control and operating theatre planning; the laboratory designer captures containment strategies and equipment servicing; the residential developer turns local planning policy and apartment mix into reusable logic. None of this requires inventing a new AI model. It requires documenting expertise the practice already possesses.
This is where ALPA’s repository becomes particularly useful. It is less a finished solution than a methodology. Its New York zoning Skills, for example, package local planning knowledge into a form that AI can consistently apply. There is nothing uniquely New York about the approach. The same pattern could equally describe London’s Green Belt policy, Scottish Building Standards, Part L compliance or healthcare guidance in Australia. Every practice already owns specialist knowledge. The challenge is making it reusable.
For larger multidisciplinary firms, the opportunity is substantial. In place of static office standards, they could gradually assemble libraries of Skills across every sector they work in, each one version controlled and refined as new projects are completed. The result is institutional knowledge that improves every time it is used. Unlike a static office manual, that knowledge compounds, because each completed project refines the library, and experience stops being merely stored and becomes easier to reuse.
This is where the idea of the ‘dumb’ BIM tool begins to make sense. The Skill needs nothing from Revit, Rhino or Archicad beyond geometry and metadata exposed in a form an external agent can understand, reason over and, critically, write back to. Intelligence begins migrating away from the authoring application and into a layer the practice owns.
That architectural shift is already becoming visible. Model data can now be extracted into open columnar formats such as Parquet for large scale querying. Geometry services, such as Rhino Compute, expose modelling operations remotely. MCP servers are emerging as a standard mechanism for AI agents to communicate with software and external services. The challenge is no longer whether AI can reason over BIM data. It is how cleanly that information can be accessed and how reliably changes can be written back.
Write back is arguably the harder problem. Reading a BIM model is relatively straightforward, but safely modifying it, while respecting constraints, relationships and the application’s own data model, is much harder. This is why the Open Design Alliance’s recent work on MCP servers is strategically significant. By exposing open, programmatic access to proprietary design formats, ODA is making it possible for firms to build AI workflows that are not tied to a single vendor’s ecosystem.
The challenge is no longer whether AI can reason over BIM data. It is how cleanly that information can be accessed and how reliably changes can be written back
This is also why interoperability suddenly becomes an AI problem as much as a BIM problem. For the last twenty years the industry has debated IFC, APIs, proprietary formats and open standards largely in terms of collaboration and file exchange. AI changes the conversation. If judgement is going to sit outside the authoring application, that judgement must be able to read information from any system, reason across it and write results back safely. Interoperability stops being a debate about moving files between applications and becomes the mechanism through which a firm’s own intelligence moves between them.
Solve legibility and write back, and the role of the BIM authoring tool begins to change. It remains where geometry is created and project information is coordinated, as those capabilities remain enormously valuable. With the Autodrawings movement, it’s possible that this process may be partially automated and external. Increasingly the BIM monolith becomes just one component in a much broader AI ecosystem, with the intelligence shaping the design sitting outside the application, encoded as Skills, orchestrated by agents and connected to the firm’s own institutional memory. This may prove to be the most important architectural change AI brings to BIM. For decades, software vendors have owned both the modelling environment and much of the intelligence surrounding it, and AI creates the possibility of separating the two.
Institutional memory and ownership
Once a practice starts externalising its judgement, another question naturally follows. Where does all of that knowledge live? A Skill is only as useful as the information it can reach. If it is expected to reason over previous projects, detail libraries, specifications, post occupancy reviews, planning submissions, RFIs and decades of accumulated experience, that information has to exist somewhere AI can access it. More importantly, it has to exist somewhere the practice controls.
This is why so many large firms are suddenly talking about data lakes, lakehouses and structured data platforms. The underlying technology is almost secondary. What practices are really building is institutional memory. For years, firms have invested heavily in BIM standards, document management systems and common data environments (CDEs), but those systems were designed primarily to store information and allow people to retrieve it. AI changes that requirement, because information now has to serve machine reasoning as well as human retrieval.
A practice whose knowledge remains scattered across disconnected project folders, PDFs, proprietary cloud services and BIM files can certainly use AI, but it will struggle to exploit its own experience. Every completed project contains thousands of design decisions, successful solutions, failed approaches and lessons learned. Unless that knowledge becomes accessible to AI, much of a firm’s intellectual capital remains effectively invisible. The ambition to build Skills and the ambition to build institutional memory are therefore not separate initiatives, they are part of the same strategy.
Once Skills begin querying that institutional memory, something much more interesting starts to happen. They move beyond following predefined instructions and begin reasoning over decades of precedent. A planning Skill can compare previous applications in similar boroughs. A specification Skill can identify products that have consistently performed well. A laboratory planning Skill can recall servicing strategies from earlier projects. AI starts behaving less like an assistant and more like an experienced colleague because it draws on the firm’s own experience instead of leaning on general knowledge alone.
Then there is the question of where the intelligence itself should run, given the practice has spent years codifying its judgement and assembling the knowledge that judgement depends upon. Today, most firms consume AI as a managed cloud service, which removes the burden of maintaining infrastructure, updating models and managing security. For many organisations that will remain the right answer for years to come, but it also creates a dependency because every time AI reasons over your projects, your standards or your institutional memory, it does so through somebody else’s platform.
This is not a theoretical concern. In conversations over recent months, I have heard the same position from numerous large practices, expressed in strikingly similar terms. Some firms are already opting not to store their project design files in vendor cloud environments for fear of losing control of their intellectual property, and would be even less willing to hand over client briefs or any AI Skills they might craft. Whatever today’s contracts say about model training, the caution runs deeper than legal language. These firms have concluded that their differentiating knowledge is too valuable to live inside another company’s platform, and it is difficult to argue they are wrong.
The industry usually describes this as vendor lock in. I increasingly think data toll is a more useful description because it better reflects the commercial reality. A toll implies somebody else owns the road, somebody else decides the price and somebody else controls access. The same principle applies when a practice’s own expertise is only accessible through another company’s AI platform. Having invested years capturing judgement into Skills and assembling institutional memory, the practice may find itself paying every time that knowledge is queried. Whether the charging model is tokens, API calls, usage-based licensing or the increasingly fashionable concept of outcome-based pricing, the effect is remarkably similar. Firms risk paying repeatedly to access intelligence they created themselves.
This does not mean every architectural practice should immediately train its own foundation model. Most will not and probably should not. Foundation models are improving at extraordinary speed and will remain the most economical option for many organisations. The opportunity lies in owning the layer above the model. Practices can own their Skills, orchestration, governance and institutional memory while fine tuning or specialising models using their own project history where appropriate. In other words, they own the intelligence architecture even if they never own the underlying model.
That distinction matters because foundation models will continue changing. Claude will improve, GPT will improve, Gemini will improve and the open-source models will become more capable. The underlying AI will become progressively more interchangeable, but the professional judgement wrapped around it will not. The Skills, governance, institutional memory and expertise developed by a practice are unique assets. They are far harder to replicate than another AI feature announced in the next software release, and they are ultimately what competitors cannot simply download.
The obvious objections
A prediction like this invites pushback, and the objections deserve serious answers, not a wave of the hand. The first is the most obvious. If Skills are so valuable, why would firms build them when Autodesk, Bentley, Graphisoft or Nemetschek will simply ship them? The vendors already own the modelling platform, the interface, the cloud infrastructure and the customer relationship, and they have every incentive to move up the stack. The answer follows from the earlier distinction between automation and judgement. A software company can only ship what generalises, and the moment it embeds one firm’s design philosophy, healthcare methodology or planning interpretation, it risks making the product wrong for thousands of other customers. Generic automation belongs inside the software, but competitive judgement, almost by definition, cannot. A related objection points to data. Autodesk hosts millions of Revit models and has surely accumulated more architectural knowledge than any individual practice. It has certainly accumulated more geometry. What it does not possess is the reasoning behind those models, the briefs, the constraints, the arguments in design reviews and the alternatives that were considered and rejected. The competitive asset is the thinking that produced the geometry.
The second objection is cultural. Architects design buildings, and most have no desire to become software companies maintaining AI systems, nor the resources to try. Surely only a Foster + Partners, a Perkins&Will, a Gensler or an Arup could afford this? The objection made perfect sense two years ago, but the barrier is falling quickly. ALPA’s repository is open source, Skills are largely plain text, and MCP has moved from experiment to standard. Writing a good Skill now looks more like drafting an office standard than commissioning an application, and the genuinely difficult part is not programming at all. It is persuading senior people to articulate how the practice actually works, which is a knowledge management problem architecture has faced for a century, not a new technical one.
If every practice has access to broadly similar language models, and every BIM platform ships its own assistants, where does competitive advantage come from?
The deepest objection is philosophical. Architecture is not chess, and much of what firms call judgement is intuition, taste, politics and client relationships built over a career. Can any of that genuinely be codified? The honest answer is that some of it cannot, and firms that attempt to encode taste will probably embarrass themselves. But a surprising amount of what practices describe as judgement turns out to be more structured than they admit. Planning interpretation, laboratory layout logic, healthcare guidance, quality assurance processes and specification decisions all follow reasoning that experienced people can explain when asked. Capturing even a modest fraction of that creates real leverage, not because it replaces the judgement that resists codification, but because it frees the people who hold it to spend their time where it actually matters.
Then there is the pragmatic objection, which is that most practices will build nothing and simply subscribe to whatever their vendor offers. That is almost certainly true, and it is not a criticism. Most practices do not write custom software today either, yet the minority that do, firms like HOK, ZHA, Buro Happold or Foster + Partners, consistently punch above their weight. Competitive advantage has never required universal adoption. It requires that some firms do something valuable that others do not, and if Skills do eventually get traded through marketplaces, the generic ones will commoditise while the ones built on a firm’s own project history, client relationships and design philosophy will remain precisely the things no marketplace can sell.
The final objection is the one I hear least often but find most interesting. What if the foundation models simply become good enough? If a future Claude or GPT can reason like a senior architect, perhaps the whole Skills layer becomes unnecessary scaffolding. I would argue the opposite conclusion follows. Foundation models supply general intelligence, but professional practice runs on context, this client, this risk appetite, this planning authority, this internal standard, this hard-won lesson from a project that went wrong. The better the general model becomes, the more those become the only remaining differentiators, because everyone else has access to the same general intelligence. Far from making practice-specific knowledge redundant, better models make it the entire game.
Conclusion
It would be a mistake to read this as an argument against Autodesk, Bentley, Graphisoft, McNeel or any other BIM or geometry vendor. They will continue delivering more capable AI, and practices should take advantage of it. The automation arriving inside authoring applications will remove repetitive work, improve consistency and become an expected part of every design platform. That is the first layer of AI, and it will become table stakes.
What ALPA has published is one of the first practical examples of what comes next. Instead of another assistant or copilot, Skills for Architects presents a reference architecture for capturing professional judgement as modular, reusable knowledge. Whether firms adopt ALPA’s implementation is beside the point. The significance lies in demonstrating that the intelligence shaping a project does not have to reside inside the BIM monolith. It can belong to the practice.
The third stage is only just beginning to emerge. As Skills become connected to institutional memory, practices move beyond automating individual tasks towards AI systems that can reason over their own projects, standards and experience. At that point competitive advantage comes from the professional judgement surrounding the model, since everyone has access to the same foundation models. Viewed in those terms, the industry’s direction starts to look different.
The first layer is vendor AI, generic capabilities delivered as product features that every customer will eventually receive.
The second layer is the judgement stack, the collection of Skills, workflows and governance that capture how an individual practice actually works.
The third layer is institutional memory, where those Skills begin reasoning over decades of projects, technical standards and lessons learned to create an AI system that reflects the firm’s own expertise. Each layer builds on the one before it, but each also becomes harder to copy.
Over the last three decades, architectural practices have invested enormous effort creating digital representations of buildings. The next decade may be defined by creating digital representations of themselves, not replacing architects, but preserving, refining and scaling the professional judgement that distinguishes one practice from another.
Perhaps that is the biggest lesson from ALPA’s work. The repository offers a glimpse of an alternative architecture for AI in AEC, one where the most valuable asset is not the language model or even the BIM platform, but the professional judgement a practice has accumulated over decades and can now begin to codify, improve and own.
The firms that build the greatest long term advantage are therefore unlikely to be those that wait for the next software update. They will embrace vendor AI where it makes sense, but they will also invest in capturing their own judgement, organising their institutional memory and building intelligence that reflects the way they work. In doing so, they will transform expertise that once existed only in the minds of experienced architects into an enduring asset that becomes more valuable with every project.
The last thirty years digitised buildings. The next decade may digitise the judgement that creates them.
Explainer: what is the Judgement Stack?
The judgement stack is the body of knowledge that captures how an individual practice actually designs buildings, and it is best understood as the middle of three layers that together determine how AI is used inside a firm. While much of the industry’s attention is focused on the AI features arriving in BIM software, those capabilities are only the first of those layers.
At the base sits vendor AI, the generic automation delivered by software companies. These are the copilots and assistants that place objects, generate schedules, produce specifications or automate repetitive modelling tasks. They improve productivity, but every customer of that platform ultimately receives similar capabilities.
Above that sits the judgement stack itself. This is the collection of Skills, workflows, rules and governance that captures how an individual practice designs buildings. It encodes the accumulated decisions that distinguish one firm from another, whether interpreting planning policy, laying out a laboratory, planning a hospital or applying internal quality standards. Unlike vendor AI, this knowledge is unique to the practice and becomes a long-term competitive asset.
The final layer is institutional memory. Here, Skills gain access to decades of projects, specifications, BIM models, post occupancy reviews, technical standards and lessons learned, so that AI reasons over the firm’s accumulated experience instead of performing isolated tasks.
Taken together, these three layers separate professional judgement from the authoring application itself. BIM software remains essential for modelling, coordination and documentation, but the intelligence guiding design moves outside the application, where it can evolve independently, operate across multiple platforms and remain under the firm’s control. In this model, AI stops being another software feature and becomes a digital representation of the practice’s own expertise.
