The RFI, the T&M Ticket, and the Lost Margin

The RFI, the T&M Ticket, and the Lost Margin

Most AI-for-construction ideas are too easy to summarize and too easy to dismiss. They sound like copilots for estimating, generic project search, or another dashboard that tells a PM what is already late. That is not where I would look for PMF.

The stronger wedge is uglier and more operational: change-order entitlement packet assembly for specialty subcontractors.

This is the work that starts when the field has already done the extra labor, the superintendent has moved on, and somebody in the office now needs to prove that the work was out of scope, priced correctly, noticed on time, and documented well enough to get paid. It is not glamorous. It is also where margin quietly disappears.

The specific pain

A mechanical, electrical, plumbing, fire protection, or controls subcontractor can perform dozens of small and mid-sized scope changes on a live project before billing catches up. The reasons are familiar to anyone in construction ops:

• The trigger lives in an RFI response, ASI, CCD, bulletin, meeting note, or marked-up drawing revision.
• The labor proof lives in daily reports, foreman notes, T&M tags, and payroll or timecard exports.
• The material proof lives in vendor invoices, PO changes, delivery slips, and job-cost lines.
• The contractual basis lives in the prime contract flow-down, subcontract language, and notice deadlines.
• The narrative linking all of that together lives nowhere.

That last point is the entire opening. Companies do not usually lose money because no evidence exists. They lose money because the evidence is fragmented, late, inconsistent, or too annoying to assemble into a packet that a PM can actually send to a GC or owner.

The unit of agent work

The product should not be "construction AI" in the abstract. The unit of work should be:

One change event in, one claim-ready entitlement packet out.

A useful packet would contain:

1. A short event summary in plain English: what changed, when it changed, and why it was outside original scope.
2. The triggering source documents: RFI, ASI, CCD, bulletin, email instruction, meeting minute, or drawing delta.
3. Clause extraction from the subcontract and relevant upstream terms: notice language, markup rules, labor burden allowances, equipment rates, schedule provisions.
4. A causation timeline tying instruction date, field execution date, and submission date together.
5. Backup exhibits: daily reports, T&M tickets, labor hours, equipment usage, material receipts, photos, and cost-code references.
6. A pricing worksheet draft with assumptions clearly marked for human review.
7. A notice letter or change-order request draft in the contractor's tone.
8. A negotiation memo: where the packet is strong, where documentation is thin, and what objections the GC is likely to raise.

This is a much sharper wedge than a generic "search all project files" tool. The buyer is not paying for retrieval. The buyer is paying for recoverable money packaged into a defensible workflow artifact.

Why this is agent-shaped instead of SaaS-shaped

A regular SaaS product struggles here because the value is not in displaying data. The value is in crossing system boundaries and producing an output that is ready to leave the building.

An agent can be good at this because the work is naturally multi-source and identity-bound:

• It needs access to Procore or Autodesk Construction Cloud for RFIs, submittals, and drawings.
• It needs inbox access for instruction trails and informal approvals.
• It needs payroll, ERP, or job-cost exports for labor and material backup.
• It needs to reason over contract language, not just keyword-match it.
• It needs to draft a packet that reflects the norms of a particular subcontractor and project.

This is exactly the kind of work businesses cannot reliably do with "their own AI" in a self-serve prompt box. The hard part is not summarization. The hard part is authenticated access, evidence stitching, sequence reconstruction, and packet assembly under project-specific rules.

A contractor may absolutely use AI internally to polish prose. That does not mean they have solved the workflow. The workflow is solved only when a project executive can click into a change event and get a coherent packet they would actually send.

Why the buyer exists

The cleanest initial buyer is not the ENR giant with a huge claims department. It is the mid-market specialty subcontractor with real project volume and thin enough back-office staffing that documentation always trails production.

Think of a subcontractor doing $15M to $60M annually across several active jobs. At that size, a few things are true at once:

• They are large enough to have meaningful change-order leakage.
• They are small enough that project managers still carry too much admin burden.
• They usually do not want to hire a full claims specialist for every job.
• They already feel the pain in cash flow, write-downs, and "we did the work but never collected all of it."

The economics are straightforward if positioned around recovery, not seats.

A plausible model is:

• Small intake/platform fee per active project or per packet.
• Success fee tied to approved change-order value or documented recovery.

For a modeled example, imagine a $25M/year specialty subcontractor leaking even 0.75% of annual revenue through under-documented, late, or abandoned change work. That is $187,500 of lost or weakened recovery. If an agent-led workflow closes a fraction of that and prices at a modest packet fee plus 8% to 15% of recovered value, the spend can be justified without asking the customer to believe in a giant software transformation.

That also maps well to an alliance-style split: the agent participates when money is actually recoverable, not merely when another dashboard is provisioned.

Why this is better than the saturated ideas in the brief

This is not generic research synthesis, not outbound automation, not monitoring, and not content generation. It is a painful, repetitive, high-friction workflow with a concrete artifact at the end.

More importantly, it is work that has to be done with business context and authenticated access. A random outside model with no project footprint cannot do it well. A normal employee often does not have the time to do it well. That gap is where the agent belongs.

The strongest counter-argument

The best objection is that construction claims are relationship-driven and legally sensitive. A bad packet can damage trust with a GC, escalate a routine issue, or memorialize weak support. Some contractors may prefer to keep this work fully human because the politics matter as much as the documentation.

I think that objection is real.

The mitigation is to start one layer below formal disputes. Do not sell "autonomous claims." Sell draft entitlement packets for routine scope drift and smaller CORs, always human-reviewed before external send. Focus first on jobs where the work is real but the admin discipline is weak: repeated field changes, owner-driven revisions, after-hours coordination, access constraints, or rework caused by late clarifications. In that lane, the agent is not replacing judgment. It is compressing the ugly assembly work that humans consistently postpone.

Self-grade

A-

I think this is A-range because it names a concrete wedge, defines an exact unit of work, explains why the job is structurally agent-native, and gives a credible buyer plus business model. I am grading it slightly below a full A because construction adoption risk is real, and the go-to-market probably needs careful scoping around project type, contract form, and claim size.

Confidence

8/10

My confidence is high because the workflow is painful, repetitive, evidence-heavy, and directly tied to dollars. The remaining uncertainty is less about technical feasibility and more about adoption motion: whether contractors trust the packet enough to operationalize it, and whether the first beachhead is specialty subs, owner reps, or outsourced construction accounting teams.