Estimating is where engineering firms lose time they never bill for. Someone reads a drawing set, counts devices, cross-references a schedule, checks what a similar job cost two years ago, writes down the assumptions, and builds a proposal — often over a weekend, often for work that will not be won. A project estimation agent attacks that bottleneck: it reads the documents, drafts the takeoff and the line items, flags what is missing, and hands an estimator something to correct rather than something to create.
Status: working prototype, actively refined. We are building this as a custom workflow integration for specific estimating processes — not as a general-purpose estimating product. That distinction matters, and we explain why below.
What the Agent Does
The agent works across the documents an estimator already uses — drawings, specifications, equipment schedules, scope documents, labour tables, material catalogues, and prior estimates:
- Scope extraction — read the specification and scope documents and set out what is actually being asked for.
- Equipment and device counting — take off quantities from drawings and schedules rather than by hand-tallying.
- Line-item drafting — build the estimate structure with materials, labour, and subcontractor allowances.
- Gap detection — identify what is missing, ambiguous, or contradictory in the documents, which is usually where estimating risk actually lives.
- Historical comparison — check the draft against comparable jobs you have already delivered.
- Assumptions and exclusions — produce the qualifying language explicitly, instead of leaving it to memory.
- Proposal drafting — assemble a first-draft proposal from the approved estimate.
Where drawings are the source, this connects directly to our CAD agent work — the same ability to read DWG geometry, layers, blocks, and annotations that drives drawing automation also drives a defensible device count.
The Estimator Approves. Always.
An estimate is a commercial commitment. A number that goes out the door binds your firm to a price, and an AI-drafted figure released without review is not an efficiency — it is an underwriting decision made by software. So the agent drafts; a human estimator reviews, corrects, and releases. Nothing reaches a client automatically.
This is the same human-approval pattern we build into every consequential agent, and estimating is one of the clearest cases for it. The value is not removing the estimator — it is giving them a drafted position and a list of flagged gaps instead of a blank page and a deadline.
Why Workflow Integration, Not a Product
Estimating is not generic. Your labour rates, your assembly logic, your historical job data, your standard exclusions, your vendor pricing, and the way your firm scopes work are specific to you — and they are most of what makes an estimate accurate. A generic estimating product has none of that and has to be taught it anyway.
We build the agent around your existing process: your document formats, your estimate structure, your historical data, your approval chain. It is more work than installing a tool, and it is the reason the output is usable rather than a plausible-looking number you cannot defend.
Where We Are Strongest
Estimating building-automation, controls, and mechanical scope is where our domain knowledge compounds. Counting devices off a controls drawing, reading an equipment schedule, understanding what a BAS point list implies about labour — that is the work our Niagara practice does daily. An estimation agent built by a team that has commissioned the systems being estimated makes better assumptions than one built purely from documents.
Being Straight About the Limits
This is a working prototype, not a finished product. Drawing sets vary enormously in quality, and an agent reading an inconsistent or poorly layered drawing will miss things — which is exactly why gap detection and estimator review are core to the design rather than bolted on. We would rather tell you where it needs a human than sell you an autonomy claim that fails on your first real bid package.
Tell us how your firm estimates today — the documents you work from, where the hours actually go, and what a good estimate has to contain — and we will scope what an agent can realistically draft for you, and what should stay with your estimators.
What Makes a Document Set Readable
The largest variable in a takeoff is not the agent; it is whether the documents carry machine-readable structure. A PDF plotted from CAD keeps its text as text and its geometry as vectors, so a symbol is an object with coordinates and a tag is a string that can be read directly. A scanned or photographed sheet is pixels, so symbols have to be recognized visually and every tag has to be read by OCR, and both degrade with thin line weights, rotated text, and annotation crossing the symbol. The quick test is to open a sheet and try to select a device tag with the text cursor. If it highlights, the sheet carries text. If it does not, you are working from an image of a drawing rather than a drawing.
DWG files carry more structure than PDFs, but only when the drawing was built normally. Devices placed as blocks with attributes can be counted by block name, and their tags read out of the attribute values. The same devices exploded into lines and arcs, or drawn as raw geometry on a catch-all layer, lose all of that. External references are the other common surprise: an unresolved xref means whatever lived in the referenced file is simply absent from the drawing you received, which in the usual MEP arrangement is the architectural background the devices were coordinated against. Layer naming matters for the same reason, since a set that follows a consistent layer standard can be filtered by discipline and one where everything landed on layer 0 cannot. Where a set arrives as scans, asking the design team for the CAD files behind the plots, or for the equipment schedule as a spreadsheet, is worth doing before any other work starts, because a schedule handed over as a file is already structured data while the same schedule inside an image has to be reconstructed.
Where the Cost Lives in the Specification
Drawings tell you what to count. The specification tells you what the count costs. Under the CSI three-part section format, Part 1 General carries most of the requirements that add hours without adding devices: submittals and shop drawings, coordination drawings, quality assurance, extra materials and spare parts, warranty duration, owner training, and closeout documentation. Part 2 Products decides whether you are pricing the basis-of-design product or an acceptable equal, and whether substitutions are permitted at all. Part 3 Execution is where testing, point-to-point checkout, commissioning support, and as-built documentation sit, and those are hours whether or not anyone counted them.
Division 01 sits above all of it and gets skipped often: submittal counts and review turnaround, temporary facilities, cleanup, site access and safety requirements, and coordination meetings are general-requirement costs charged against every section. Attribution matters as much as content, because a device shown on a drawing is not necessarily a device you buy. Owner-furnished contractor-installed material is installed labor with no material cost, contractor-furnished contractor-installed is both, and not-in-contract or by-others items are neither, though they can still create coordination work. These are the lines worth pulling out of a specification and putting in front of an estimator before the takeoff is priced:
- Order-of-precedence language, which decides whether the drawing or the specification governs when the two disagree.
- Basis-of-design products and named acceptable manufacturers, plus whether an or-equal substitution requires prior approval and on what schedule.
- Submittal and shop drawing requirements, including coordination drawings and the number of review cycles allowed before resubmittal becomes your cost.
- Extra materials and spare parts named in Part 1, which are purchased quantities that appear nowhere on the plans.
- Testing, commissioning, and training obligations, including who witnesses the tests and how many hours of owner training are required.
- Warranty duration and what it covers, since a multi-year warranty that includes labor is a carried cost, not a line item.
Where the Count Goes Wrong
Miscounts are rarely random. They cluster into a few patterns, and each pattern has a cause in how the drawing set was assembled rather than in how carefully someone counted.
The reconciliation that catches most of them is cheap: count each device type off the plans for a given area, then compare that against the equipment schedule for the same area. When the two disagree, either one of the documents is wrong or one of the counts includes something it should not, and the disagreement is itself the finding worth flagging. These are the patterns that produce it:
- Typical details. A detail marked typical of 6 is drawn once and applies six times, and a count taken from geometry alone sees one.
- Double counting across views. A device drawn on a floor plan and again on a riser or one-line diagram is one device shown twice.
- Match lines. Sheets that overlap at a match line show the same area twice, and devices in the overlap get counted on both sheets.
- Demolition sheets. Existing devices marked for removal are labor, not new material, and reading them as new inflates both quantities.
- Alternates and unit prices. Scope carried as an add alternate belongs in the alternate, not in the base bid, and the drawings often do not distinguish them.
- Superseded sheets. When a set contains both an original sheet and its reissue, counting from the superseded one produces a number that was correct at a previous revision.
Every Quantity Needs a Source
A drafted quantity is only useful if the estimator can check it without redoing it. That means every number carries its provenance: the sheet number and revision it came from, the block handle or schedule row it was derived from, and the rule that produced it. An estimator reviewing a number with no source has to re-derive it, which can cost more than doing the takeoff by hand, and it also removes the audit trail that matters later, when the job is built and someone asks where a quantity came from.
Provenance changes what happens on the next revision as well. When quantities trace to specific sheets and rows, a reissued sheet invalidates only the quantities that came from it and the rest of the draft stands. Without that link, a change to any sheet puts the whole takeoff back in question. The same holds for assumptions: an assumption recorded as free text is a note, while an assumption recorded against the line items it affects tells you exactly what has to be re-priced if it turns out to be wrong.
Scoping a Build, and When You Do Not Need One
There are firms this is wrong for. If your bids are repeat catalog orders priced off a fixed-price book, the takeoff is not where your hours go and automating it returns little. If you bid a handful of jobs a year, the effort of encoding your assemblies and rates outweighs what it gives back. If every job is genuinely one-off with no reusable assembly structure, there is nothing stable to draft into, and the honest answer is to settle the estimate structure first, with or without an agent. Poor document quality on its own is not a disqualifier, but a firm whose drawings arrive only as phone photographs of printed sheets should expect review to dominate the process.
A build normally starts narrow: one scope type, one document family, and one estimator's process, run against jobs that are already closed so drafted numbers can be compared against what was actually bid. Expansion follows the same pattern, one scope at a time, rather than turning everything on at once. Three inputs are usually the hardest to produce, and they are worth starting on before development begins:
- Labor rates with their crew makeup and productivity factors, not a single blended hourly number, since a device count only becomes hours through an assumption about how long that device takes and who installs it.
- A deliberately bad sample set: the worst drawings you have accepted in the last two years, not the cleanest. Anything tuned on clean documents fails on the ones that actually arrive.
- A named person who decides scope boundary questions, because many flagged items are not technical questions but judgment calls about what your firm includes by default.
Frequently Asked Questions
Does this replace our estimating software?
No. It does not replace your estimating system; it drafts into it. Your cost database, assembly library, bid history, and the record of what was actually sent to a client all stay where they are. What the agent produces is a structured takeoff and drafted line items that have to map onto items your system already recognizes, which is why item mapping is usually the largest piece of the integration work. Where a drafted item has no match, the useful outcome is an unmapped line held for review rather than one force-fitted to the nearest existing item.
What has to be in place before a build is worth starting?
Four things. Your documents have to live somewhere a program can read them, which normally means a shared folder or a document management system rather than attachments scattered across inboxes. You need an estimate format you can describe in detail, including your assemblies and how rates are applied to them. You need closed bids with the estimates intact, so drafts can be back-tested against numbers you already trust. And you need an estimator who owns the review, because without a named reviewer the output has no path into a real bid.
What access does the agent need to our systems?
That is a scoping decision rather than a fixed design, and it is worth settling before development starts. The narrow end is a folder the agent reads documents from and an export file it writes. The wide end is a direct connection into the estimating database. Two questions drive most of the security discussion: where documents are read from, and whether drafted output is written into your system automatically or staged for a person to import. The second one changes the shape of the review step, so it belongs to whoever owns the estimating process and not only to IT.
Our drawings usually arrive as scanned PDFs. Does that rule this out?
No, but it changes where the numbers come from. Where an equipment schedule exists as text, whether in the specification, on a schedule sheet, or in a submittal, counts are driven from the schedule and the plans are used for location, routing, and verification instead of as the count source. Where the scan is genuinely all that exists, expect a longer flagged-item list and heavier estimator review on the early drafts.
How are addenda and revised drawings handled?
That is one of the first process questions scoping has to settle. The choice is between re-reading the full set and producing a fresh draft, or comparing the reissued sheets against the previous draft and reporting only what moved. A delta is more useful to an estimator, but it depends on revisions being identifiable in the documents: a revision number and date in the title block, clouded areas, a bulletin reference, or a sheet index marking which sheets were reissued. When an addendum arrives as narrative text with no reissued sheets, someone still has to decide which line items it touches.
Does the agent decide the price?
No. Unit costs come from your rate tables and vendor quotes, and markup, contingency, risk posture, and bid strategy stay with the estimator. Vendor quotes bring their own constraints that a draft has to respect, since validity dates, quantity breaks, and freight terms mean a quoted unit price is only good under the conditions of that quote. Where a rate table has no entry for an assembly, the right result is an unpriced line reported for review rather than a filled-in guess, and that is worth checking on the first drafts you look at.
Can it work on scopes outside controls and building automation?
The limiting factor is the shape of the quantity rather than the trade. Counted quantities, meaning discrete devices with tags and a schedule, and measured quantities, meaning linear feet of conduit or duct, areas, and weights, are different problems. Counting matches symbols against schedule rows, while measuring needs scale calibration, usable polyline geometry, and routing rules that drawings usually do not state. Scopes that are mostly counted are the more tractable starting point, and measured work often has to carry a factor or an allowance until there is enough closed-job history to do better.