How I built an AI content engine for my own engineering firm
June 2, 2026
I am an industrial engineer who has spent 20-plus years troubleshooting humidity problems inside food plants, pharmaceutical suites, and battery dry rooms. I know how to size a desiccant wheel. I also know how long it takes to write a technical guide that is actually correct.
The short answer is: too long.
A good application guide for, say, a tablet-coating room starts with the psychrometrics — entering and leaving conditions, moisture load, dew-point target. Then you explain why the design decisions follow from those numbers. Then you check every derived figure because a wrong grain-per-pound calculation does not just embarrass you, it potentially gets copied into a spec.
Doing that at any real scale — across a full library of application topics — was simply not on the table with one engineer and a blank document.
So I built a pipeline.
What the pipeline actually does
The system is a chain of three specialist AI skills I wrote for our firm, Desiccant Air Solutions. Each skill has a defined role and hands its output to the next.
The researcher goes first. Given a target application and keyword, it pulls together the engineering context: relevant humidity targets by application, common design problems, how our hybrid desiccant-refrigeration approach fits in. It also identifies what competitors have already published on the topic, so the generator knows what ground to cover and what to skip.
The generator takes that research brief and produces a first-draft article. It works from an explicit structure: lead with the customer’s problem, explain the engineering response, include a differentiation section that speaks to our specific hybrid design, and close with a call to action. The skill has internalized the voice rules — no academic hedging, no hype, plain-language headings — and it knows which hype words to avoid entirely.
The evaluator runs last. This is the step that changes the quality equation. The evaluator is not just checking grammar or SEO boxes. It is running psychrometric verification: for any stated moisture-removal figure (expressed in pounds per hour), it checks whether the math holds against the correct formula using the stated airflow and delta-grains. It checks dew-point claims against the application targets in our technical reference. It flags anything that looks derived but is wrong. If a number does not check out, it surfaces the issue with a specific correction rather than passing the article through.
The output
Running that pipeline across 14 application guides produced a library that covers topics from pharmaceutical tablet coating to lithium-battery dry rooms to cold storage dock-door infiltration. Each guide went through the full researcher — generator — evaluator chain.
The evaluator caught real errors. Not hypothetical ones — actual derived calculations that were off because a unit conversion was applied incompletely or a formula step was dropped. Those corrections happened in the QA pass, not after someone read a published piece and found the mistake.
Hours of expert technical writing compressed to minutes. That is not a marketing claim. It is what the output log shows.
The lesson worth taking
What made the difference was building the quality check into the workflow rather than treating it as an afterthought. The researcher, generator, and evaluator pattern is not complicated, but most people skip the evaluator entirely or replace it with a human reading the final draft with tired eyes.
When you are writing technical content where the numbers matter — and in regulated, process-critical industries they almost always matter — the evaluator step is not optional. It is where the system earns the right to be trusted.
The same logic applies to any AI system doing knowledge work in an engineering context. You can automate the research and the generation. But if you want the output to hold up to professional scrutiny, you need a checker that understands what correct looks like in your domain. A generic grammar pass does not substitute for domain-aware verification.
What this means practically
If your firm produces technical documentation — application guides, submittals, engineering reports, sales support — you are writing the same things repeatedly with small variations. That is exactly the kind of work a well-structured AI pipeline handles well. The value is not in replacing engineering judgment. It is in making sure that judgment gets applied once, in the right place, and then gets enforced consistently across every output the pipeline produces.
I am happy to walk through how the architecture works and whether a similar approach fits your operation. Start with the State of AI Session — an initial conversation about where AI fits in your specific workflow.