Twelve days for a question

Here is the life of one Request for Information, reconstructed from a real project with the names filed off. Nothing about it is unusual. That is the point.

Day 1, Tuesday. A foreman on a mid-rise residential job notices that the mechanical drawings show a duct run passing through a beam that the structural drawings say cannot be penetrated. He flags it to the superintendent at the 6:30 huddle. The superintendent takes a photo, writes it up that evening, and sends it to the project engineer.

Day 2. The project engineer formats the question into an RFI, attaches the photo and both drawing sheets, logs it in the project management system, and submits it to the architect. The RFI is now number 214 on this job.

Day 5. The architect's office opens RFI 214. The project architect realizes this is really a structural question and forwards it to the structural engineer of record.

Day 8. The structural engineer's team reviews it. They have a solution, a web penetration with reinforcement, but they want to confirm the duct size hasn't changed since the last mechanical revision. They email the mechanical engineer.

Day 10. The mechanical engineer confirms the duct size. The structural engineer drafts the response and sketch.

Day 12, Saturday. The answer lands back in the project management system. Nobody reads it until Monday. Day 14, really.

Twelve days for a question that took every individual party less than an hour of actual work. If you added up the thinking time across all five people who touched RFI 214, you would get maybe ninety minutes. The other eleven days and twenty-two and a half hours were the question sitting in queues, waiting for someone to notice it, route it, or remember it.

What the crew did in the meantime

While RFI 214 aged, the framing crew reached that section of level three. The superintendent, not wanting to eat idle hours, resequenced them to level four. That worked, mostly, except the scaffolding plan assumed floors would finish in order, and the material hoist schedule had to be redone, and a plumbing rough-in inspection got orphaned because the inspector was booked against the original sequence.

None of this shows up in the RFI log. The log says 214 was answered in twelve days, which on many jobs would count as decent. The resequencing cost, the hoist reshuffle, the inspection rebooking fee, the superintendent's Tuesday evening spent redrawing the three-week lookahead: all of that gets absorbed into the general fog of "the job is hard." Coordination failures in construction are rarely catastrophic. They are a steady leak, a few hours here, a crew-day there, and the leak compounds across two hundred RFIs, four hundred submittals, and a thousand small questions that never get formalized at all.

The queue is the problem, not the people

It is tempting to read the story of RFI 214 as a story about slow architects or disorganized contractors. It isn't. Everyone in the chain responded within a normal professional window. The problem is structural: the question had to pass through five inboxes, and an inbox is a place where work waits for a human to have time.

This is where the interesting shift is happening, and it is happening quietly, on ordinary jobs, not in innovation-lab pilots. Some project teams have started running AI agents inside their project channels, and the first thing those agents changed was not the answering of questions but the waiting.

The pattern looks like this. An agent watches the RFI and submittal logs the way a very patient project engineer would. When RFI 214 sits unopened at the architect's office for three days, the agent doesn't wait for the weekly coordination meeting to surface it. It pings the architect's team directly, with the context attached. If the ping goes unanswered another two days, it escalates to the GC's project manager as a flagged item, not a buried row in a log report. On a few teams the routing itself is delegated: the architect's side runs its own agent, and the GC's agent hands the question to it, which recognizes the structural nature of the query and puts it in front of the structural engineer on day one instead of day five.

Meanwhile, the superintendent's morning got a new fixture. Instead of opening the PM system to reconstruct what is blocked, he gets a short summary posted into the project channel before the 6:30 huddle: which RFIs are aging, which submittals came back yesterday, which answers affect this week's work. When the answer to 214 landed on Saturday, an agent noticed that it touched the level three framing sequence and pinged the superintendent and the mechanical sub's PM directly, so Monday started with the answer rather than with the discovery of the answer.

And in the version of this story I find most telling, the GC's agent asked the mechanical sub's agent a follow-up nobody had thought to formalize: does the approved penetration detail change the sleeve order that went out last week? It did. The correction went out before the wrong sleeves shipped.

Ninety minutes of thinking, on demand

None of this makes the structural engineer think faster. The ninety minutes of real engineering in RFI 214 still takes ninety minutes. What collapses is everything around it: the routing, the waiting, the noticing, the remembering, the ripple management. Teams working this way report answer cycles measured in days shrinking toward measured in hours, and the honest ones will tell you the bigger win is what stopped happening. Fewer resequences. Fewer orphaned inspections. Fewer Tuesday evenings redrawing the lookahead.

Construction has spent twenty years buying software that stores questions better. Storage was never the constraint. The constraint was that every question needed a human to carry it to the next human, and humans carry things when they have time, and on a jobsite nobody has time.

RFI 214 was answered in twelve days. The next one like it, on a team set up this way, was answered before the foreman's coffee went cold. Same beam. Same duct. Same ninety minutes of engineering. Just nobody standing in a queue.