Where Will Your Firm’s Knowledge Live in an AI-Native Future?

Ask any design firm what makes it different, and the answer is rarely its software. Many firms rely on similar design tools. What sets one apart is how it designs: the standards it holds itself to, the way its architects and engineers solve recurring problems, the judgement its senior people bring to a difficult design or coordination issue at the end of a long week.

That identity lives in three places today.

The first is in what it has written down: its standards, workflows and templates. Drafting standards, BIM execution plans, modelling guidelines, QA checklists, model templates and family libraries. They capture the firm’s decisions about how work should be done, and most firms have invested years in them. But they only describe the work; it still takes people to apply them, and they are often out of date or inconsistently followed.

The second is in the heads of its people. Years of experience in how a façade detail should resolve, how to plan a classroom or a ward to the firm’s standard, how to route services through a congested ceiling, which details tend to fail, and when something that looks right is actually wrong. Much of it was never written down, and much of it couldn’t be.

The third is in the project models it has designed. Every completed project is a record of thousands of decisions: how systems were sized, how elements were configured, what was changed after review. A firm’s archive of past project models is a detailed history of how it actually works.

All three are valuable, and all three are hard to scale. As design becomes AI-native, each will play a new role.

As AI becomes available to everyone, simply having it won’t set a firm apart. What will is how well that AI embodies the firm’s own expertise, standards and design judgement.

What AI-native actually means

There’s an important difference between a firm that uses AI and a firm that is AI-native.

An AI-assisted firm adds tools to the way it already works. People still do most of the steps; AI helps with some of them.

An AI-native firm works the other way around. AI agents increasingly take responsibility for producing and coordinating design information, while design professionals define the intent, guide the process, validate outcomes, and remain accountable for the decisions that matter. The work shifts from producing information to making design and engineering decisions.

This is not just about higher productivity. It changes how projects are delivered: who does the work, how a firm scales, and where its value lies.

AI-native services

AI agents produce and coordinate design information. Professionals direct, validate and decide.

agents serve the services

AI agents

Collaborating agents, each doing one part of the workflow and handing it on.

AI models serve the agents

AI models

The foundation the agents run on: general, physical and specialised AI models.

• General
• Physical
• AEC-specialised

That shift raises a question every firm will have to answer: if AI is doing the work, how does it do the work your way?

How a firm’s knowledge becomes AI capability

We think the answer follows the same split as a firm’s knowledge.

A firm’s written standards and workflows are the starting point for its agents. Agents are the layer that turns general AI capability into finished design work, each doing one part of a workflow and handing it on to the next. Out of the box, an agent knows how the work is generally done. Given the firm’s standards, it applies them every time: naming conventions, view and sheet setups, modelling rules, the steps of a workflow. This is usually the fastest place to begin, because the knowledge already exists.

An agent is more than an AI model: it’s the AI model plus the software it works in, the standards and examples it follows, and the checks on what it produces. AI engineers call this the agent harness, and as powerful AI models become widely available, it becomes a major source of differentiation. Research on software-engineering agents has found that, with the same underlying AI model, the design of the agent’s tools and interface makes a large difference to how well it performs, alongside the choice of AI model itself.¹

The know-how of a firm’s people refines its agents. The most natural way to customise an agent isn’t to write long instructions. It’s to show it: here is how we did this, here is what good looks like. That’s how experienced professionals have always passed on their craft, and it’s increasingly how agents can learn too.² An architect might show an agent how the firm sets up its detail views on one project, then correct it where needed on the next.

This is easier to describe than to do. Following an example it has just been shown is one thing; remembering corrections from one project to the next, and generalising a workflow to new geometry, constraints and exceptions, are harder, and are where much of the current work in the field is focused. Showing an agent how one hospital room is documented doesn’t mean it will handle every room or every unusual case, which is why a professional’s review stays part of the process.

The experience embedded in past projects can inform both its agents and its AI models. A past project shows an agent how the firm actually modelled, detailed and documented similar work, the way a new team member learns from previous jobs. And years of completed project models contain patterns no one could write down as rules, such as what’s typical for a given building type or what tends to change after review, which AI models trained on that history can carry into every new project.

There is a catch: past projects are a record of what a firm has done, not always of what it considers good design. A completed model can contain compromises, mistakes, outdated standards and decisions that only made sense on that project. Learning from history means drawing on the projects the firm regards as its best work, and on review records that show what was changed and why.

Written downStandards, workflows and templates

set up

Agents

In people’s headsKnow-how and judgement

refines

Agents

In past projectsYears of completed project models

shows how it was done

Agents

trains

AI models

AI models make more accurate Agents

Agents and AI models: different tools for different jobs

Agents and specialised AI models are both ways of putting a firm’s knowledge to work, but they suit different jobs.

	Agents	Specialised AI models
Learn from	Standards, instructions and worked examples	Large amounts of consistent project data
Customised by	Domain experts	AI specialists
Time to adapt	Weeks	Months
Breadth	Many workflows on one general AI model	Usually one task, or a narrow family of tasks
Updating	Edit the standard or the example	Retrain the AI model
Best for	Getting value quickly across varied work	Narrow, high-volume tasks, and checking agents’ work

Putting knowledge into an agent is a different kind of task from putting it into an AI model.³ An agent takes knowledge in the form people already have it, and the people who do the work can start customising it themselves, often within weeks, without an AI team, large datasets or significant computing power. It also stays visible: when a standard changes, you update it and the agent changes with it. Recent research supports starting here: on the same AI model, improving the instructions it follows has outperformed retraining the model itself on most tasks tested.⁴

Specialised AI models earn their place on narrow, well-defined tasks. Small AI models trained to generate building layout code or CAD geometry have outperformed much larger general ones on exactly those tasks, but each was trained for a single task.⁵ Training one also needs a large amount of consistent, well-structured project data and the rights to use it, as well as specialist expertise, and what it learns can’t be read or edited directly. Many firms’ archives are not in that shape yet.

Where specialised AI models can help most is in making agents better. Agents running on general-purpose AI models can make subtle mistakes: misreading a schematic, choosing a value that is valid but implausible, or missing a problem an experienced reviewer would spot. Even the most advanced AI models still break basic physical constraints when reasoning about floor plans.⁶ An AI model that understands buildings should make fewer of those mistakes in every agent built on it,⁷ and can check the agents’ work: in one recent study, a small AI model trained to judge each step of a web agent improved its success rate, at a fraction of the cost of a general-purpose checker.⁸

So most firms will start with agents on existing AI models, and adopt specialised AI models later, often with partners, where a task is narrow and well defined, or to make their agents more accurate.

What agents look like in practice

A few examples, by discipline:

Discipline	Agent	Where judgement comes in
MEP	Clash resolution	Deciding which service moves, which way and how far, following the firm’s coordination priorities
MEP	CAD to BIM	Working out what each line, layer and annotation in a 2D drawing is meant to be in the 3D model
MEP	Schematic and model check	Understanding which schematic lines represent which systems, and which modelled elements they correspond to
Architecture	Spec and code compliance check	Working out which clauses apply to which parts of the model, and judging those open to interpretation
Architecture	Accessible bathroom design	Fitting fixtures, grab rails and clearances to accessibility requirements within the available space
Architecture	Family creation	Interpreting a product image or PDF, and building the family the way the firm builds its families
Architecture	Documentation	Deciding what to dimension and tag, and where, so views read clearly and follow the firm’s standards
Structure	Rebar modelling	Placing reinforcement from the engineer’s drawings so it works in practice, avoiding congested or clashing bars
Structure	Rebar detailing	Producing bar marks, bending schedules and details the way the firm and its fabricators expect

What these have in common is that none of them can be done with code alone. A family creation agent has to understand the image it is given; a clash resolution agent has to decide the best way to resolve each clash, not just detect it; a schematic check has to understand what the drawing means, not just what lines it contains. That judgement is what separates an agent from a script.

How is an agent different from an add-in or a command?

An add-in, a command or a Dynamo script follows fixed logic. It does the same thing every time, which makes it predictable and reliable for well-defined tasks, but handling situations that require interpreting unfamiliar information, or making decisions not explicitly covered by its logic, can be difficult, and changing it means changing its code.

An agent starts from a goal and works out the steps, so it can interpret less-structured information and make decisions without every case being explicitly programmed: a messy CAD drawing, for example, or a schematic drawn in a different style. That flexibility has a cost: an agent is less predictable than a script, which is why its work needs checking. In practice the two work together. Commands and add-ins become tools the agent uses, for the steps that should always be done the same way.

Script or add-inFollows fixed steps

Step 1 →Step 2 →Unexpected input →May require new logic

AgentWorks towards a goal

Goal →Plans →Unexpected input →Adapts →Checked →✓ Result

Tools it usesCommandsAdd-insChecks

How firms build their agents

It’s natural to assume building agents needs software engineers and AI scientists. With the right platform, it doesn’t. The best people to build agents are the domain experts: the architects, engineers, modellers, drafters and coordinators who already know how the work should be done, starting from base agents and refining them on real projects. That changes their role. Instead of producing every drawing and model themselves, they shape and direct the agents that handle much of the production, and spend more of their time on design, judgement and decisions. Their expertise doesn’t become less valuable; it becomes the thing that scales.

One more thing: trust

As AI produces more of the work, checking it becomes the hard part. Rules can catch some errors, but many real ones look correct on the surface: a door that meets every rule but swings into the clear space an accessible bathroom needs, a pipe run that steps from 100 mm to 150 mm and back again with every size valid, or a valve that clashes with nothing but sits where no one can reach it.

Recognising those takes judgement, and as agents become more autonomous, this validation layer becomes essential: agents generate, the work is checked, agents correct, and design professionals make the decisions that matter.

Research on AI reasoning supports this loop, with one important condition: it works when the check comes from outside the agent, such as rules, tests or a separate AI model acting as a checker, rather than from the agent judging its own work.⁹ In a recent benchmark of engineering design tasks, including structural design, the best AI model passed about a third of tasks at the first attempt, and almost 60% of a subset after ten rounds of feedback from automated checks.¹⁰ And trained verifiers, which score many candidate solutions and keep the best, have given smaller AI models gains comparable to much larger ones on maths problems.¹¹

1. 1GenerateAgents produce the design work
2. 2CheckRules and a specialised AI model flag likely errors
3. 3CorrectAgents fix what was flagged, and the work is checked again
4. 4DecideDesign professionals review and sign off

↺ check and correct until clean

What this means for firms today

None of this happens overnight, but the direction is clear, and a few things are worth doing now:

• Get your standards agent-ready. Your standards, templates and workflow documents are the quickest way to give agents your way of working. Make sure they are current, consistent, and written so they can be followed step by step.
• Treat your project archive as an asset. Your past project models are not old files; they are a record of how you work. Their consistency, the rights you hold over them, confidentiality and client permissions all matter, as does knowing which projects represent your best work and keeping the review records that show what was changed and why.
• Help your people’s expertise go further. The judgement of your senior people is your most valuable asset. Agents that learn from how they work let that expertise reach more projects, and support the next generation of designers.
• Start with agents. For most firms, customising agents is the faster path to value. Begin capturing your expertise in agents today, while building the data needed for specialised AI models later.
• Invest in validation early. The firms that can trust AI-generated work at scale will be the ones that can actually use it.

The real advantage is the loop, not the snapshot. Capturing a firm’s knowledge once is not enough: standards change, people learn, and every project brings new situations. The lasting advantage comes from a feedback loop in which every project’s corrections, reviews and decisions make the agents better, the checks sharper, and the next project’s work stronger. A firm that builds that loop keeps getting better; one that captures its knowledge once will find it going out of date.

Where we’re focused

At BIMLOGIQ, this is the problem we work on. Our platform, Argus, integrates with design software and lets design professionals automate workflows simply by describing what they need, starting from a growing library of specialised agents that firms can customise to their own standards. We’re also developing Design Lift, technology designed to help agents learn from examples of how work is performed, making it easier for domain experts to customise agents around their firm’s workflows and standards.

We believe the firms that thrive in an AI-native future won’t be the ones with the most AI tools. They’ll be the ones whose AI knows how they work, and keeps learning as they do.

Discover how BIMLOGIQ helps design teams turn their expertise into AI-powered workflows with Argus →

Footnotes

1. Yang et al., “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering,” NeurIPS 2024. arXiv:2405.15793. With the same model, a purpose-built interface for the agent clearly outperformed a plain command line. See also Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models,” ICLR 2023, arXiv:2210.03629, where letting a model look things up through tools, not only reason, cut down on made-up facts. More recently, Kapoor et al., “Holistic Agent Leaderboard: The Missing Infrastructure for AI Agent Evaluation,” ICLR 2026, arXiv:2510.11977, found in an evaluation of 21,730 agent runs that harnesses designed for the task outperformed a generalist harness using the same model in most comparisons (9 of 12 on CORE-Bench Hard, 11 of 12 on SWE-bench Verified Mini). The model still matters: Merrill et al., “Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces,” ICLR 2026, arXiv:2601.11868, found that changing the model usually made a bigger difference than changing the harness. ↩

2. Brown et al., “Language Models are Few-Shot Learners,” NeurIPS 2020. arXiv:2005.14165. Large models can take on new tasks from a few examples, without retraining. Zheng et al., “Synapse: Trajectory-as-Exemplar Prompting with Memory for Computer Control,” ICLR 2024, arXiv:2306.07863: agents prompted with complete step-by-step examples of similar tasks performed better on computer-control benchmarks, especially on long multi-step tasks. ↩

3. Gudibande et al., “The False Promise of Imitating Proprietary Language Models,” ICLR 2024. arXiv:2305.15717. Small models trained to imitate a stronger one copied its style but closed little of the capability gap outside the tasks they were trained on; the authors conclude that a stronger base model is the bigger lever. The picture is not one-sided: Liu et al., “Few-Shot Parameter-Efficient Fine-Tuning is Better and Cheaper than In-Context Learning,” NeurIPS 2022, arXiv:2205.05638, found that lightly fine-tuning a model about 16 times smaller could beat prompting a large one on specific tasks with a few dozen labelled examples. That is why we see agents as the first step, not the only one. ↩

4. Agrawal et al., “GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning,” ICLR 2026. arXiv:2507.19457. On a small open model (Qwen3 8B), rewriting its instructions based on reflection about what went wrong beat reinforcement-learning training of its weights on five of six tasks, by about 6 percentage points on average and up to about 20, using up to 35 times fewer attempts. ↩

5. Wei et al., “Text-to-Code Generation for Modular Building Layouts in Building Information Modeling,” NeurIPS 2025, arXiv:2509.23713: fine-tuned 7-billion-parameter models produced compilable layout code more reliably than GPT-4.1 from abstract instructions, and generating code against a building API gave more accurate layouts than generating coordinates directly. Yuan et al., “Clarify Before You Draw: Proactive Agents for Robust Text-to-CAD Generation,” ICML 2026, arXiv:2602.03045: two fine-tuned 7-billion-parameter models working together produced fewer invalid CAD models than Claude Sonnet 4.5 (0.9% vs 4.8%) and about 80% lower average geometric error. Both studies trained and evaluated their models on a single task. ↩

6. Rodionov et al., “FloorplanQA: A Benchmark for Spatial Reasoning in LLMs using Structured Representations,” ICML 2026. arXiv:2507.07644. Frontier models often violated physical constraints when reasoning about floor plans. Giving GPT-4.1 a Python tool raised distance accuracy from 56% to 99%, but its accuracy on planning tasks fell, from 25% to 12.5% on shortest paths. ↩

7. Lewkowycz et al., “Solving Quantitative Reasoning Problems with Language Models,” NeurIPS 2022. arXiv:2206.14858. Further training a general model (PaLM) on mathematical and scientific text gave state-of-the-art results at the time on maths and science benchmarks (MATH, GSM8K and the STEM subset of MMLU). Whether this carries over to building design is our extrapolation. ↩

8. Chae et al., “Web-Shepherd: Advancing PRMs for Reinforcing Web Agents,” NeurIPS 2025. arXiv:2505.15277. Used to choose each step of a GPT-4o-mini web agent on WebArena-lite, the 8-billion-parameter Web-Shepherd raised success from 23.6% to 34.6%, while GPT-4o-mini as the checker reached only 24.2%. The 3-billion-parameter version (+8.5 points) cost about a tenth as much to run as GPT-4o-mini. ↩

9. Huang et al., “Large Language Models Cannot Self-Correct Reasoning Yet,” ICLR 2024. arXiv:2310.01798. On reasoning benchmarks, models asked to review and correct their own answers without outside feedback did not improve, and often got worse. By contrast, Gou et al., “CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing,” ICLR 2024, arXiv:2305.11738, showed correction working when feedback came from tools such as search engines and code interpreters; and Shinn et al., “Reflexion: Language Agents with Verbal Reinforcement Learning,” NeurIPS 2023, arXiv:2303.11366, when a coding agent ran its code against tests and used the results. ↩

10. Guo et al., “Toward Engineering AGI: Benchmarking the Engineering Design Capabilities of LLMs,” NeurIPS 2025 (Datasets and Benchmarks Track). arXiv:2509.16204. Designs across nine engineering domains, including structural design, were checked by task-specific scripts, mostly simulation-based. The best model (o3) passed about 34% at the first attempt. On a 71-task subset, it reached almost 60% after ten rounds of feedback from those checks, though feedback did not help in every domain. ↩

11. Cobbe et al., “Training Verifiers to Solve Math Word Problems,” 2021 preprint, arXiv:2110.14168: on grade-school maths problems, ranking 100 generated solutions with a trained verifier gave about the same improvement as a 30-times larger model. Lightman et al., “Let’s Verify Step by Step,” ICLR 2024, arXiv:2305.20050: verifiers trained to judge each reasoning step outperformed those trained only on whether the final answer was correct. Snell et al., “Scaling LLM Test-Time Compute Optimally Can be More Effective than Scaling Parameters for Reasoning,” ICLR 2025, arXiv:2408.03314: on competition maths, spending extra computation at answer time, by searching with a step-level verifier or having the model revise its answers, could outperform a 14-times larger model on problems the smaller model could already partly solve; on the hardest problems, the larger model was better. These results come from maths, where answers can be checked automatically; applying them to design review is our extrapolation. The author’s own research builds on the same idea of generating many diverse candidates: Lamont, Walder, Dezfouli et al., “3D-Prover: Diversity Driven Theorem Proving With Determinantal Point Processes,” NeurIPS 2025, arXiv:2410.11133, which selects a diverse, high-quality subset of candidate proof steps; and Lamont, Walder, Montague, Dezfouli and Norrish, “Free Lunch for Pass@k? Low Cost Diverse Sampling for Diffusion Language Models,” NeurIPS 2026, to appear, arXiv:2603.04893, which makes sampled candidates more diverse. ↩