The AI Ascension Path: How AEC Firms Move From Prompts to Autonomous Agents

Most companies that say they’ve “tried AI” really mean they built something that answers questions well. Nobody on the call argued with that anymore — the argument was over what comes after it.

That was the throughline of our live Vitru AI Q&A on August 27, 2026 — open to anyone working in architecture, engineering, or construction, no pitch, just questions from people trying to work out what actually separates an AI agent from the AI tools they already use every day.

The conversation moved from what actually defines an agent, through the three stages a firm tends to pass through on the way to real autonomy, to a live troubleshooting session on why an AI system can end up drowning a reviewer in information instead of saving them time. Here’s what came out of it.

Why an assistant that only informs isn’t an agent

An agent, in the sense the term gets used on the platform, does three things: it perceives information from an environment — a Revit model, an inbox, a WhatsApp thread, a project management board — it applies some intelligence to that information, either a rule book or an AI model, and then it acts on what it finds by writing back into the system it’s watching. Send a message, flag an element, update a record. Skip that last step and the output is just information, however well-reasoned.

That distinction is where a lot of AI pilots quietly stall. An assistant that only informs is still limited by how much attention a human can give its output — and AI can produce far more analysis than a person can absorb at the same pace it’s generated. Give it the ability to act on what it finds, and the constraint moves from the human’s attention span to the quality of the rules it’s acting under.

There are two things that follow from building something that acts on its own. First, it has to run as a closed loop — perceive, decide, act, check again — without someone approving each individual step, or it isn’t really autonomous. Second, that doesn’t mean no human is involved. The concept, as it was put on the call, is that a human is on the loop, not in it: the person who set the agent’s policies, procedures, and tools up front is still the one who can look in on it, adjust its rules, and step back in if something looks wrong. What they’re not doing anymore is clicking confirm on every individual action, because that’s the whole point of building the thing in the first place.

The AI ascension path: three stages to autonomy

1. Master the tools already available. Before anything gets built, the first stage is getting genuinely good at the AI tools already sitting in front of a person — a plain chat window included. A prompt gives a predictable, repeatable output when it specifies the role the AI should take, the task itself, and the exact format the answer should come back in. From there, most AI chat tools let a person save that setup as a reusable custom assistant: describe what it should do once, upload the templates or reference files it needs as context, and it becomes something a firm can reach for every time that type of work comes up, instead of re-explaining it from a blank window.
2. Build assistants for specific AEC tasks. The next stage points that same idea at the tools a firm already runs on. An assistant connected to Revit that reads a model and drafts documentation out of it is a good example — reusable, task-specific, and still something a person invokes rather than something running on its own.
3. Go autonomous — a human on the loop, not in the loop. The last stage is the one that actually changes how a person’s week looks. An autonomous agent doesn’t wait to be invoked. A human supplies the strategies, policies, standard operating procedures, and tool access it needs once, up front — and from there the agent runs the loop itself, checking in on its own schedule or its own triggers rather than a person’s.

None of this was theoretical even a few years ago — the tools weren’t powerful enough yet to make it real. What’s changed is less about any single breakthrough and more about scale: the working context window a mainstream AI model can hold has grown roughly tenfold in the past year alone.

One coordinator, ten sub-agents, no information overload

One attendee already running agents inside a firm that works across both architecture and engineering raised the question that eventually catches up with every team experimenting with AI: what happens when an agent knows too much and hands you all of it? A QA/QC check against a large reference database can come back accurate and still be useless, because it’s answering with everything it found instead of exactly what’s relevant.

The fix is a pattern the flagship QA/QC agent already runs on: a coordinator agent that doesn’t try to check a model itself. Instead, it breaks a full sweep into ten or more sub-agents, one per discipline — site logistics, spatial programs, MEP and structural coordination, and so on. During setup, AI ingests a firm’s building codes and checklists once, splits the rule set by discipline, and hands each sub-agent only its own range of rules to work from. One sub-agent never sees the rules assigned to another.

Each sub-agent doesn’t re-derive a fresh opinion on every element it checks, either. It converts its assigned rules into a script once — a genuinely elaborate one, factoring in that every Revit model has its own formatting quirks and its own mix of what’s a stored parameter versus what has to be derived from geometry — and that script is what actually runs the sweep afterward. The AI’s job was writing the check once; running it hundreds of times is cheap and deterministic from there on. A system instruction on top of that governs exactly what the output should look like — specific table columns, a specific file format — so the report a person receives is scoped to what they asked for, not everything the system is capable of returning.

The same pattern shows up at two other levels of the platform. A reflective control loop pairs a task-assigning agent with an execution agent and adds an observer that evaluates the quality of what came back and amends both agents’ instructions over time, so the pairing gets sharper with use. And for anything that runs in defined stages rather than one flat pass, a layered, sequential primitive breaks the work into phases that run one after another — the same way a BPMN diagram lays out a process, branch by branch, gateway by gateway.

Find the highest-ROI place to point AI first

1. Map the process the way it actually runs. Sit down with the people doing the work and lay out a specific business process step by step — the branch decisions, the micro job description and the policies attached at each one, the way a BPMN diagram would. Done well, this becomes a common language between a firm’s functional departments and its IT side, instead of a document only one team can read.
2. Measure where the time actually goes. The gap between how long a task takes and how long it takes to get done is usually the real target. A task that’s 15 to 20 minutes of actual work can still take about a week to close out end to end, once it sits in a different team’s backlog waiting its turn. Lay that kind of delay over the process map — the same way a person would track any other operational cue — and it turns into a heat map of exactly where the flow is clogging.
3. Take the simplest, highest-ROI candidate first. Not every use case that looks impressive is the right one to build first. Score what’s on the map against how much ROI it delivers and how simple it is to implement, and prioritize whatever sits in the easiest, highest-value corner. Clear that one, then repeat the same process for the next.

Quick tips for moving up the AI ascension path

• Write the output format into the system instruction, not just the task. Telling an AI exactly what table, columns, or file format to return is what keeps a capable system from handing back more than anyone asked for.
• Convert a judgment call into a script once you can defend it. For anything with a real pass or fail answer, have AI derive the check, have a person review it, then let the script run the check going forward instead of re-judging it every time.
• Split large checks by discipline, not by size. A coordinator that hands each sub-agent one lane of the rule set stays accurate and fast even as the checklist grows.
• Measure wait time, not just work time, when you map a process. The bottleneck is usually the backlog a task sits in, not how long the work itself takes once someone picks it up.
• Match the model to the data, not the other way around. Enterprise contracts already exclude a firm’s data from training; a private, local deployment exists for firms that need to go further than that.

FAQ

What’s the actual difference between an AI assistant and an AI agent?

An assistant answers a question or produces information when you ask it to. An agent perceives information from a system on its own, decides what to do about it, and writes the result back into that system without someone invoking it each time — the acting part is what makes it an agent rather than a chat window.

Why does an AI agent sometimes hand back way more information than I need?

It usually means the system is searching everything it has access to and returning all of it, rather than being scoped to a specific slice of the problem. Splitting the work across sub-agents that each own one discipline or one rule range, and setting a system instruction that defines exactly what the output should look like, is what keeps the response scoped to what was actually asked.

Is our data safe if we use a commercial AI provider?

Enterprise accounts with major AI providers contractually guarantee your data isn’t used to train their models — a risk profile similar to the one most firms already accept using Microsoft or Google for email. Firms that need tighter control can run an open-source or local model on their own private cloud instead.

What does “human on the loop, not in the loop” mean in practice?

It means a person sets the policies, procedures, and tool access an agent needs up front, then supervises and can step in if something looks wrong — rather than approving every individual action the agent takes. The work shifts from doing each step to designing the system that runs the steps.

We haven’t automated anything yet. Where do we actually start?

Start by mapping a real workflow with the people who run it, not by shopping for tools. Overlay real operational data on that map to see where time is actually leaking, and that becomes the foundation both for picking a first use case and for the context an agent eventually needs to work from.

The takeaway

Nothing on the ascension path starts with a bigger model subscription. It starts with getting predictable output out of the tools already open on someone’s screen, then pointing that same discipline at the systems a firm actually runs on, and only then handing an agent the policies and access it needs to run the loop by itself. The firms that skip straight to the last stage are the ones that end up with an impressive demo and a reviewer buried in output nobody asked for.

Reserve your spot → Book a 1:1 →