Seven agents.
One finished bid.

Phase 1 is the part most takeoff software skips. Before a single SF gets counted, the agent reads the entire plan set cover to cover and writes a narrative summary — what the project is, what's unusual about it, where the architect made calls that will drive cost, and what's missing.

It pulls client preferences off plan notes, captures existing site conditions (demolition, well capping, septic abandonment, tree removal), and surfaces the things that won't show up in a quantity column but will absolutely show up in the bid.

If you've ever lost money because a detail buried on sheet A-5.2 didn't make it into the budget, this is the phase that catches it. No quantities. No prices. Just a structured read of what's actually on the plans.

Why it matters: every downstream phase inherits this read. Skip it and you're doing math on a project the agent doesn't understand.

This phase sweeps the plan set across seven conflict categories — cross-discipline mismatches, within-discipline contradictions, MEP routing issues, code and buildability problems, site and zoning conflicts, constructability concerns, and spec/document gaps.

Every finding gets logged with a severity rating (Sev-1 through Sev-5) and a specific sheet reference. All of them — Sev-1 through Sev-5 — land in the Conflict Report you get at delivery. Nothing flows into the budget; nothing blocks downstream phases.

The output is an architect/engineer RFI memo: the conflicts you'd want to send back for resolution before signing a contract. The point is to surface what your design team needs to fix, in writing, before you bid the job.

Why it matters: the conflicts that bite a builder mid-construction are almost always visible at bid time if someone reads carefully enough. Most builders don't have the hours.

The takeoff is the count itself — every SF, LF, opening, and unit count, pulled off the plans and dropped into a structured schema (487 fields across categories from site conditions through interior finishes).

The rule is hard: every value cites the sheet and detail it came from. No guessing. If a quantity can't be measured directly, it gets flagged for builder verification rather than estimated.

Each row gets validated — area math has to close, perimeter has to match the footprint, opening counts have to reconcile against the door and window schedules.

Why it matters: this is the layer most takeoff tools sell you. The difference is that ours runs the same audit a senior estimator would run before passing the takeoff to pricing — and refuses to move forward if the numbers don't reconcile.

Phase 4 is the highest-stakes phase. The takeoff feeds into 135 cost-code formulas — one per trade scope — and produces a line-item estimate organized the way a builder actually thinks about a job.

Every formula has a unit-rate baseline calibrated to regional cost data, refreshed quarterly. When the agent overrides a baseline rate (because a project warrants a higher or lower number), the override is logged with a reason. Every override gets re-audited in Phase 5.

Why it matters: most AI estimators give you a number with no way to defend it. This one gives you 135 line items, each tied to a specific quantity from Phase 2 and a specific unit rate, with every adjustment logged and auditable.

Phase 5 is the QC gate. A second agent — running the same model, with a different system prompt and no access to Phase 4's reasoning — re-audits the entire estimate the way a senior estimator would audit a junior's work.

It re-reads every override logged in Phase 4 and asks: was this override warranted, was it directionally correct, was it documented well enough to defend? Anything that fails goes back for correction, not approval.

It runs sanity checks — total bid against $/SF range for the project type, line-item ratios against typical splits, scope coverage against Phase 1 narrative findings. Out-of-range numbers trigger a re-pricing pass, not a footnote.

Why it matters: the failure mode in AI estimating isn't a wild number — it's a plausible-looking number that's $40K off because nobody re-checked the override. Phase 5 is the second pair of eyes that catches that.

Phase 6 takes the QC-approved estimate and writes the Scope of Work — organized by trade category, formatted the way a builder would format it for a client, with the front elevation from page 1 of the plans pulled in near the top.

No costs in this document — that's the rule. The SOW describes what's in scope and what isn't, in plain language, organized in the order trades hit the job site. The numbers live in the cost estimate. The scope lives here.

Every line traces back to a specific cost code or takeoff row, so when a client asks why something is or isn't in the bid, you can answer with the source.

Why it matters: the SOW is the document a client signs against. A mismatch between the SOW and the cost estimate is how change orders happen. Generating both from the same upstream data is how you avoid that.

Delivery is the assembly step. Four files land in your dashboard: the Quantity Takeoff (XLS), the Cost Estimate (XLS), the Scope of Work (DOC), and the Conflict Report (DOC) — plus an in-app bid view that reads them side by side.

Everything is named with your project identifier, formatted for direct use, and ready to download. One-click revisions kick a single phase back without re-running the whole pipeline.

The four-hour SLA is measured from upload to delivery. Most bids land faster than that.

Why it matters: a deliverable you can't actually use isn't a deliverable. Every output is in a file format your office is already working in — no proprietary viewer, no platform lock-in.