Submittal and RFI chase, run by an agent

It's Tuesday in the site trailer and procurement is asking for a release date. The superintendent opens the submittal log expecting green — and finds the racking approval still sitting with the engineer, three weeks in, with the delivery window closing behind it.

The problem

Every project runs on approvals nobody can see. The racking submittal is with the engineer, the module datasheet went to the owner two weeks ago, and the RFI on the roof attachment detail is sitting in someone's inbox. None of it blocks work today. All of it blocks work the week the material is supposed to land.

The superintendent finds out the way it always happens: procurement asks for a release, somebody checks the log, and an approval that was "basically done" turns out to have never moved. Now the schedule, the delivery, and the lookahead all bend around a piece of paper. Keeping the log current by hand means a weekly pass through email, the platform, and memory — the first work skipped on a busy week, and a skipped week is when things go stale.

How the agent workflow works

The agent maintains one submittal and RFI register and works it on a schedule, twice a week.

What it reads:

• The submittal log and RFI log, in whatever platform or spreadsheet the project already uses.
• The project email, for approvals, comments, and "approved as noted" replies that never got logged.
• The schedule and open orders, so it knows each item's need-by date — the date the answer stops being paperwork and starts being a delay.

What it produces: A chase list sorted by need-by date, not submission date. Each item shows who owes the response, how long they've had it, and what it blocks. Past its follow-up threshold, the agent drafts the nudge — a short email naming the item, when it was submitted, and when it's needed — ready for the superintendent or PM to send. Nothing sends automatically.

Where the human checks it: The superintendent reviews the list and the drafts. He knows which engineer answers faster by phone, which reviewer is on vacation, and which item the PM is already handling. The agent tracks and drafts; the human decides how each chase goes out.

What you need to set it up

• One register that is the source of truth. If submittals live in two platforms and a spreadsheet, the agent will faithfully maintain the confusion. Consolidate first.
• Read access for the agent to the register and the project email, so unlogged replies get caught. Cost is honest and small: this runs on the AI assistant and project platform you already pay for — the spend is setup time, not a new tool.
• Need-by dates tied to the schedule. A chase list without need-by dates is just nagging in order of age.
• Your follow-up thresholds written down: how many days before the first nudge, and when it escalates from the superintendent to the PM.
• A few examples of your nudge emails, so the drafts sound like your project and not a collections department.

Setup is a few hours, mostly cleaning the register and attaching need-by dates. Expect the first lists to surface old items everyone assumed were closed. That is the point.

Where it breaks

Garbage register, gospel output. If an approval came back verbally in a meeting and nobody logged it, the agent will keep chasing a closed item — politely, specifically, and wrong. Somebody still has to close items the old way: by writing it down.

Need-by dates move. When the schedule slips, an item that was urgent becomes routine and a routine one becomes critical. If the schedule the agent reads is last month's, the priorities it computes are last month's too.

It can't read leverage. Some reviewers respond to a nudge; some respond to a call from the PM; one responds only when the owner's rep asks. The agent drafts the same reasonable email for all of them. The human still picks the channel.

Email tone drift. A generated nudge can read sharper than intended, especially on the third follow-up. Read every draft before it goes. A burnt reviewer costs more than a late submittal.

The bottom line

This turns the submittal log from a record of what happened into a list of what happens next: the agent watches dates so a stalled approval surfaces weeks early, not at procurement time. Trial it on one project for a month — if the list catches one item that would have surfaced late, it has paid for its setup. If it mostly nags about items already handled off the books, the register, not the agent, is what needs fixing.

Related use cases

• Three-way match on every delivery Materials
• Long-lead gear tracker Materials
• A gate on every material order before it goes out Materials