A year ago at NXT BLD, the conversation was about AI assisting the architect. This year, it was about agents.
The shift in vocabulary was striking. The shift in substance underneath the vocabulary was less so. By the second afternoon I had counted at least four distinct things being called agents, by different speakers, in different sessions, with no acknowledgement that they were not the same kind of object.
This post is an attempt to separate the things being called agents into the categories they actually belong in - partly to clear the air, and partly because the categories that don't deserve the word turn out to point at where the real value in this cycle is forming.
1. The parametric tool, dressed up
The most common thing I heard called an agent this year was, on inspection, a parametric tool. A defined input, a deterministic process, a defined output. Sometimes wrapped in a chat interface. Sometimes not.
There is nothing wrong with parametric tools. The AEC industry has had them for decades and they are some of the most useful software the industry has built. But calling one an agent makes it sound more capable than it is - and, more importantly, more opaque than it is. The parametric tool's value is precisely that its logic is inspectable. The architect can interrogate it, contest it, override it. Re-skinning it as an agent invites the user to treat it as a black box.
This matters because it inverts the relationship that makes the tool useful in the first place. The correct version is: we built a parametric tool that does X. That is a good thing. It does not need promoting to an agent to be interesting.
2. The prompt as interface
The second thing being called an agent is, more accurately, a prompt-driven interface to an existing capability.
Prompts have earned their place in some contexts. For architectural rendering, the prompt is genuinely the right interface - describing a desired image in language is far more accessible than configuring materials, textures, and lighting from a panel of controls. Rendering has become a tool more architects can actually use, and the prompt did that.
In some other contexts a prompt also out-performs the alternative. Searching a project model with a sentence is sometimes faster than building a filter expression. Drafting a first pass of a specification clause in language is sometimes faster than starting from a template.
But here is the gap I keep coming back to. When the prompt produces something useful for a common task, there is no clear way to capture the process and retrieve it for future use.
Take door schedules. Producing a door schedule from a prompt, formatted exactly the way the firm wants it to look, is impressive. The flexibility is real. But once that perfect schedule exists, how does the firm turn it into a reusable system? How does the prompt - the actual sequence of refinements that produced the good output - get versioned, governed, and re-applied to the next project? In most of what I saw, it doesn't. The next project starts from scratch.
This is the missing developmental loop. A prompt that produces a good output once is a demo. A prompt-derived process that the firm can re-run, audit, improve, and retire is a tool. The gap between those two states is where most "agentic" demonstrations currently sit, and almost nobody is talking about it.
3. The AI-developed tool, and the system around it
The third thing called an agent is where the actual value is forming - and where the word "agent" stops being the most useful description.
Richard Parker's a.engineer session was the clearest articulation of this I saw all week. The product is, in a real sense, a system for rapidly developing calculation engines, structural utilities, and analytical tools that would previously have required either deep in-house expertise or expensive external software. AI compresses the time-to-build dramatically. Tools that were uneconomical to develop two years ago are now a few days of work.
That is interesting on its own. But the part of Richard's talk that stayed with me was not the tools. It was the system built around them - verification, validation, the gating process before a new utility is released to the wider team. The same point ran through Al Fisher's Buro Happold session, and through several other Software Development Stage talks.
The same insight applies in different costume: as the cost of building the tool falls, the system around the tool matters more, not less. If anyone in your firm can spin up a calculation engine in an afternoon, the bottleneck shifts from building it to knowing it is correct, knowing who uses it, knowing when it is wrong, and knowing when and how to retire it.
This is not an agent in any meaningful sense. It is a small piece of well-specified software, with a verification process around it that makes it usable in a regulated profession. The progress is real, the language is wrong.
4. The system that learns across projects
The version of agent that the word would actually earn - and which I saw less of than I expected this year - is the one that accumulates knowledge across projects and applies it back to new ones, with its reasoning visible enough that the architect can interrogate and override it.
This is the shape Lira Nikolovska described in The Good Enough Intelligence two weeks ago. The capture-and-reuse loop I flagged in section 2 above is the same problem at smaller scale. The firm-level version is the same problem at larger scale.
The firms that solve it will not be the ones with the most agents. They will be the ones with the most legible institutional memory - the ones where the door schedule prompt becomes a sanctioned tool, the structural utility becomes a versioned asset, and the senior architect's design judgement becomes something the firm can teach a junior architect with, rather than something that walks out the door at retirement.
Giraffe - who were not at NXT BLD this year, but whose work I have spent time with recently - are one of the more interesting examples of this pattern actually being built. The same upstream-customisation-with-reuse instinct, applied to early-stage urban and site planning. More on that in a piece coming soon.