Skip to content
Home » BLOG » How We Built RouteNet: Why We Created Our Own AI for a Problem Off-the-Shelf Models Couldn’t Solve

How We Built RouteNet: Why We Created Our Own AI for a Problem Off-the-Shelf Models Couldn’t Solve

  • by

In 2026, the default advice for any company that wants “to do AI” is simple: call an API. The frontier models are extraordinary, the tooling is mature, and for a huge class of problems that advice is exactly right.

This is the story of a problem where it wasn’t — and why we ended up building our own AI model, from training data to patent filing, to solve a single unglamorous problem inside one construction discipline. We think the lessons matter for anyone who owns or operates a business in a specialized industry, and especially for private equity firms asking what “AI transformation” should actually mean inside a portfolio company.

The problem: the last mile of a construction estimate

Through Aginera, our AI takeoff venture, we process construction drawing sets every day — electrical, mechanical, plumbing. Estimators use it to turn PDF and CAD drawings into bills of quantities: counting fixtures, panels, and equipment, and measuring the runs that connect them.

Modern multimodal AI handles a surprising amount of this. Reading schedules, classifying sheets, counting symbols on a floor plan — frontier models, carefully harnessed, do this well enough to build a business on. Aginera’s growth came from exactly that.

But one part of the job resisted every off-the-shelf approach: the routing. The conduit, cable tray, and wiring paths that snake through a building are drawn as dense, overlapping linework — thousands of line segments sharing a page with walls, dimensions, grid lines, and annotations that look almost identical. An experienced electrical estimator traces these routes by eye and measures them by hand. It is some of the slowest, most error-prone work in the bid process, and it directly prices real money: miss the routing and you eat the cost; overcount it and you lose the bid.

Why the API-call playbook failed

We tried the obvious things first. Every general-purpose vision model we tested — and we tested them rigorously, because we wanted the easy answer to work — failed in the same two ways:

They don’t speak the language. Foundation models are trained on photographs, documents, and web images. An engineering drawing is a different visual language: meaning lives in line weight, line style, and drafting convention, not in texture or color. To a general model, a cable tray run and a dimension line look like close cousins.

They fail in the wrong direction. In a consumer application, a plausible-but-wrong answer is a nuisance. In an estimate, a hallucinated route is a financial event. The tolerance for confident fabrication is effectively zero, and general models are not built to be conservative in that specific, measurable way.

The pattern to notice: the problem wasn’t that AI couldn’t help. It was that the economically decisive part of the workflow demanded precision guarantees and domain understanding that no horizontal tool ships with. That’s not a construction quirk. Almost every specialized industry has a workflow like this — and it’s usually where the margin is.

So we built RouteNet

RouteNet is our proprietary, patent-pending computer-vision system for recovering routing networks from construction drawings. We won’t say much here about how it works — the mechanism is the subject of an active patent filing — but the shape of the effort is the useful part:

It’s a purpose-built model, not a prompt. RouteNet is trained on curated, real-world drawing data we assembled ourselves, project by project, with labeling and validation workflows we had to invent because none existed for this problem.

It’s engineered precision-first. The entire system is designed and evaluated around a hard constraint on false routes, because that is what an estimator — and the contractor whose bid depends on the number — actually needs. Chasing benchmark-style accuracy would have produced an impressive demo and a useless product.

It compounds. Every project that flows through Aginera makes the data asset deeper and the validation set harder. A competitor can copy our UI in a quarter. They cannot copy the curated drawing corpus, the evaluation discipline built on top of it, or the filed IP.

RouteNet is now moving from research into the Aginera product, extending what the platform already does for estimators. But strategically, the more interesting result isn’t the model. It’s what the process proved about where AI value concentrates in a vertical business.

The playbook, generalized

Aginera didn’t grow because of a model. It grew because of a sequence, and the sequence is repeatable:

1 · Pick a wedge with money attached

Not “AI strategy” — one workflow where hours are burned and errors are priced. For us: takeoff. In your portfolio company it might be quoting, claims, scheduling, or compliance review.

2 · Use horizontal AI as far as it goes

Frontier models via API, harnessed with domain logic, got Aginera to market fast. Build custom AI only where the generic stack demonstrably breaks — and instrument everything so you know exactly where that is.

3 · Let the workflow generate the moat

The product’s daily operation produced the proprietary data, the evaluation sets, and eventually the patentable invention. The moat was a byproduct of running the business, funded by revenue, not a research budget.

4 · Buy distribution with specificity

Aginera’s inbound engine is intent-specific landing pages — one page per trade, per task, per market — plus free tools that let a buyer experience the product before a signup. Weekly inbound signups grew roughly 10× in a single summer on this pattern, with zero paid acquisition.

What this means if you own companies, not software

Private equity firms are staring at the same question from the other side: every portfolio company now has an “AI initiative,” and most of them are copilot pilots that will never touch EBITDA. The vertical AI pattern is the alternative, and operating companies are actually better positioned for it than startups:

They already own the scarce asset. Decades of quotes, claims, drawings, work orders, and outcomes — the exact data a vertical AI system needs and a foundation-model lab will never have.

They already have distribution. A startup spends years earning the customer relationships an established operator starts with.

The value shows up twice. Done seriously, vertical AI moves operating margin during the hold and re-rates the asset at exit — a services or distribution business that owns proprietary AI capability in its niche trades differently than one that rents generic software.

The discipline required is the same one we learned with RouteNet: be ruthless about using off-the-shelf AI wherever it works, and equally ruthless about recognizing the one workflow where owning the capability changes the company’s trajectory.

Talking to PE firms and operators about exactly this

Kamna Ventures builds vertical AI — we run our own AI ventures like Aginera, and we work hands-on with private equity firms and PE-backed operators who want real transformation, not AI theater. If you’re weighing where AI genuinely belongs inside a business you own, we’ll tell you honestly — including when the answer is “an API call is enough.”

Vertical AI for Private Equity → For Portfolio Company Operators →

Or book a direct conversation with our team

FAQ

What is RouteNet?

RouteNet is Kamna Ventures’ proprietary, patent-pending computer-vision system for recovering routing networks — conduit, cable tray, and wiring paths — from construction drawings. It was built inside Aginera, our AI construction-takeoff venture, to solve the part of electrical estimating that general-purpose AI models consistently fail at.

Why not just use GPT-style multimodal models for construction drawings?

General multimodal models handle many drawing tasks well — reading schedules, classifying sheets, counting distinct symbols. They break down on dense engineering linework, where meaning is carried by drafting convention rather than visual appearance, and where a confidently wrong answer has direct financial cost. Purpose-built systems can be engineered around precision constraints that generic models don’t offer.

Does Kamna build custom AI models for clients?

Sometimes — but only where it’s justified. Our default is the same discipline we applied ourselves: use frontier models via API wherever they meet the bar, and invest in proprietary models only for the specific workflow where owning the capability creates durable advantage. Most engagements start with an assessment that identifies which of the two situations you’re actually in.

How is this relevant to private equity?

PE-owned companies typically hold exactly the ingredients vertical AI needs — proprietary workflow data, distribution, and pricing power in a niche — but lack a build partner who has done it end-to-end. Kamna works with PE firms and their portfolio companies on assessment, build, and deployment, with EBITDA impact during the hold period as the explicit goal. See our private equity page for the engagement model.

Leave a Reply

Your email address will not be published. Required fields are marked *