Boon's steel beam agent
Boon’s steel beam agent
Designing a structural steel takeoff agent
At Boon, I designed a structural steel takeoff agent with engineering.
The goal was simple: help estimators get through one of the most repetitive parts of preconstruction faster, without asking them to trust AI blindly. The final workflow reduced structural steel takeoff time from about 55 minutes to 6, while shifting the user’s role from manual entry to review and validation.
Context
I was the founding and sole designer at Boon. When we pivoted into construction, I had to learn the domain quickly and start shaping workflows almost immediately.
Structural steel became one of the earliest areas where the product clicked. It had clear user pain, legible drawing patterns, and a narrow enough workflow that we could break the problem into concrete steps.
That made it a good place to go narrow and get something real working.
Context
I was the founding and sole designer at Boon. When we pivoted into construction, I had to learn the domain quickly and start shaping workflows almost immediately.
Structural steel became one of the earliest areas where the product clicked. It had clear user pain, legible drawing patterns, and a narrow enough workflow that we could break the problem into concrete steps.
That made it a good place to go narrow and get something real working.
The problem
A structural steel takeoff sounds straightforward until you watch someone do it.
An estimator has to scan a framing plan, identify each beam, read the label, count how many instances exist, and then translate that into purchase quantity. Even a single beam label carries multiple layers of meaning. It is not just geometry. It is section type, nominal depth, weight per linear foot, and sometimes downstream purchasing logic.
The work is repetitive, but it is not low stakes. Errors affect tonnage, cost, and confidence in the bid.
That meant the design challenge was not just making an agent that could detect beams. It was figuring out how to break the job down in a way engineering could build, and in a way estimators could understand and trust.
The problem
A structural steel takeoff sounds straightforward until you watch someone do it.
An estimator has to scan a framing plan, identify each beam, read the label, count how many instances exist, and then translate that into purchase quantity. Even a single beam label carries multiple layers of meaning. It is not just geometry. It is section type, nominal depth, weight per linear foot, and sometimes downstream purchasing logic.
The work is repetitive, but it is not low stakes. Errors affect tonnage, cost, and confidence in the bid.
That meant the design challenge was not just making an agent that could detect beams. It was figuring out how to break the job down in a way engineering could build, and in a way estimators could understand and trust.
Breaking down the agent
One of the most important parts of the project was working closely with engineers to decompose the agent into smaller jobs.
Instead of talking about the system as one abstract AI capability, we mapped the workflow step by step. What is the trigger? What does the system inspect first? What changes if the PDF is vector based versus raster? What information can we extract directly from labels, and what do we do when that information is incomplete?
That decomposition shaped both the technical approach and the product experience.
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.
Agent extracts beam labels.
It parses the label into usable metadata.
Agent then measures the length of each beam.
Then calculates tonnage when enough information is available.
It falls back gracefully when information is missing.
That structure mattered because it turned the agent into something more concrete than “find beams.” It became a sequence of legible operations with known failure points.
Breaking down the agent
One of the most important parts of the project was working closely with engineers to decompose the agent into smaller jobs.
Instead of talking about the system as one abstract AI capability, we mapped the workflow step by step. What is the trigger? What does the system inspect first? What changes if the PDF is vector based versus raster? What information can we extract directly from labels, and what do we do when that information is incomplete?
That decomposition shaped both the technical approach and the product experience.
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.
Agent extracts beam labels.
It parses the label into usable metadata.
Agent then measures the length of each beam.
Then calculates tonnage when enough information is available.
It falls back gracefully when information is missing.
That structure mattered because it turned the agent into something more concrete than “find beams.” It became a sequence of legible operations with known failure points.
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.
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.
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 product problem.
Even when model quality was high, users and managers were worried estimators would blindly follow the output. So I designed the review flow to make verification feel systematic instead of optional.
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 flow changed the nature of the task. The user was no longer rebuilding the takeoff manually, but they were still fully in control of validation.
Designing the review flow
Trust was the product problem.
Even when model quality was high, users and managers were worried estimators would blindly follow the output. So I designed the review flow to make verification feel systematic instead of optional.
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 flow changed the nature of the task. The user was no longer rebuilding the takeoff manually, but they were still fully in control of validation.
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.
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
The structural steel agent became one of the clearest examples of where the product delivered real value.
The workflow reduced structural steel takeoff time per framing plan from about 55 minutes to 6. More importantly, it changed what the user spent time on. Instead of hunting, typing, and calculating by hand, they could focus on checking the work, fixing exceptions, and moving faster with more confidence.
Outcome
The structural steel agent became one of the clearest examples of where the product delivered real value.
The workflow reduced structural steel takeoff time per framing plan from about 55 minutes to 6. More importantly, it changed what the user spent time on. Instead of hunting, typing, and calculating by hand, they could focus on checking the work, fixing exceptions, and moving faster with more confidence.
What I learned
This project reshaped how I think about AI product design.
First, focused agents are where AI products start becoming truly useful. The breakthrough was not treating takeoffs as one broad intelligence problem. It was isolating a specific workflow, defining its boundaries clearly, and designing around one job that mattered.
Second, focused agents create better product decisions. Once we narrowed the structural workflow, it became much easier to align with engineering on what the system needed to do, how to structure fallbacks, and how to make the output legible and trustworthy for estimators.
What I learned
This project reshaped how I think about AI product design.
First, focused agents are where AI products start becoming truly useful. The breakthrough was not treating takeoffs as one broad intelligence problem. It was isolating a specific workflow, defining its boundaries clearly, and designing around one job that mattered.
Second, focused agents create better product decisions. Once we narrowed the structural workflow, it became much easier to align with engineering on what the system needed to do, how to structure fallbacks, and how to make the output legible and trustworthy for estimators.
Featured work
Alerts
| Zapier
An error notification interface for Zapier's enterprise plan. A 0->1 feature.
->
Analytics
| Zapier
An analytics dashboard for Zapier's enterprise plan. A 0->1 feature.
->
Price Manager
| Zilliant
A permissions feature for pricing users managing their workbooks.
->
Alerts
| Zapier
An error notification interface for Zapier's enterprise plan. A 0->1 feature.
->
Analytics
| Zapier
An analytics dashboard for Zapier's enterprise plan. A 0->1 feature.
->
Price Manager
| Zilliant
A permissions feature for pricing users managing their workbooks.
->