Every civil engineer who has done water work knows the fire flow report. It’s not hard. That’s the problem. It’s a long sequence of steps that are each straightforward, that have to be done in order, that have to be right, and that eat most of a day for the professional engineer in charge every time one lands on the desk.
I run a civil engineering firm, Calichi. We do this on most projects, sometimes more than once when the work is phased, across four offices. So a few years into watching senior engineers spend a day at a time on it, I built an agent to do the production part. Here’s the honest version of what that workflow is, what it used to take us, and what it takes now.
What a fire flow report actually involves
Start with the flow test. You pull the flow test letter from the water purveyor or the fire district and read three numbers off it: static pressure, residual pressure, and the flow rate at the test hydrant. Those three numbers are the calibration target for everything downstream. Get the source wrong and the whole model is fiction.
Then the demand side. Pull the project’s water plan, identify the demand nodes, and figure out what the building actually requires. The required fire flow comes out of the fire code based on construction type and area, with reductions for sprinklers. In California that’s CFC Appendix B for the requirement and Appendix C for hydrant spacing and count. Other jurisdictions layer their own amendments on top, and you have to know which edition the local agency has actually adopted, not the one you used last year.
Then you build the model. In EPANET that means junctions, pipes, valves, fittings, the public main, the on-site loop, the service connections. You set the pipe material and roughness (we default fire service to C900 PVC unless cover, hydraulics, or the AHJ pushes us to ductile iron). You calibrate the model against the flow test until it reproduces the field numbers. If there are two service connections, you include the shared public main segment, because leaving it out double-counts the supply and quietly hides a pressure deficit at high flows.
Then you run the scenarios. Peak hour. Max day plus fire flow. Residual pressure at the most hydraulically remote hydrants. You check that the system holds the required flow at 20 psi residual, and you find the governing case.
Then you write it up. The narrative, the input tables, the scenario results, the schematic, the utility maps, the hydrant coverage exhibit, the appendices with the flow test and the model output. You format it to firm standards. You QC it. And then, the part that’s actually the job, the professional engineer in charge reviews the analysis, owns the judgment calls, and stamps it.
If you’ve done one, none of that is news. If you manage people who do them, you already know it’s most of a day, every time.
What it used to take us
At Calichi, a full fire flow report (EPANET model, fire code compliance, the written report with figures and appendices) ran 16 to 24 hours of an engineer’s time. The better part of a day, sometimes more, depending on the system. That’s our own measured number, not a projection.
The frustrating part wasn’t the hard part. The judgment, the unusual hydraulic condition, the call between a conservative and a realistic demand, the read on whether the AHJ would accept the approach, that’s real engineering and it deserves an engineer’s time. The frustrating part was the other 90 percent: the model assembly, the scenario runs, the table-building, the formatting, the appendix compilation. Same shape, every time, done by the most expensive person in the room.
How the agent does it now
The engineer emails the agent the way they’d email a junior: fire flow for this project, flow test letter attached, demand schedule attached. From there:
- It parses the flow test and reads out the static, residual, and flow values.
- It builds the EPANET model from the project files: junctions, pipes, valves, fittings, the public main and the on-site loop, calibrated against the flow test.
- It runs the scenarios (peak hour, max day plus fire, residual at the critical hydrants) and identifies the governing case.
- It checks the required fire flow and hydrant coverage against the fire code, for the code edition the local agency has actually adopted.
- It drafts the report in firm format: narrative, tables, scenario figures, the EPANET schematic, utility maps, and the appendices.
- It routes the whole package through a separate QC agent before a person sees it.
Then the finished package lands in the project folder, and the engineer picks it up the same morning instead of clearing a day for it. At Calichi that 16-to-24 hour task comes back in about 2 hours of engineer time, almost all of it review and judgment rather than production.
The QC gate
This is the part I’d push back on if someone described it to me, so let me be specific. The agent does not email its first draft to the engineer. Every output goes through a separate, independent QC agent first.
The QC pass checks the arithmetic, confirms the scenarios are complete, verifies the cited code sections actually apply to this project, flags a missing appendix, and catches the wrong jurisdiction’s value before it ever reaches a person. The point isn’t that the first agent is perfect. It isn’t. The point is that a tired engineer at the end of a long day isn’t perfect either, and a deterministic check that runs the same way every time catches the boring mistakes so the engineer can spend attention on the ones that need judgment.
I built this after shipping output without an independent pass and learning that "the engineer will catch it" is not a quality system when the output gets stamped.
What stays human
Everything that needs the professional engineer in charge. The engineer reviews the analysis, makes the judgment calls on the unusual cases, decides the demand basis, owns the relationship with the AHJ and the fire marshal, and applies the stamp. When a fire protection engineer’s hydraulic calculations are the authority on a project, those govern over our model, and the engineer is the one who knows that.
The agent does the production pattern-work. The engineer does the engineering. That division is the whole design, and it’s also why this is a supplement to your engineers, not a replacement for them.
Where it applies
Fire flow modeling shows up on most site development projects with a building of any size: commercial, institutional, multifamily, industrial, schools. It repeats on phased work. It crosses jurisdictions, which is exactly where the manual version gets slow, because every agency has its own adopted code edition, its own flow test format, and its own hydrant rules. An agent that resolves the jurisdiction from the project location and applies the right framework turns the slowest part into the fastest.
We run it everywhere we practice.
What this means for your firm
I’m not going to tell you it’ll save your firm 14 to 22 hours per report. That’s what we measured at Calichi, on our projects, with our standards. Your number depends on your workflow, your templates, and how your engineers work today, and the honest way to find it is to measure it on your real projects rather than promise it in a post.
That’s what the first two gates of how I deploy are for. An AI Readiness Audit to find where the highest-value automation sits across your divisions, then a Strategic AI Discovery that puts my engineers and yours on your actual workflows and produces the hours-saved picture by workflow, so you see exactly where the time goes back. Every gate is a stop or go. You only go further once you’ve watched the last step work on your own projects.
I built this inside my own firm before I offered it to anyone. Fire flow was one of the first agents, because it was one of the clearest cases of the professional engineer in charge doing production work that didn’t need them.
If you run a multi-office firm and that pattern sounds familiar, the first step is the AI Readiness Audit.