Roots AutomationThe AI Agent Platform Built Only for Insurance
Roots builds AI agents for the insurance industry. Not chatbots. Not dashboards with a GPT wrapper. Actual autonomous agents trained to handle underwriting submissions, process claims documents, extract loss run data, and manage policy servicing — the operational work that keeps carriers running but buries their teams in manual tasks. Their client list tells you what you need to know: Berkshire Hathaway, SCOR, Eastern Alliance, Engle Martin, Mutual of Enumclaw. These aren't companies that take chances on unproven platforms. Roots earned that trust by solving real problems — one of their insurance carrier clients achieved a 100x improvement in claims document processing after deploying Roots' AI agents. But when Roots first came to Few, they weren't there yet.
The Challenge
Roots had built four distinct automation products. Each one worked. Each one solved a legitimate problem. But each one existed as its own thing — its own interface, its own experience, its own design language. What started as focused product development had become fragmented. Four tools doing four jobs with no connective tissue between them.
That's a common trajectory for startups that build fast and build well. You ship what works. You iterate on what customers need. And then one day you look up and realize your product suite doesn't feel like a suite — it feels like four separate companies built four separate things.
For Roots, the timing made it urgent. They were approaching a Series B raise. Investors don't just evaluate what a product does — they evaluate how it scales. A fragmented product experience raises questions about technical debt, about long-term platform viability, about whether the team can execute at the next level. Roots needed to walk into that raise with a unified vision, and they needed the product to back it up.
The Approach
Few was brought in to lead the strategy and UX work — to figure out how four products come together without losing what made each one work in the first place.
That distinction matters. This wasn't a redesign. It wasn't a rebrand. It was an architecture problem disguised as a design problem. The question wasn't "how do we make these look the same?" It was "how do we build a framework that holds all of this and still has room for whatever comes next?"
We started where we always start: understanding the users. Insurance underwriters, claims adjusters, operations teams — each group interacts with automation tools differently, with different workflows, different expectations, and different definitions of what "working" looks like. Collapsing everything into a single view would have been simple and wrong. The work was in finding the shared patterns without flattening the differences.
From there, we mapped the information architecture for a unified platform. How do you move between underwriting tools and claims tools without losing context? How do you surface the right data at the right moment when each product generates its own data set? How do you build a navigation system that scales from four products to fourteen without becoming unusable?
These are the questions that don't show up in a pitch deck but determine whether a platform survives its next phase of growth.
The Solution
Few delivered a unified product experience that brought all four tools under one roof — a single platform with shared navigation, consistent interaction patterns, and a design system built for scale.
On the UX side, we designed workflows that respected the distinct needs of each product while creating a coherent experience across the entire platform. An underwriter moving from submission intake to loss run processing shouldn't feel like they've switched applications. A claims adjuster working through document indexing and then checking FNOL status should feel like they're working in one place, because they are.
On the frontend architecture side, we built a component system and technical foundation designed to accommodate growth. Roots wasn't going to stop at four products. They needed an architecture that could absorb new AI agents, new workflows, and new capabilities without requiring a structural overhaul every time. We built for that future — a modular, scalable frontend that treats each new product as an extension of the platform rather than an addition to it.
The result was a platform that could stand up to Series B scrutiny. Not because it looked polished — though it did — but because it demonstrated that Roots had the infrastructure to scale. The product told the same story the team was telling: this is a company that knows where it's going and has built the thing to get there.
The Outcome
The Outcome The Roots platform today is unrecognizable from where it started. What was once four separate tools is now a comprehensive AI agent platform trusted by some of the largest insurance carriers in the country.
The platform has expanded well beyond its original scope. Roots now offers a full suite of AI agents covering underwriting automation, claims processing, and policy servicing and operations. They've built InsurGPT — a proprietary insurance-specific AI model embedded across the platform. They've added a Cockpit for real-time monitoring and oversight of AI agent activity. They've introduced Human-in-the-Loop collaboration for exception handling. And they've layered in Workflow Orchestration to connect with the systems insurance teams already use daily.
None of that happens on a fragmented foundation. The architectural decisions made during our engagement — the shared design system, the modular frontend, the scalable information architecture — created the structural runway for everything that followed.
Roots has since rebranded from Roots Automation to simply Roots, reflecting their evolution from an automation tool provider to a full platform company. They maintain SOC 2 Type 2, ISO 27001, HIPAA, and CCPA compliance. They're available on the Azure Marketplace. And their client results speak louder than any case study — including one carrier that saw a 100x improvement in claims document processing speed after deployment.