Boon’s steel beam agent
Designing a structural steel takeoff agent
At Boon, I worked with engineering to design a structural steel takeoff agent.
We were trying to speed up one of the most tedious parts of preconstruction without asking estimators to take the model on faith. The shipped workflow cut a beam takeoff from roughly 55 minutes to 6 and shifted the user’s job from manual entry to review.
Context
I was Boon’s founding and only designer when we pivoted into construction. That meant learning the domain fast while still helping define how the product should work.
Structural steel was one of the first workflows that made sense to tackle. The user pain was obvious, the drawings followed repeatable patterns, and the scope was tight enough for us to build a real product instead of a vague AI demo.
The problem
Structural steel takeoffs sound simple until you sit next to an estimator and watch the work.
To finish a framing plan, they scan for each beam, read the label, count repeats, and turn that into order quantities. A label is doing a lot of work: it tells you the section, depth, weight per foot, and sometimes purchasing logic too.
The work is repetitive, but mistakes are expensive. A bad count changes tonnage, cost, and confidence in the bid.
So the problem was not just beam detection. We had to break the job into pieces engineering could actually build and estimators could audit.
Breaking down the agent
A big part of the project was sitting with engineering and breaking the agent into smaller, testable jobs.
Rather than treating it like one fuzzy AI system, we walked the workflow step by step. What kicks it off? What does the system look at first? What changes when a PDF is vector based versus raster? When can we trust the label, and when do we need a fallback?
That exercise shaped both the backend approach and the UI.
For structural beams, the flow looked roughly like this:
The estimator selects beams from takeoff intelligence.
The system checks whether the PDF is vector based.
If yes, it reads beam linework from CAD lines.
If no, it detects beams visually from the drawing image.
It extracts beam labels.
It parses the label into usable metadata.
It uses measured length.
It calculates tonnage when enough information is available.
It falls back gracefully when information is missing.
Mapping the failure points this way made the agent easier to reason about. It was no longer “find beams.” It was a sequence the team could inspect, tune, and explain.
Designing the handoff between system and user
Once we broke the workflow down, the next design problem was deciding what the user should actually see from that process.
I did not want the agent to feel like a black box. I wanted the output to reflect the logic underneath it.
If the system could detect beams but could not confidently parse a label, it should still assign a generic beam type instead of failing silently. If it could calculate length but not pounds per foot, it should leave tonnage fields empty instead of pretending certainty. Those fallback states were as much a design decision as a technical one.
This was a big part of the collaboration with engineering. We were not only aligning on what the model should do. We were aligning on how partial success should appear in the product.
The core design decision
The most important design decision was to keep the drawing at the center of the experience.
The drawing surface was not supporting context. It was the source of truth.
That meant AI output had to stay anchored to the plan. The table could not become a disconnected result view. Every grouped item needed a clear relationship back to the exact geometry and label on the drawing.
This made the workflow feel much more trustworthy. Users were not just reading results. They were seeing evidence.
Designing the review flow
Trust was the real product problem.
Even when accuracy was strong, users and managers were nervous that estimators would accept the output too quickly. I designed the review flow so checking the work felt built in, not like extra diligence.
Users could move through grouped measurements, jump directly to the corresponding region on the drawing, inspect segments, edit properties in place, and mark the work complete only after it had been reviewed.
That changed the job. Instead of rebuilding the takeoff by hand, estimators could spend their time validating exceptions and moving on.
The output
As the structural workflow matured, the output experience became much more grounded.
The table evolved into a review surface with grouping, linked items, weight per foot, tonnage, and purchasing context. The system was not just counting beams anymore. It was helping estimators move toward a bid-ready output while still showing enough evidence to validate the work.
Outcome
This became one of the clearest places where Boon delivered real value.
The workflow cut structural steel takeoff time on a framing plan from about 55 minutes to 6. Just as important, it changed what users were doing with that time. Less hunting, typing, and calculator work; more review, correction, and confidence.
What I learned
This project changed how I think about AI product design.
First, useful AI products usually start narrower than people expect. The breakthrough was not trying to solve takeoffs as one giant intelligence problem. It was choosing one workflow, drawing the boundaries clearly, and designing around a job estimators already cared about.
Second, that narrow scope led to better product decisions. Once we focused on structural steel, it became much easier to align with engineering on fallbacks, failure states, and how to make the output readable enough for someone to trust.
