A mid-sized general contractor running three concurrent projects agreed to let us watch one workflow closely: the RFI log on its largest job, a renovation with a design team that answered questions unevenly and a super who filed requests the moment they occurred to him. Nothing about the workflow was unusual. That is exactly why it made a useful test case.
The Log Before the Agent
RFIs went out by email, one at a time, addressed to whichever architect or engineer seemed most likely to answer fast. A project engineer kept a spreadsheet that was supposed to mirror every request and its status, but updating it meant remembering to do it after the email was already sent, so it lagged by a few days more often than not. Some RFIs got answered inline in a reply-all thread that never made it back to the spreadsheet at all. Two subcontractors were, for a stretch of nearly three weeks, working off different answers to the same question about a header detail, because the correction had gone out by email to one super and never reached the other.
The cost of this was not that the RFIs went unanswered. Most did get answered, eventually. The cost was that nobody, including the project engineer, could say with confidence which ones were still open on any given morning without opening the spreadsheet, cross-checking it against the inbox, and calling around. That reconciliation ate the better part of an hour most days, and it was the kind of hour that got skipped on the busiest ones, which were exactly the days something slipped.
What the Agent Actually Took Over
The agent we built reads the project inbox and the project's document platform directly. Every RFI that goes out, regardless of who sent it or how, gets logged the moment it is sent, with the question, the recipient, and a timestamp. When a reply comes back, whether it is a formal response through the platform or a two-line email answer, the agent matches it to the open request and closes it out, or flags it as partial if the reply does not actually resolve the question asked. Nothing depends on the project engineer remembering to update a second system, because there is no second system left to update.
The part that mattered more than the logging itself was the aging logic. Anything unanswered past a threshold set for that job, four business days on this one, triggers a nudge back to the design team and a note to the PM. On a Tuesday afternoon in week two, that nudge caught an RFI about a mechanical clearance that had quietly sat for six days because the engineer's reply had gone to an old project email address. The agent flagged the bounce, the PM called directly, and the answer came back that afternoon instead of whenever someone happened to notice the silence.
What Changed Once the Log Was the Single Copy
Once the log was the only copy, the shadow spreadsheet was gone. The project engineer checked one place for status, and it matched what the field actually knew, because the field was reading from the same log. Average time from RFI sent to RFI answered dropped from just under nine days to five, most of that gain coming from the requests that used to get lost between systems rather than from any single fast answer. The two-super, two-answers problem did not recur once the log itself became the single copy everyone read from. The project engineer estimated she got back hours every week, most of it from reconciliation work she no longer had to do at all, and the rest from disputes that simply stopped happening because both sides could point at the same record.
None of this required rebuilding how the contractor ran its jobs. It required picking the one workflow where a small daily failure was quietly expensive, and handing that one thing to something that would not forget to check it. That is a smaller ambition than most pitches for this kind of tool make, and it is also the reason this particular rollout stuck.