An HVAC Owner Is Building His Own AI Foreman

An HVAC owner is trying something that sounds like it belongs five years from now. He has a personal AI assistant, he has given it a separate long-term memory, and he wants to connect that assistant to the jobs, schedules, invoices, reminders and customer history inside his business.

There is an important gap in this story, and it is the most useful part of it.

Component	Status
The AI assistant	Running
A separate long-term memory	Running
Connection to the live business	Does not exist yet
Proven across the full cycle	No — still being planned

So this is not a report on a working AI foreman. It is a look at an architecture somebody is attempting, why the idea is more realistic than it was two years ago, and the three things that will decide whether it becomes an operating model or just another tool to babysit.

Why an owner reaches for this

The operator in question understands the fieldwork. His problem was never answering the phone faster or writing a better email.

A single owner may be the technician, dispatcher, estimator, service manager and office administrator at once. That means the business runs on hundreds of small details that live inside one person’s head:

• one customer prefers a particular arrival window
• a boiler has an unusual service history
• a job looks open on the calendar but is actually waiting for a part

Individually trivial. Together they decide whether the day works. And none of it is written down anywhere a computer can read.

Rather than wait for a perfect trade-specific assistant, he started with a consumer AI and built a memory layer around it, so the assistant could hold context instead of treating every conversation as the first.

That is the first lesson here. AI is good in the moment and much weaker when the context is scattered across conversations, customer records, calendars, invoices and the owner’s recollection.

But memory is not the same as current

Here is where the naive version of this breaks.

Long-term memory solves forgetfulness and introduces a worse problem: memory is not necessarily true any more.

• The AI may remember that a customer prefers Friday mornings — and that customer changed the request yesterday.
• It may remember an invoice as unpaid — and the payment landed this morning.
• It may remember an old service note — after a technician already replaced the equipment.

An assistant that treats its memory as the record will be confidently wrong, which is worse than being ignorant. So the memory cannot be allowed to become the business record.

That constraint is what produces the three-layer shape.

The three layers

Layer	What it is	What it holds
1	The field service platform	Current operational facts: customers, jobs, visits, schedules, estimates, invoices, payments
2	A separate memory system	Longer-term preferences, operating rules, useful history — the context that normally stays in the owner’s head
3	The AI assistant	Talks to the owner, checks the other two, explains what needs attention, prepares the next action

Layer 1 is the current facts. Layer 2 is the brain and rulebook. Layer 3 does the reading, explaining and preparing — and nothing else.

The separation is the design, not an implementation detail. Collapse memory into the record and you get an assistant that overwrites reality with recollection. Collapse authority into the assistant and you get an employee you have to supervise every second.

What makes this newly possible — and what doesn’t

Three things have changed to make this more than a thought experiment:

• APIs. Modern field service platforms can expose data programmatically.
• Webhooks. They can report supported events as they happen, so the assistant is not permanently re-reading everything.
• MCP. The Model Context Protocol is, in its own words, “an open-source standard for connecting AI applications to external systems” — the project’s own analogy is a USB-C port for AI applications.

One precision matters here, because it changes what you have to build yourself. MCP standardises the connection, not the authorisation. It makes it straightforward for an assistant to reach a tool; it does not decide what that assistant is allowed to do once connected. The approval model is the host application’s responsibility — which means the permission ladder below is something you still have to insist on, not something the standard hands you.

Building blocks are not an AI employee. They make the connection technically possible, and that is all. The workflow in this story was still being planned: the assistant and its memory were running, but nothing had yet been proven across the full cycle of reading current records, taking approved actions, handling failures and confirming results.

That is precisely the difference between an interesting experiment and a system you can run a business on.

The three tests that decide it

1. Permissions

Reading tomorrow’s schedule is low risk. Moving a locked appointment, changing a price, refunding a payment or promising an emergency arrival is not remotely the same thing.

A real AI foreman needs an explicit ladder:

Tier	Examples
May read	Today’s schedule, job history, invoice status, maintenance due
May prepare	A draft message, a suggested reschedule, a proposed action list
Must be approved	Anything customer-facing, financial, or hard to reverse

If a tool cannot express that boundary, it is not ready for the job.

2. Fresh data wins

When the AI’s memory disagrees with the current job record, the operational record has to win. Memory can supply context — “this customer has asked for early slots before” — but it must never quietly override what the business knows right now.

This is the same failure we described in our AI dispatch analysis: software that acts on stale assumptions repeats them efficiently across the whole operation.

3. Failure behaviour

What happens when the assistant cannot reach the calendar? When a job was changed by hand? When an event never arrives? When the owner gives a half-finished instruction standing next to a running condenser?

The safe response is not to guess. It should stop, say what it could not confirm, and hand the decision back to a person. An assistant that guesses under uncertainty is not saving anybody time — it is generating work that surfaces later, usually in front of a customer.

What the useful version looks like

Picture a normal Monday. The owner is driving to the first no-cooling call and asks for the day’s schedule, any invoices needing attention, and the maintenance work coming due this month.

The assistant checks the current field service records, combines them with the relevant long-term context, and prepares a short list of actions. Anything customer-facing, financially significant or hard to reverse waits for confirmation.

That is a believable AI foreman. Not one magical robot running an HVAC company — an assistant that can remember, check the live operation, and help the owner make the next decision without pretending to authority it was never given.

Where this is heading

The most useful assistant in the trades probably will not be another isolated chatbot. It will sit above the software a business already runs, pull the right context at the right moment, and operate inside very clear permissions. Our guide to AI for HVAC businesses covers the workflows that are ready for that treatment today.

This owner is early and the full system still has to prove itself. The model is worth watching anyway, because it starts from a real problem rather than a product roadmap: too much operational knowledge depends on one person remembering everything.

Keep the three layers separate and the AI gets more useful as the business grows. Mix memory, live data and authority together and you have not built a digital foreman. You have hired someone else to supervise.

Frequently asked questions

What is an AI foreman?

An AI assistant that sits above a field service business’s existing software, reads the current operational record, applies longer-term context about customers and rules, and prepares the next action for a person to approve. It supervises information rather than people, and it holds no authority of its own.

Can you connect an AI assistant to field service software today?

Technically, often yes. Modern platforms expose data through APIs, webhooks can report events, and MCP provides a standard way for an AI application to connect to external systems. What none of those provide is the permission model — that still has to be designed.

Does MCP handle permissions?

No, and this is widely misunderstood. MCP standardises how an AI application connects to external tools and data. Deciding what the assistant may read, prepare or execute is the host application’s job, so the approval boundary is something you specify and enforce yourself.

Why not just let the AI remember everything?

Because memory goes stale and the business record does not. An assistant that remembers an unpaid invoice, a preferred time slot or an old service note will act on that after the facts have changed. Memory should explain context, never define current state.

Is a consumer AI safe to use in a trade business?

It depends entirely on what you connect it to and what you let it do. Reading a schedule is low risk. Anything customer-facing, financial or hard to reverse should require explicit approval, and the assistant should stop rather than guess when it cannot confirm something.

Is anyone actually running an AI foreman successfully?

Not in this story. The owner’s assistant and memory layer are running; the connection to the live business is not, and the workflow has not been proven across reading records, acting, failing and confirming. We would rather report that honestly than describe a plan as a result.

The verdict

The gap in this story is the story. An assistant that remembers, plus a business record that is current, plus a clear boundary of authority — that combination is genuinely useful, and none of it requires a breakthrough. It requires discipline about which layer owns what.

The owner who gets that right ends up with an assistant that makes a one-person operation feel like a three-person one. The owner who blurs the layers ends up with a very fast source of plausible mistakes.

Now we would like to hear from you. If you are using AI inside a trade business right now, tell us one job it handles well and one thing it still gets wrong. We would rather report what contractors are actually doing with these tools than what software companies are promising — get in touch.

Sources

• Model Context Protocol — official documentation