RFI and Submittal Workflow Automation in Construction Projects

RFI and submittal automation in construction fails for a reason most firms never examine: it is aimed at the wrong layer. The documents get created, logged, and stored, but the work that actually delays projects remains manual, unowned, and invisible to the systems meant to improve it.

Why RFI and submittal workflows break down before automation is even introduced

The failure begins with a structural confusion between two document types that serve fundamentally different purposes. An RFI is a question, a request for clarification that, left unanswered, leaves a design decision unresolved. A submittal is a review cycle, a request for approval of product data or shop drawings. When a contractor files an RFI where a submittal was required, no review cycle begins, and the project stalls waiting for an answer that doesn't move anything forward. When product data gets pushed through the submittal path while a design conflict sits underneath it, the team is effectively building on an assumption that may not hold. Neither mistake is rare, and both flow from treating the two document types as interchangeable paperwork rather than as distinct workflow triggers.

Even correctly filed documents stall at points no one has designed for. A question routed to the wrong consultant because the architect passed structural work to the engineer without notifying the team sits for days before anyone notices. A response arrives but never reaches the crew waiting on site, because the person who received it had no instruction to forward it. Work finishes, but the RFI stays open in the system for months because closing the loop was nobody's assigned task. Each of these is a small, quiet failure, and each one compounds the others.

The aggregate cost is substantial but largely invisible to the firms paying it. RFIs silently consume between one and three percent of total project cost, and the average response takes days rather than hours. That figure points to something more specific than document volume: it points to a coordination failure. The documents are not the bottleneck. The handoffs between the people responsible for them are.

What current platforms actually do — and where they stop

The dominant platforms in construction project management, Procore and Autodesk among them, are systems of record. They store information, log activity, and surface status to anyone who asks. Where is the latest drawing, which RFIs are still open, what is the submittal status: these are the questions a system of record answers well, and answering them has real value. But none of those answers advances a workflow one step without a human prompt. Knowing that an RFI is overdue does not chase the architect. Knowing that a submittal lacks an attachment does not catch the missing file before routing. Knowing that an RFI closed does not link that closure to the procurement or schedule task it affects.

The category has been remarkably consistent about where its responsibility ends. A system of record records. It does not act. Most firms that have invested in these platforms have therefore concluded, reasonably, that they have addressed their document management problem. What they have not addressed is the layer above it, the layer where the actual project delay occurs. The distinction matters because the two are routinely confused, and the confusion is expensive.

There are signals that the platform layer is beginning to push past record-keeping. Procore's Digital Coworker packages, made generally available in July 2026, include pre-built agents for Submittal Review and RFI workflows, with proposed actions staged for human review before any changes are made. Pelles, designed as an intelligence layer for MEP subcontractors, illustrates what the next tier looks like in practice: its GenAI generates proposals, RFIs, and submittal logs in the firm's own format, its DoubleCheck feature surfaces requirements before they become costly misses, and its Compare flags deltas the day addenda drop. These are actions on documents, not merely storage of them. But such capabilities remain the exception, and even where they exist, they operate within systems that still require deliberate configuration to connect an RFI closure to the downstream workflow it affects. Linking RFI closure to downstream tasks is the step most firms skip, and no current platform does it automatically without that configuration.

The automation layer most firms add — and why it replicates the same gap

What most firms add on top of their systems of record is automation, and it is almost always aimed at the same layer the platform already covers. The typical automation stack drafts an RFI from a field note, summarizes a long submittal thread, generates a compliance check against specifications. These are all document-layer interventions. None of them owns the routing decision. None of them escalates when a response goes overdue. None of them notifies a procurement sequence that a closed RFI has changed its timeline. The automation produces documents faster, and the documents then proceed to stall at exactly the same handoff points they stalled at before.

Smart routing and prioritization is often described as a real capability, and in a narrow sense it is. AI sorts, categorizes, and prioritizes incoming RFIs so the right person gets the right question. But routing without escalation logic is just a smarter inbox. When the right person does not respond, the smarter inbox does nothing about it. The accountability gap that creates most RFI delay remains untouched, because the system has no authority to enforce a response and no mechanism to escalate the failure.

The governance risk in automating consequential outputs without a verification gate is not hypothetical, and the clearest named example comes from outside construction but applies to it directly. In 2025, Deloitte Australia agreed to partially refund the Australian government after a report it produced was found to contain fabricated references, nonexistent academic papers, and a fabricated quote from a federal court judgment. A revised version disclosed that Azure OpenAI had been used. The failure was not the AI. The failure was the absent review gate, a process that allowed generated content to reach a client without a named person verifying it. The same logic applies to an AI-drafted RFI response issued under a professional seal: the technology is not the risk, the absence of a human checkpoint is.

The practical automation blueprint that actually addresses this problem identifies four distinct steps: intake, routing, draft responses, and SLA escalation. Most implementations stop after the first two. Intake gets automated, drafts get generated, and the routing and escalation layers, the layers where delay actually concentrates, remain manual. The result is a firm that has invested substantially in automation and has not moved its critical path by a day.

What process inconsistency does to any automation built on top of it

The deepest structural objection to RFI and submittal automation is not that the technology is immature. It is that the processes being automated are not consistent enough to automate. An AI agent can only replicate a stable pattern. When RFI routing varies by project manager, and submittal handling depends on who happens to be available that week, there is no stable pattern to replicate. Automating that inconsistency does not resolve it. It accelerates it, producing a faster version of the same failure.

The dual-tracking problem makes this concrete. If half a firm's RFIs live in email threads and the other half in the project management system, automation does not solve the split. It adds a third layer that attempts to reconcile two inconsistent sources of truth, and the result is faster confusion. An agent drawing from two incomplete repositories cannot know which one is current, and it will generate outputs that reflect whichever source it happened to query. The manual version of this problem at least has a person who knows, from memory, which thread is authoritative. The automated version has no such person.

Process maturity is therefore a precondition, not an outcome. Standardized routing, defined approval chains, and a single source of truth must exist before an AI-assisted workflow can function. This is the mechanism behind the broader finding that generative AI in construction drives consistency: templates and style guides ensure submissions align with the firm's voice and commercial terms across the entire team. But consistency tools presuppose a process that has already been standardized enough to template. Deploying them into a process that is not standardized produces templated chaos.

At enterprise scale, the governance failure mode is worse than inaction. Automating a process full of workarounds, redundant approvals, and unclear ownership makes it fail faster. The manual version has people who can catch exceptions mid-step, who notice when a routing decision looks wrong or an approval chain has a gap. The automated version runs past those exceptions, executing the flawed process at machine speed, and the failures accumulate before a human catches up. The technology is not the variable. The process is.

Where delay actually originates — the handoff points automation must cover

Delay in RFI and submittal workflows concentrates at a small number of handoff points: the moment a document leaves one party's inbox, the moment a response arrives but does not trigger a downstream action, and the moment a review cycle ends without a closed loop. Effective automation must be built around these points, not around document creation. The first handoff point is intake to routing. A document is received, and the routing decision is manual. An agent that classifies the RFI by type, urgency, project phase, and correct recipient, and routes it without human triage, compresses the first delay window, the one that occurs before any substantive work begins. Predictive RFI generation goes one step further: cross-referencing drawings, specifications, and historical project data to flag likely information gaps before they become formal RFIs shifts the workflow from reactive to proactive, addressing the question before it stalls a schedule.

The second handoff point is response monitoring and escalation. The document has been routed, the clock is running, and no human is watching. An agent that monitors timelines, sends follow-ups at defined intervals, and escalates when SLA thresholds are crossed covers the window where a significant share of all RFIs go unanswered. This is the accountability layer that smart routing alone cannot provide.

The third handoff point is closure to downstream notification. When an RFI response is issued, it may affect a submittal, a schedule activity, a material order, or a subcontract scope. An agent that links RFI closure to the relevant downstream workflow and notifies the affected parties closes the loop that most firms leave open. The most specific named evidence in the sources for why this link matters comes from Hut 8, whose material framed the downstream connection as the step that turns an isolated answer into an operational instruction. Without that connection, the information sits isolated, and the delay simply migrates to the next task.

The fourth handoff point is submittal pre-screening before architect or engineer review. A general contractor that routes subcontractor submittals directly to the architect without internal review loses the catch that prevents a Revise and Resubmit cycle. An agent that cross-references submitted materials against project specifications before routing adds the review gate that human coordinators skip under time pressure. The logic is the same one Pelles' DoubleCheck feature applies to bid review: surface requirements before they become costly misses. Applied to submittal pre-screening rather than bid review, it catches nonconforming submissions before they consume the design team's review capacity.

What process redesign must happen before agents are deployed

Deploying agents into an unredesigned RFI and submittal process does not accelerate the work. It accelerates the failure. The preconditions for effective automation are operational decisions, not software configurations, and they must be made before any agent is turned on.

The first precondition is a single source of truth. Dual-tracking across email and a project management system must be resolved before automation is introduced. An agent reconciling two inconsistent sources produces faster confusion, not faster resolution, and no routing logic can compensate for a split record.

The second precondition is standardized routing logic. Who receives which RFI type, under what conditions, with what response SLA, must be documented and consistently enforced before an agent can replicate it. Variation by project manager is not a configuration problem. It is a process problem that automation will not fix, and an agent trained on inconsistent routing decisions will simply reproduce the inconsistency at scale.

The third precondition is defined escalation authority. When a response goes overdue, someone must have authority to escalate, to a named recipient, through a defined channel. If this is unresolved in the manual process, the automated escalation will fire into a void, and the accountability gap will remain exactly as wide as it was before automation.

The fourth precondition is downstream linkage mapping. Before an agent can notify a procurement or schedule workflow when an RFI closes, someone must have mapped which RFIs affect which downstream tasks. This is analytical work, not software work, and it must precede the automation rather than follow it.

The fifth precondition is a human review gate for every consequential output. AI-drafted RFI responses, submittal compliance flags, and escalation notices all require a named person to verify before they are issued. The Deloitte Australia failure is the negative case: AI inserted into a high-accountability process without a strong verification gate produced fabricated references that the firm had to partially refund. The lesson applies directly to RFI responses issued under a professional seal, where the cost of an unverified output is not a refund but a construction defect.

The right starting point is not a platform strategy or a broad automation roadmap. It is a specific, painful step in the current workflow. A process audit that maps exactly how a workflow runs today and where it stalls is the precondition for deciding which handoff point to rebuild first. The practical entry sequence follows from that audit: identify the top document bottlenecks, pick one, configure automation around that step, measure the result, then expand. Firms that move this way set the operational benchmark. Those that deploy broad automation first debug it forever.