Have a workflow like this one?
30-min scope call, free. By the end you'll know what we'd build, in what order, and what it costs.
Doc-aware agents reading drawings, pulling supplier prices, and drafting client quotes. Built to cut the wait between estimator, buyer and account lead, with a person signing off every quote.
The client is a regional contractor whose bid desk turns RFQ documents — architectural drawings, material specs, scope sheets — into priced quotes for clients. Each bid touched three roles: an estimator who read the documents and produced a takeoff, a buyer who priced materials against the supplier catalog, and an account lead who wrapped it into a client-facing proposal.
The chain worked, but it was slow. Most of the time on each bid was waiting between roles, not actual work. Estimators sat on bids until they had a few to batch; buyers checked supplier prices manually because catalogs were spread across PDFs, spreadsheets, and a dated procurement system. The result was a bid pipeline that lost work to faster competitors.
The contractor wanted to keep humans in the loop on every quote — they weren't trying to remove the estimator or the account lead. They wanted to shrink the wait time between roles by giving each person a draft to react to instead of a blank page.
The pipeline starts with doc ingest: drawings, spec sheets, and scope documents land in a single inbox and the system parses them into structured artifacts. Drawings get OCR'd; specs get chunked and embedded in Milvus alongside the contractor's prior bids and the supplier catalog. The vector store is the system's memory across bids — every new RFQ inherits context from similar past projects.
Three specialist agents draft the bid. The takeoff agent produces line-item quantities and material lists from the drawings + specs, citing the source location for every line. The pricing agent matches each line against the supplier catalog and returns a quoted unit price with a confidence score. The proposal agent assembles the priced takeoff into a client-facing document in the contractor's voice.
Every output goes to the estimator and account lead for review. The system never sends a quote to a client. The estimator can accept, edit, or reject any line; the account lead signs off on the final proposal. The whole point was to give them a starting draft, not replace their judgment.
The first two days of Map are discovery, inside the fixed price. Sat with an estimator through three real bids. Documented every place they paused, every reference they pulled, every decision they couldn't justify in one line. That became the spec.
Days 1 — 2Built the document pipeline before any agent code. Validated the takeoff parsing on 50 historical bids until accuracy was high enough that the estimator wouldn't have to redo the work.
Weeks 1 — 2Takeoff agent first, then pricing, then proposal. Each ran in shadow mode against new bids for a week before being trusted as the default draft.
Weeks 3 — 5Deployed inside the contractor's existing tooling — no new logins for the estimator. Loom walkthrough, runbook, 30-day support tail. Bids run through the copilot by default; estimators can fall back to manual any time.
Week 6Claude for the agents. Document reasoning over architectural drawings + dense specs benchmarked stronger than alternatives — fewer hallucinated line items, better citation discipline. Milvus for the vector store because the contractor needed metadata-rich filtering across thousands of past bids and supplier docs; pgvector would have worked at this scale, but Milvus's hybrid search ranked higher in our retrieval evals.
Python service layer. The team didn't have an in-house engineer; staying in a single language with a single deploy target kept the post-handoff support tail small. OCR was a precise pick: tested three providers, the one that read architectural drawings cleanly enough for layout-aware retrieval won, even though it cost more than the cheapest option.
Considered and rejected: a single big agent with all three responsibilities (lost specialization, regressed on takeoff accuracy), a fully manual pricing layer using deterministic SQL against the supplier catalog (couldn't handle the catalog's free-text item descriptions), and storing everything in Postgres with pgvector (worked, but Milvus was faster on the hybrid filter queries the pricing agent needed).
| Metric | Status |
|---|---|
| Bid turnaround, RFQ to quote | Number published when the client signs off. |
| Estimator time per bid | Number published when the client signs off. |
| Bids handled per week | Number published when the client signs off. |
| Win-rate change | Number published when the client signs off. |
About these figures. Verticals, durations, stacks and architecture are real. Outcome numbers are published only with client sign-off, and none are signed off yet. Read the open book.
30-min scope call, free. By the end you'll know what we'd build, in what order, and what it costs.