Building Tom: An AI System Inside a Construction Company

Tom is an AI system that lives inside the business instead of beside it. It covers lead to accepted estimate to operations handoff, and it is organized as hats, one assistant per role, all reading the same company memory.

Tom covers one stretch of the business and stops. A lead comes in, and the system carries it through qualification, the site visit, the scope, the estimate, the customer accepting that estimate, and the handoff to operations. It does not touch the build, the schedule after handoff, or the money at the end. Naming the boundary was the first real decision we made, because a system that promises the whole company is a system nobody can check.

Inside that boundary, Tom is organized as hats. Each role on the team gets its own assistant with its own name and its own permissions. EVIE is the field hat, the one that takes the site scan and the walk recording. JARVIS is the permit hat. HAL is the estimating hat. They all read the same company memory underneath, which is the part that makes them different from ten separate chat threads. A hat with no company memory behind it is a chat window with a name on it.

The scan is fast. What follows is not: a manual PDF export, a hand gather of scope and county records, roughly ten chat bots producing a field plan whose format drifts every time, someone fixing the formatting, then the whole job typed into the quoting system again and the quote built line by line.

Here is how a job runs today, before any of this. A free site visit happens. Somebody scans the rooms with MagicPlan on an iPhone, which uses the phone's LiDAR sensor to capture measurements. There is no integration available to us that pulls that scan straight into the rest of their stack, so the report leaves the phone as a PDF that a person exports by hand. Then the owner gathers the written scope and the county appraiser data himself.

Then it gets long. Roughly ten ChatGPT bots produce a field plan between them, and the format and the logo drift every single time, so somebody has to fix the formatting before anyone can read it. After that, the whole job is typed into Jobber by hand and the quote is built line by line. No single step in that list is wrong. The cost is that the same facts get handled four or five times by four or five people, and every handling is a chance to drop one.

The scan comes off the phone as a PDF report. The plan reader turns that report into rooms as data. On June 24, 2026, it read a real kitchen job's report and returned 18 of 18 rooms with nothing invented, scoring 100 out of 100 on its scoring run.

This is the piece we built first, because it is the piece the rest depends on. The scan comes off the phone as a report with room by room measurements and photos, page after page of it. The plan reader takes that exported report and gives back rooms as data instead of pages as pictures: each room with its dimensions and notes, the scope attached to the job, and the identifier that ties it back to the right job in the quoting system. The rule it is built around is that the job is the record and the address is not, so that two jobs at one address cannot quietly become one.

It has a real result behind it. On June 24, 2026, the reader ran against a real kitchen job's MagicPlan report and returned 18 of 18 rooms, with nothing invented that was not in the report, scoring 100 out of 100 on its scoring run. That is one job on one date, and it is the strongest single result in the build so far. It proves the reader reads a plan correctly. It does not yet prove a time saving, and those are different claims.

Not into the scan. Into the export, the reformatting, the retyping and rebuilding the quote line by line. We have not put a timer on it yet, and we are not publishing a minutes saved figure that nobody measured.

A takeoff is the step where a physical job becomes a priced list of work: rooms, measurements, linear footage, cabinet runs, and which trade owns which part. Ask an owner where the takeoff time goes and the answer is usually the measuring. On this job it is not. The scan is the fast part. The time sits in the export, the reformatting, the retyping and rebuilding the quote line by line, which is desk work that happens after everyone has left the site.

That is the part the build removes, and this is where I have to be careful. We have not put a timer on it. There is no before and after number yet, because no real job has travelled the whole chain, and the module that records that baseline on named live jobs is still ahead of us. So there is no minutes saved figure in this article. When there is a measured one, it will be published with the jobs it came from.

Nine pieces, built and checked one at a time: the audit and foundation, the company memory, the history read in, the field hat, the estimate and draft quote, the permit hat, their own box and spending cap, handover and the numbers, and the long form estimator report.

Tom is broken into modules so each piece can be built, checked and accepted on its own, rather than delivered as one large thing nobody can inspect. Here is every one of them, in the order they get built.

• Module 0, the audit and the foundation. Already delivered: three years of the owner's chat history catalogued, 325 legacy records moved onto GreenBuilt's own database, and a Jobber dashboard running since July 27.
• Module 1, the company memory. One record per client, property and job, so two jobs at one address never merge, plus a checked registry of the people and companies involved.
• Module 2, three years of history read in. Every conversation and file accounted for in one coverage table, with MagicPlan reports read and their dimensions tied back to the job they belong to.
• Module 3, EVIE, the field hat. The MagicPlan report and the client walk recording go in, and a one page brief each for the electrician and the plumber comes out.
• Module 4, the estimate and the draft quote. The estimate is drafted in Wisdom's own pricing, a person approves it, and only then does an unsent draft quote appear in Jobber.
• Module 5, JARVIS, the permit hat. On the customer's signature, a permit task, a job card and a schedule item get created without anyone having to remember.
• Module 6, GreenBuilt's own box. The system moves onto their hardware and their accounts, with sign-ins per person, a daily spending cap on AI use, and a backup and restore that has to be run for real before the module counts as done.
• Module 7, handover, corrections and the numbers. Corrections from the field become tests, and a before and after baseline gets recorded on named live jobs.
• Module 8, the estimator report. A long form priced estimate document, quoted separately if and when the owner wants it.

The order is the argument. The memory and the history come before the hats on purpose, because an assistant with no company memory behind it cannot tell you why a price was what it was on a job two years ago. Build that backwards and you get something that sounds confident and knows nothing.

Tested: 325 legacy records moved and re-counted, the quote engine's arithmetic and payment schedule against a real job's numbers, and the plan reader on one real job's report. Not tested: the chain end to end, the price catalog beyond 2 of 11 trades, and anything that writes to a live invoice.

Tested, with a receipt behind each one. The 325 legacy records moved onto GreenBuilt's own database and were re-counted by a fresh read: 291 jobs, 20 line items, 8 payment rules and 6 county records, all present. The quote engine's arithmetic and payment schedule passed their test run, and the useful part is what the test caught on the way: two earlier versions of the payment schedule, one living in the code and one in the written notes, were both wrong, and the test found them before a customer ever saw a number. The plan reader is the 18 of 18 above. There is also a candidate build of Tom itself with 115 of 115 engine tests and 129 of 129 application tests passing on a clean install, and its own notes say plainly that those tests use invented data and do not prove a real job journey.

Not tested, said just as plainly. The chain has never run end to end on a real job, and the only two pieces of that chain to have run on real job data are the two named above. The pricing catalog covers 2 of 11 trades on the one real job we measured it against, which is a gap we now know the exact size of and can close. The live job monitor reads the first 50 of roughly 291 jobs on each run, a known limit that is not fixed yet. And one rule is not a limitation but a design choice: Tom never sends a quote and never touches a live invoice. A person approves the estimate first, and only then does an unsent draft appear for a human to send.

A renovation job is a scan, a scope and a quote. A commercial real estate deal is a loan file, a lease and a rent roll. Same shape: documents nobody can query, facts retyped by hand. The method carries across. The proof does not, until it is run on real documents.

Strip the trade out of this and the problem is not a construction problem. It is a pile of documents nobody can query, and the same facts typed again by hand into the system that eventually bills. A renovation job has a scan, a written scope and a quote. A commercial real estate deal has a loan file, a lease, a rent roll and a payment history, and the person reading it is hunting for the handful of sentences that change the number. Same shape, different paper.

So the method carries across, and the limits carry across with it. Read the source document instead of waiting for an integration. Keep every extracted fact tied to the page it came from. Put a named person on the approval and let the system draft, never send. I have written up how that reads on the commercial side in how distressed commercial loan review actually works. What I have not done is run a lease or a loan file through this particular build, so there are no numbers here from that world. The pattern transfers. The proof does not, until it is done on real documents.

The plan is for the system to run on GreenBuilt's own box and their own accounts, with a daily spending cap and a backup and restore that gets proven before the module is accepted. Built that way, if we stopped working together, the system and the memory stay with them.

Module 6 is the one owners tend to care about once they understand it, and it is ahead of us rather than behind us. The system will run on GreenBuilt's own box and their own accounts, with a sign-in per person, a daily cap on what it can spend on AI in a day, and a backup and restore that gets run for real before the module is accepted rather than assumed. The point of building it that way is that if we stopped working together tomorrow, the system and the company memory stay in the building. The alternative, renting your own operating knowledge back from somebody else's platform, is a worse deal the longer it runs.

That is the shape of the work, and it is the shape I want more of. Pick the stretch of the business that actually hurts, build the memory first, put the assistants on top of it, keep a named person on every approval, and write down what is proven and what is not in the same sentence. GreenBuilt Co-Op and Wisdom Renovations are the current example, mid build, in public. If your operation reads like the one described up top, there is room to do this with you next.