Thirty-four times in one week, someone asked the Boon agent to find something in a construction document set. Five customer agents produced the pattern.
The questions were not vague. They were about prevailing wage rates, liquidated damages, dryfall paint, and whether medium-voltage cable and terminations require testing.
The words are searchable, but the decisions are not.
An estimator can find “testing” in seconds. The harder question is whether the requirement applies to this scope, whether an addendum changed it, and whether the contract assigns it to the trade being priced. That is the work hiding inside a short question.
I used to call this document Q&A. I think that description is too small.
The first hit is not the answer
The first match feels like progress because it is visible: a page number appears, a sentence contains the right word, and the search appears to be over.
Except it isn’t.
The sentence may sit in a specification section that governs another trade. A later addendum may change the requirement. The contract may assign the responsibility somewhere else. The drawing may show a condition the specification never names. The phrase is correct. The conclusion is not settled.
Search is a lookup, while preconstruction is a reconciliation.
That distinction is easy to miss when the question arrives in one line. “Is testing required?” sounds like a yes-or-no request. In practice, it means: required for what, under which section, on which scope, in which revision, and with what responsibility attached?
The answer has to follow the question into the project.
The source has to travel
A useful response carries more than a sentence.
It carries the answer in plain language. It names the document. It cites the sheet or section. It preserves the passage that supports the read. If the set contains a conflict, it surfaces the conflict. If the set does not settle the question, it says that too.
That source trail is not decoration. It is what lets the next person continue the work.
A good response doesn’t just show its work. It makes the work legible to someone who wasn’t in the original conversation, and it doesn’t make them trust an invisible step between the citation and the conclusion.
A senior estimator has to explain the read to a project manager. A subcontractor has to decide whether to carry the work. A preconstruction lead may need to turn the gap into an RFI. If the answer arrives without its source, each person starts the search again. The agent has saved a sentence and returned the labor.
I want the citation to travel with the answer all the way into the handoff.
That changes the shape of the output. A response about liquidated damages should separate the contract clause from the schedule language in the proposal instructions. A response about dryfall paint should distinguish a direct requirement from a nearby finish reference. A response about medium-voltage testing should show the section that creates the obligation, not just a page that happens to contain the word “testing.”
The source is part of the answer.
The boundary is the product
The most dangerous answer is almost right.
A document set can mention testing without defining the exact equipment covered. It can contain a liquidated-damages clause while the proposal instructions describe a different schedule. It can show a finish on the drawings while the specification leaves the final selection to an approved submittal.
The agent should not smooth those edges over.
We don’t want it deciding that the latest-looking sentence wins. We don’t want it turning a nearby phrase into a contract interpretation. We don’t want it writing a confident paragraph because the user asked for a clean answer.
A clean answer that hides the gap is more expensive than an incomplete answer that names it.
The estimator still owns the call when the documents leave room for interpretation. That is not a failure of automation. It is the boundary that makes the automation useful. The agent should gather the evidence, show the conflict, and leave the commercial or contractual judgment with the person who carries it.
We made the demo too clean
We used to show the easy version. One PDF. One keyword. One answer.
It made the product look crisp. It also made the workflow look trivial.
That was our mistake.
We kept selling search because search fit in a demo. The real work starts after the first result, when someone asks whether the passage governs this scope, whether the addendum changes it, and where the answer should be carried next.
“Ask your documents a question” is a good entry point. It is not the product description I would use now.
The better description is quieter. The agent stays with the question while it moves across the contract, specifications, drawings, and addenda. It returns to the source when someone asks, “Where did that come from?” It can say when the set has not decided the issue.
That is less impressive in a thirty-second demo. It is closer to the work an estimator actually needs done.
The test we use now
The basic search demo isn’t enough. Any serious system can find a phrase in a clean PDF.
The better test crosses the set.
Ask about a requirement that could live in the contract, the specifications, the drawings, or an addendum. Ask for the source. Ask what is missing. Then ask a follow-up that changes the trade or the scope.
If the answer becomes more specific without losing its citations, the system is doing useful work. If it gives you a polished paragraph without a section reference, it is doing presentation. If it ignores a conflict between revisions, it is moving risk in the wrong direction.
You don’t need a benchmark slide to see the difference. The next question will expose it.
Still probably wrong
A document agent can read the set in front of it. It can’t know that the owner discussed a scope change on a call that never made it into the addendum. It can’t decide whether a contradictory clause deserves an RFI or a commercial assumption. It can’t replace the person who knows what the project team meant when the documents failed to say it clearly.
It can make the evidence easier to reach. It can keep the answer tied to the document that supports it. It can say, plainly, when the set doesn’t settle the question.
That is the standard we think estimators should apply to any vendor, including us. Don’t ask whether the system can search your files. Ask whether it can answer a real preconstruction question with a source, a boundary, and enough context for a person to make the call.
If it can’t, it isn’t document intelligence yet.
