The Agentic Design Landscape

This lesson maps the agentic tools a designer might reach for - but it does so on purpose as a map of kinds, not a list of products, and it is worth being clear why before we draw it. Agentic AI is moving extraordinarily fast. Any specific tool, model or feature named here is illustrative as of 2026 and may be renamed, merged, transformed or gone by the time you read it; new categories are appearing that did not exist when this was written. A course built on product names would be stale in a season. So we build on something more durable: the classes of agentic tool, defined by what they do, which change far more slowly than the logos that fill each class.

Thinking in classes gives you three things a shopping list cannot. First, orientation that lasts: when a new tool appears, you can place it - 'this is a general agent with computer use', 'this is a BIM-connected automation agent' - and immediately know roughly what it is for and what to watch out for, rather than starting from zero. Second, better choices: you evaluate a tool against what its class is supposed to do and how it fits your actual work, instead of being swayed by whichever demo is loudest this month. Third, immunity to hype cycles: understanding the categories lets you ignore most of the noise and pay attention only when something genuinely new to a class, or a genuinely new class, appears.

There is a deeper point here that runs through the whole course. The goal is not to know the tools; it is to know the work, and to fit tools to it. A designer clear about their own process - where the grind is, where judgement lives, what would actually help - can pick up whatever agentic tool is best this year and put it to work, and drop it for a better one next year, without losing their footing. A designer who chases products, by contrast, is forever learning interfaces and forever a step behind. So read the map that follows as a way to think about the ecosystem, not as recommendations to adopt - and hold every named example lightly, as an example of its class, to verify against the current state when you actually need it.

The first and broadest class is the general-purpose assistant that has become an agent - the direct descendant of the chatbot, now able to plan, use tools and do multi-step work. These are the tools most designers will meet first, and for many the most useful, because they are flexible, general and require no setup. Within the class it helps to see a few sub-kinds.

Conversational assistants with agentic abilities. The familiar chat assistants (the well-known large-model chat products, as of 2026) increasingly can search the web, read files you give them, run code, and carry out several steps toward a goal rather than answering one question. For a designer this is a genuinely capable research-and-drafting partner: hand it a goal like 'compile and compare these precedents' or 'turn this messy brief into a structured programme' and it will do multi-step work and report back. Because it is general, it fits an enormous range of design tasks - and because it is general, it knows nothing specific about your project unless you tell it, and can be confidently wrong, so its output is always a draft to verify.

Browser and computer-use agents. A newer sub-kind can operate software the way a person does - moving through a web browser or a computer screen, clicking, typing, filling forms - so it can carry out tasks across tools that have no tidy connection of their own. This is powerful for the tedious cross-application chores of practice (gathering data from portals, filling repetitive forms) and also the riskiest, because an agent acting on your screen can do real and hard-to-undo things; it belongs firmly at supervised autonomy.

Deep-research and long-task agents. Another sub-kind is tuned to run longer, multi-source investigations - reading widely, synthesising, and returning a structured report with citations. For the research-heavy front of design (precedents, products, context, code background) this can compress hours of gathering into minutes - with the same non-negotiable caveat that you check the sources and claims before relying on them, because a fluent, well-formatted report can be wrong.

The through-line for the whole class: general assistants-turned-agents are the versatile workhorses of agentic design - broad, fast, easy to start with, and knowing nothing of your specific project and duty of care, which remain yours to supply and to verify.

The second class is built for making and automating things, and although it grew up in software engineering, it matters to designers for two reasons: some of it is directly useful, and all of it is where the frontier of agentic capability is being pushed.

Coding agents. Agents that write, run and debug code have become strikingly capable, and their relevance to non-programmer designers is larger than it sounds. Much of the custom automation a studio wants - a script that renames and sorts a drawing set, a small tool that pulls quantities from a model, a routine that reformats data between two programs - is exactly what a coding agent can build, from a plain-language description, for someone who could not have written it by hand. This quietly lowers the barrier to bespoke tooling in a design practice, and Module 7 returns to it in depth. It also demands the sharpest verification of all, because code that looks right and runs can still be silently wrong.

Workflow and automation agents. A broad class of tools automates multi-step processes across applications - connecting services, moving and transforming information, triggering actions when something happens. Increasingly these carry agentic decision-making rather than only fixed rules. For a studio, this is the machinery of taming administrative and data-shuffling grind: intake, filing, notifications, routine coordination. The judgement required is about where an automated action has real consequences and therefore needs a human gate.

No-code and low-code agent builders. A growing class lets you assemble your own agents and automations with little or no programming - describing what you want, wiring tools together in a visual canvas, or configuring a template. This is how many designers will first build rather than merely use an agent - a custom research assistant, a specification helper, a studio intake bot - and Module 7.1 is devoted to it. The promise is real; the caution is that a tool built easily is still a tool you are responsible for, so what it does on consequential work must still be verified.

Across this class the pattern holds: automation and building agents extend a studio's reach into custom, bespoke help - and every gain in convenience raises, never lowers, the duty to verify the consequential output and to keep a human on the actions that matter.

The third class is the one designers most wish for and should watch most critically: agents built for design itself, and agents that connect to the design and BIM model. This is where the map is thinnest and moving fastest, so hold every example especially lightly.

Design-specific assistants and generative tools. A growing set of tools aims squarely at design tasks - generating layout or massing options from constraints, producing or restyling imagery, drafting specifications, helping with space planning - and they are becoming more agentic, taking a goal and producing worked options rather than a single output. These can genuinely accelerate exploration and production. The standing caution is that a tool trained to produce design-shaped output is not a designer: it has no judgement about what is good for this place and these people, no responsibility, and can produce plausible, non-compliant or simply poor results confidently. It proposes; you dispose.

BIM- and CAD-connected agents. The most consequential frontier for architects is agents that reach into the model - querying it ('how many doors of this type', 'where does this wall type occur'), automating modelling and documentation, checking the model against rules, extracting schedules and quantities. Some arrive as plugins to established BIM and CAD platforms; some connect through emerging open standards for linking agents to tools (Module 7.3). This is where agentic AI touches the real, binding output of practice - which makes it both the highest-value and the highest-stakes class, demanding supervised autonomy and rigorous verification as a matter of course.

How, then, should you engage with this whole landscape without chasing products? A few durable habits. Start from your work, not the tool - know where your grind and your judgement are, and look for a tool to fit a real need. Place any tool in its class before judging it, so you know what to expect and what to watch. Evaluate against your process, your data confidentiality, your budget and your verification burden, not against the demo. Adopt a few well, rather than many shallowly, and expect to change them as the field moves. And treat every tool, in every class, as an instrument of a practice whose judgement, responsibility and duty of care remain human - which is the one thing on this fast-moving map that will not change.