Not Every AI Tool Is an Agent. The Controls Still Matter.
- Ankit Singhai
- Jul 26
- 3 min read
The word “agent” is becoming a shortcut for almost every AI-enabled capability in AEC.
That is not just a language problem. It is a control problem.
A deterministic parametric tool, a prompt interface, an AI-built calculation utility, and an autonomous system do not create the same risk. When they receive the same label, teams can overestimate what a tool understands and underestimate what it can change.
Four different capabilities are being called agents
Campbell Yule’s analysis from NXT BLD separates the current market into four useful categories.
Parametric tool: defined inputs, inspectable logic, and a defined output—sometimes placed behind a conversational interface.
Prompt-based interface: natural language used to search, generate, or operate an existing capability.
AI-developed utility: software built more quickly with AI, such as a calculation engine or model-checking tool.
Autonomous system: a system that can plan, act, retain context, and apply knowledge across tasks or projects.
Why the category changes the control
A parametric tool may need engineering verification and version control. A prompt interface needs prompt and output records. An AI-built utility needs software testing and release gates. A more autonomous system adds access, action limits, monitoring, escalation, and rollback.
Calling all four an agent hides those differences.
A useful output once is not yet a company process
A prompt may produce an excellent door schedule, model query, specification draft, or coordination summary. The next question is more important: can the firm repeat the result under control?
Was the prompt or workflow saved?
Were the source files and tool version recorded?
Can another reviewer reproduce the output?
Are the acceptance criteria explicit?
Can the process be improved, approved, and eventually retired?
Without that loop, the result may be useful, but it is still an isolated output—not an organizational capability.
The minimum AI control record for AEC
Before an AI-enabled workflow becomes routine, the team should document a small but complete control record.
Purpose: the specific task the tool is allowed to perform.
Inputs: approved information sources and prohibited data.
Permissions: what the tool can read, create, change, submit, or send.
Validation: the technical and professional checks required.
Human owner: the person accountable for the final decision.
Audit trail: prompt, source, output, reviewer, date, and version.
Failure path: how the team stops, reverses, and reports a bad result.
Decisions that should remain visibly human
For current construction workflows, people should remain explicitly responsible for contractual and professional decisions.
Issuing RFIs and accepting design responses.
Approving submittals and substitutions.
Changing cost, schedule, or scope commitments.
Releasing calculations, drawings, or models for construction.
Sending contractual communications.
Accepting information that affects life safety, code compliance, or professional liability.
Questions to ask every vendor
What does the product mean by “agent” in operational terms?
What systems and project data can it access?
Can it take action without a human approval step?
What does it record, retain, or use for training?
Can an administrator limit permissions by project and role?
How are outputs validated, challenged, corrected, and exported?
What happens when the model, prompt, or software version changes?
The DDG perspective
AEC does not need inflated terminology to make useful technology sound valuable. A well-governed parametric tool or prompt interface can deliver significant value precisely because its limits are understood.
Start with the capability. Define the authority. Record the evidence. Keep a named person accountable for the decision. That is how firms gain the benefit of AI without trusting it beyond its tested function.
Read more practical AI and BIM governance insights from Detail Design Group
Comments