Agents with approvals: how we think about AI in the back office

There are two bad versions of AI in a construction back office.

The first is the chatbot that knows nothing. It writes a polite email and summarizes a PDF, but it has never seen your cost codes, your commitments or your pay app, so every answer starts with you pasting in context and ends with you checking its work against the system it can’t see.

The second is the autopilot. It codes invoices, posts entries and sends documents on its own, and you find out what it did at month end. In an industry where one wrong lien waiver or one overpaid sub can cost real money, that’s not a feature. It’s a liability.

We think the right model is older than software: an apprentice with a supervisor. The apprentice does the legwork, shows their work, and nothing goes out the door until someone with authority signs off. That’s how we’re designing agents in os.construction. This post lays out the rules.

Rule 1: Agents work on the real record

An agent is only as good as what it can see. If it works from an export, it’s working from a copy that was stale the moment it was made.

In os.construction, agents read the same data core as everyone else: the actual invoice, the actual purchase order and its remaining balance, the actual budget by cost code, the actual waiver status for every vendor. When an agent says “this invoice exceeds the remaining commitment”, it’s because it looked at the commitment, not a report about it.

Rule 2: Agents propose. People approve.

It helps to think in levels of autonomy:

That’s where we stop, by design. Every action that changes a record, moves money or leaves the company needs a human to approve it. An agent never posts on its own, and it never approves its own work.

Rule 3: Same permissions as the role

An agent that does AP work gets the permissions of an AP clerk, not an administrator. If your AP clerk can’t see payroll, neither can the AP agent. If your PM can approve change orders up to a threshold, the agent can draft them for that PM, but it can’t route around the threshold.

This sounds obvious, but it’s where a lot of AI tools cut corners: one service account with access to everything, because it’s easier. In a construction company, where segregation of duties is a real control, “easier” isn’t good enough.

Rule 4: Show the work

Every proposal comes with its receipts: which documents the agent read, which numbers it compared, what it concluded and how sure it is. An approver should be able to check an agent’s draft in a fraction of the time it would take to do the work, and that only happens if the reasoning is right there next to the draft.

Every action is then written to the audit trail with both names on it: proposed by the agent, approved by the person.

Rule 5: Your controls, not ours

You already have a delegation of authority, whether it’s written down or not. PMs approve some things, the controller approves others, and some things, like changing a vendor’s bank account, need two people. Agents should follow those rules exactly. They’re new hands in your process, not a new process.

Rule 6: Easy to undo, easy to turn off

Any agent can be paused per job, per workflow or company-wide. Drafts can be discarded without a trace in the ledger. And because approved work goes through the same posting rules as human work, it can be reversed the same way.

Three examples

These use our illustrative sample job, Riverside Medical Center (Job #24-118).

Coding an invoice that doesn’t fit

Volt Electric sends INV-4471 for $48,200 against PO-118. The agent codes the invoice lines to the electrical cost codes, matches it to the PO and notices the remaining commitment is $42,050, which leaves the invoice $6,150 over. It also notes that cost code 26 Electrical is already running about 4% over budget.

It doesn’t pay anything. It drafts two options for the PM: approve $42,050 and hold $6,150 pending a subcontract change order, or issue the change order now if the extra work was authorized. The PM picks one. That’s a ten-second decision instead of a twenty-minute investigation.

Chasing lien waivers before the pay app

Before Pay App #9 goes to the owner, the agent checks waiver status for every vendor paid in the last cycle. Two are missing: Apex Steel and CoreDry. It drafts the requests using the right waiver type (unconditional progress waivers for amounts already paid) on your templates, and flags the pay app checklist so nobody submits without them. A person reviews and sends. More on how waivers, retainage and pay apps fit together in this post.

Drafting a change order

When the design team answers RFI-212 and confirms that fire dampers need to be added, the agent drafts a change order from the RFI, attaches the mechanical sub’s quote and applies your markup rules. The PM reviews the pricing, adjusts what needs adjusting and sends it. Nothing reaches the owner without the PM.

What AI is still bad at

Honesty matters here. Language models can misread a scanned invoice, mix up two similar vendors, or sound confident about something that’s wrong. They’re not good at judgment calls on scope disputes, and they don’t know what was said on a jobsite walk unless someone wrote it down.

That’s exactly why the approval step isn’t a formality. The design assumes the agent will sometimes be wrong and makes it cheap for a person to catch. Over time, the useful measures are practical ones: how often approvers accept a draft unchanged, how long approvals take, and how many errors get caught before they post. We’ll measure those with founding contractors before we make any claims about them.

The short version

Agents do the work. You sign off. They work on your real data, with the same permissions as the person they’re helping, they show their work, and nothing posts, pays or sends without a human.

If you want a say in which back-office work agents take on first, get early access. Founding contractors decide the order.