ARCHITECTURE·MAY 06, 2026·13 MIN

THE ROOFING OS ARCHITECTURE

What it actually takes to keep 2,000+ tools in sync across a roofing operation — the integration graph behind ROOF_OS, explained.

BY Zach Rosenberg·Head of Platform Engineering

A roofing operating system is, structurally, an integration company. The user sees agents that quote, schedule, and dispatch. The engineering team sees a graph of 2,000+ external tools that have to stay in sync, gracefully fall over when they fail, and not pollute the data when they misbehave.

This article describes that graph. It is the technical companion to the autonomous roofing operator playbook. If you are an operator, you can skip it. If you are an engineer or a CTO evaluating the underpinnings, this is what you actually want.

The shape of the graph

We organize tools into roughly two dozen categories. Each category has 30–250 individual tools. The full inventory lives at /integrations; the categories are: CRM, lead capture, aerial measurement, insurance, permits, communications, calendars, payments, accounting, ERP, maps, storm data, document signing, supplier catalogs, marketing, analytics, BI, customer reviews, forms, storage, knowledge bases, AI models, developer tools, and webhooks.

Categories matter because agents reach for tools by category, not by name. When the Quoting Agent needs an aerial measurement, it doesn't ask for "EagleView" specifically — it asks the aerial category for the best response given the property and the available providers. Fallback happens automatically.

The four properties every tool must have

When we onboard a new tool to the graph, we evaluate four properties:

**Latency floor.** What's the 95th-percentile response time when the tool is working? Anything over 10 seconds gets demoted to async-only.

**Failure mode.** What does the tool return when it fails? Silent 200 with empty payload is the worst — we can't tell anything went wrong. Explicit 5xx is the best — we know to retry or fall back.

**Idempotency.** Can we call the same operation twice without side effects? Critical for any agent action that involves money or external messaging.

**Data residency.** Where does the tool store the payload we send it? For customer roof photos and homeowner PII, this is a contractual question.

PART OF

THE AUTONOMOUS ROOFING OPERATOR PLAYBOOK

A field-tested playbook for running a roofing company where agents quote, schedule, dispatch, and follow up — while owners decide.

Frequently Asked Questions

Can I see the full list of supported tools?

Yes, browse /integrations for the live catalog. Customer requests for new tools are tracked publicly and prioritized by votes.

How long does it take to add a tool that isn't supported?

Median 4 business days from request to availability if the tool has a public API. Tools without a public API can sometimes be reached via webhook listeners or browser automation, but those take longer.

Do I have to commit to your stack to use the integrations?

The integrations exist in service of the agentic stack. You don't license them à la carte. We are not an iPaaS — we are an OS that happens to integrate broadly.

What about data privacy across the graph?

Each tool has a documented data residency and retention posture. The system surfaces this when you enable the tool. You can configure tenant-level rules that block any tool whose policies don't meet your bar.

Is there an open API for our own developers?

Yes. We expose a REST and a webhook API for both inbound and outbound. Most operators use it to feed data into their own BI tools; a few have built bespoke internal tools on top.