AI for Writing Construction RFIs

Every RFI that sits unanswered for a week is a design question nobody has resolved, and it usually means the programme is quietly slipping too. This guide is for PMs and site staff who want AI drafting RFIs to the right format and chasing the responses, without ever letting it decide what the answer should be. It comes from my walkthrough of building a Claude routine, the mechanism behind both the drafting and the tracking, in the video below.

Key takeaways

• Drafting a good RFI is mostly formatting: one question, referenced to the exact drawing and spec section, with the impact stated plainly. AI does this reliably from a plain description of the issue.
• Tracking is the harder discipline. A register only works if someone keeps it current, and a scheduled Claude routine does that update instead of relying on memory.
• The average RFI still costs around $1,080 to process and can take up to ten days to get answered, according to research cited by Procore, so anything that tightens the drafting and the chase is worth having.
• The trust boundary holds here like everywhere else in contract admin: AI drafts the question and surfaces the overdue response. It never decides what the engineer’s answer means.
• Build the routine manually first. Run the task yourself, get the output right, then convert it to a schedule.

What is AI-assisted RFI drafting?

AI-assisted RFI drafting is using a tool like Claude to turn a plain description of a design discrepancy into a formatted Request for Information: numbered, referenced to the drawing and spec section, one clear question, a suggested resolution and the impact if it goes unanswered. You describe the problem once; AI produces the document and logs it.

The reason this works is that a good RFI is a fixed shape. It needs a drawing or spec reference so the engineer isn’t hunting for context, a location, a single answerable question, and a statement of what happens if it doesn’t get resolved. That shape barely changes from project to project, which is exactly the kind of repeatable drafting AI is reliable at. Citing the right sheet is easier again once your drawing set is already indexed and searchable, the setup covered in AI for reading construction drawings. What changes RFI to RFI is the content, and that still comes from you: what you saw on site, which documents actually conflict, and why it matters.

The skill behind this, the one that assigns the next number, drafts to a standard template and writes the entry into the log automatically, is part of the ContractorOS community library, alongside the register it feeds. One description in, one formal RFI out, log updated. The judgment about what the discrepancy actually means stays with whoever wrote the description.

How do you draft an RFI with AI?

You describe the discrepancy once, what it is, where it is, which documents conflict, and what happens if it stays open, and AI turns that description into a numbered, referenced Request for Information that is ready for you to check before it sends. In practice this runs in five steps, from description to a logged register entry.

1. Describe the issue. What the discrepancy is, where it is (drawing number, grid reference, level or area), which documents conflict, and the impact if it isn’t resolved.
2. Assign the number. AI reads the register, finds the highest RFI number logged, and assigns the next one in sequence, so nothing gets skipped or accidentally duplicated.
3. Draft to the template. Drawing and spec references, a single clear question, a suggested resolution if you have a preferred approach, and a response-required-by date pulled from the contract’s notice period.
4. Review before anything sends. Nothing goes out until you’ve read it. AI drafts, you approve.
5. Log it as open. The register gets a new row: RFI number, date sent, subject, recipient, status, zero days open.

The most common mistake at step one is bundling more than one question into a single RFI. A drawing that doesn’t match the spec and a separate query about a fixture schedule are two RFIs, not one. Multi-part RFIs get partial answers, and you end up raising a second RFI anyway to close out the part that got missed.

What changes when AI handles the drafting and the tracking?

AI does the reading, the formatting, the numbering and the chasing. You still decide what to ask, what the engineer’s answer means, and whether it changes the drawings, the scope or the programme. None of the technical judgment moves.

RFI task	What AI does	What stays with you
Describing the issue	Nothing	Write what it is, where it is, and why it matters
Formatting the RFI	Drafts to the template with drawing and spec references	Reviews the wording, adds a suggested resolution
Numbering and logging	Assigns the next number, writes the register row	Confirms it before it sends
Chasing responses	Surfaces anything past its response-required-by date	Decides who to escalate to, and how hard
Reading the answer	Nothing	Confirms design intent, updates drawings or scope

That split matches how RFI drafting and response chasing sit on the workflow map for contract administration: rated GOOD, low blast radius. Low risk if something is slightly off, and easy to check before it goes anywhere, which is why it’s one of the first things worth automating in the contract admin stack. It’s a narrow slice of the wider workflow covered in AI for construction contract administration: departures registers, obligations, variations and EOT notices all run on the same read-draft-verify pattern. RFIs are just the smallest, most contained example, and one card in the broader AI for construction workflows map.

How do Claude routines keep an RFI register current?

A Claude routine is a task that runs on a schedule or a trigger instead of one you prompt by hand. Pointed at a project’s correspondence, it can sweep new emails daily, catch anything that reads like an RFI response, and update the register without anyone having to remember to do it.

“A Claude routine is simply a Claude code task that runs on its own, either triggered by an event or that runs on a schedule,” is how I put it in the video. The distinction that matters first is local versus remote. A routine on your own desktop only works while your computer is on, not much use for something checking your inbox every morning. A remote routine runs in the cloud instead, reading and writing to an online repository, GitHub is the free option I use, so it keeps running whether your laptop is open or not.

The build sequence is always the same. I set it up first with a simple example: an Airtable database of project performance, and a prompt asking Claude to pull that data into a weekly email summary. It rarely comes back right the first time. “This will take maybe five to 10 attempts,” and that’s expected, you’re teaching it the report you actually want. Once the output is right, Claude turns the process into a skill and saves it to the repository. Only then do you create the routine: new, remote, scheduled, run once manually to confirm it works before you let it run unattended.

Point that same mechanism at a correspondence register instead of a performance database, and you get RFI tracking. The routine runs daily instead of weekly, reads new correspondence, and surfaces anything that looks like an RFI response or anything sitting past its required-by date. A register only holds up if someone keeps it current, and the fix that works is logging correspondence in the channel people already use, email, and letting automation file it rather than depending on memory. I’ve shown this exact pattern before, an automated RFI register built off a project email address, every relevant email classified and filed so the open items stay visible. Most of what you’d assume needs a trigger runs just as well as a scheduled sweep on a shorter interval, and it’s simpler to set up and trust.

Common mistakes to watch for

• Bundling more than one question into a single RFI. Split them. One clear, answerable question per document.
• Letting a routine send anything without review. Draft and log automatically, approve manually, always.
• Skipping the manual run before scheduling it. Get the output right by hand a handful of times first; five to ten attempts is normal, not a sign something’s wrong.
• Running RFI tracking with no correspondence register underneath it. The routine can only sweep what’s actually being filed to a project inbox.
• Treating a response as settled without checking it. Confirm whether the answer changes the drawings, the scope or the programme before anyone downstream relies on it.
• Trusting a drawing or spec reference without checking the current revision. A citation to a superseded sheet is worse than no citation at all.

The full walkthrough of building that routine, from a plain-language prompt to a scheduled task running in the cloud, is in the video above.