Entropiex™ White Paper
A plumber, an electrician, a CPA, an insurance agent — the average owner is 57, has no succession plan, and is the receptionist, the dispatcher, the estimator, the CFO, the collections department, the HR desk, and the lawyer — all at once, all part-time, all under-resourced. The work is real. The license is real. The 20-year customer book is real. But none of it is written down, so when the owner sells, it sells at 1.5–2.5× earnings to a buyer pricing in everything the owner never built. Over the next decade, roughly $10 trillion of this value changes hands — the largest small-business ownership transfer in history.
The owner's problem is not effort. It is that one person cannot answer every after-hours call, quote in minutes, chase every overdue invoice, and watch cash flow at the same time. 40% of inbound calls go to voicemail. Quotes take days. The owner spends eleven hours a week on the phone. Every one of those is recoverable revenue walking out the door — and it is the exact gap an AI operating layer closes.
Enterprise AI does not reach these businesses. Wonderful.ai and its peers automate the front desk for companies that already have an ops team, a CRM, and an IT budget. The lower-middle-market owner has none of that — the owner is the ops team. Entropiex fills exactly that gap: not a bolt-on widget for a business that runs on systems, but the system itself for a business that runs on one exhausted person.
The arbitrage: buy at 1.5–2.5× earnings, deploy the AI operating system, recover 35–65% of leaked capacity, and exit systematized at 4–8× to the PE consolidators who are already buying. With seller-note leverage and disciplined deal structuring, that is a 5–8× cash-on-cash target per deal at the equity level. One business is live and proving it today. This document shows the work behind every number in that sentence — and Section 13 states exactly what we are raising and what you get.
How to read this document
The Investment Thesis makes the case in four pages: the asset class, the method, the return stack, and the position. This white paper is the data-room companion. It assumes you have read the thesis and now want to stress-test it — every convergence threshold and its statistical justification, the full agent architecture as deployed, market sizing and exit comparables per vertical, the financial model with its assumptions exposed, and the risks with their mitigations.
The one-page stakes above are the only recap — included so this document stands on its own for a reader who lands here first. Everything after it is new: where the thesis asserts, this document shows the work.
01 The Shadow Mode Methodology
Shadow Mode is the mechanism by which AI earns operational authority. The thesis describes what it does. This is how it is built.
Every Entropiex agent is deployed into a live business in a strictly non-acting posture. It receives the same inputs the staff receives — the inbound call, the job details, the price book, the customer history — produces the decision it would make, attaches a confidence score, and writes that decision to a ledger beside the decision a human actually made. It does not execute. In v1, no agent output and no deterministic rule output ever takes effect automatically, regardless of confidence. The human dispatcher confirms, edits, or rejects every proposal. The AI is on probation, and the ledger is the record of whether it deserves parole.
From open loop to closed loop
A manually operated service business runs open loops. A quote is sent, a job is scheduled, a technician is dispatched, an invoice goes out — and no one circles back to ask whether the price was right, the slot was correct, or the tech was the right match. The outcome is never connected back to the decision that produced it. Such a business cannot improve faster than its owner can personally pay attention.
Shadow Mode forces every workflow into a closed loop by construction. The AI's recommendation, the operator's actual choice, and the downstream outcome are written to one record, and the system reads itself continuously. Convergence is what happens when the loop has run enough cycles that the AI's recommendation is statistically indistinguishable from — or better than — the human's. A closed-loop business improves at the rate of its decision volume, not its owner's bandwidth.
Pre-trained, not under-training
This is not model training in the machine-learning sense. The underlying models arrive pre-trained on the general structure of service-business interactions. Shadow Mode does not teach the AI what a quote is. It proves the AI understands this business — its customers, its job mix, its local market, its pricing idiosyncrasies — well enough to be trusted with it. The asset being accumulated is not weights. It is evidence.
The decision ledger
Three persistent data structures carry the methodology. They are schema, not slideware — written on every decision from day one of deployment.
| Structure | Records | Purpose |
|---|---|---|
shadow_decisions | For every dispatchable action: AI-proposed decision, human-actual decision, confidence score, source (ai_agent or rules_engine), and reviewed outcome. | The append-only evidence ledger. Written before any shared-state write, so a write conflict can never discard a proposal. |
convergence_logs | Per workflow and job type: jobs_evaluated, ai_accuracy_pct, rolling-window size, and status (training → converged → auto_pilot). | The live convergence meter the owner watches. Recomputed on every reviewed decision. |
auto_pilot_config | Per workflow: enabled flag, threshold settings, owner-approval timestamp, and auto_pilot_disabled_at. | The autonomy switch. Cannot flip without explicit owner action. |
Outcomes are typed: ai_correct, human_correct, both_correct, both_wrong, or unreviewed. A decision defaults to unreviewed until a human dispatcher confirms or rejects it (quoting can be auto-scored once the final invoice amount is known). Critically, unreviewed decisions are excluded from the accuracy denominator entirely — they do not count as AI errors. This prevents a busy dispatcher's review backlog from artificially deflating measured accuracy, which would otherwise make the system look worse the busier the business gets.
Any competitor can license the same models tomorrow. What they cannot license is six to eighteen months of reviewed decisions tuned to one business's customers, geography, and job mix. The product is the proof, and the proof accrues only in calendar time and decision volume. Section 03 explains why that proof is also non-transferable between businesses.
02 The Convergence Framework
Convergence is measured with statistical rigor, not intuition. The phrase "our AI is 95% accurate" is meaningless on its own. The defensible statement is workflow-specific, business-specific, and bounded by a confidence interval: "Standard L2-install quoting for this business is 95% accurate, within ±10% of the human price, over the last 300 reviewed quotes."
The authoritative thresholds
Each workflow has its own definition of "correct," its own convergence bar, and its own auto-revert floor. These are the canonical values the platform enforces.
| Workflow | "AI correct" means | Convergence threshold | Auto-revert if… |
|---|---|---|---|
| Quoting | AI price within ±10% of human price | 95% over ≥300 reviewed | drops below 90% |
| Scheduling | Same tech AND start within ±2h of human | 90% over ≥200 reviewed | drops below 85% |
| Tech assignment | AI-proposed tech = human-chosen tech | 95% over ≥200 reviewed | drops below 90% |
| Invoice generation | AI total within ±5% of final invoice | 98% over ≥300 reviewed | drops below 95% |
| Follow-up timing | Sent within 30 min of human-preferred time | 92% over ≥200 reviewed | drops below 88% |
Why 200–300, and why 50 is malpractice
The sample size is not arbitrary. It is the smallest window at which the confidence interval around the accuracy estimate is tight enough to distinguish a converged workflow from a failing one. Consider the 95% Wilson confidence interval — the appropriate interval for a proportion — at three sample sizes, for an observed 95% accuracy:
| Reviewed decisions | Observed accuracy | 95% Wilson CI | Interpretation |
|---|---|---|---|
| 50 | 95% | ~85% – 98% | Lower bound sits below the 90% auto-revert floor. You cannot tell a converged workflow from one about to fail. Certification here is false confidence. |
| 200 | 95% | ~91% – 97% (±3pp) | Statistical minimum. Lower bound clears the revert floor. Convergence becomes defensible. |
| 300 | 95% | ~92% – 97% (±2.5pp) | Preferred. The lower bound sits comfortably above the 90% floor — the workflow is statistically distinguishable from failure. |
This is the entire reason the platform refuses to certify on small samples. A claim of "95% over 50 jobs" is indistinguishable from "85% over 50 jobs," and 85% is below the revert threshold. The 200-decision floor is the point at which the lower confidence bound finally clears the failure line; 300 is where it clears comfortably. Convergence certification therefore requires both the accuracy threshold and the minimum reviewed-decision count — never accuracy alone.
The rolling window
Accuracy is computed over a rolling window of the most recent 300 reviewed decisions (the full reviewed history below 300). The window is rolling, not cumulative, for a deliberate reason: a business is a living system. Its tech roster changes, its pricing strategy shifts, its job mix moves with the season. A cumulative average would let a year of stale decisions mask a recent regression. The rolling window means the meter always reflects what the AI is doing now.
What convergence actually takes at pilot volume
The live pilot — a Bay Area C-10 electrical contractor specializing in EV-charger installation in San Mateo County — runs 6–15 jobs per week across roughly three job types and four to five workflows. At that volume, reaching the reviewed-decision floor is a matter of months, not weeks, and the platform is honest about it:
| Workflow | Threshold | First activation (favorable, ~10 jobs/wk) |
|---|---|---|
| Follow-up timing | 92% over ≥200, ±30 min | Month 6–9 |
| Quoting — standard L2 install | 95% over ≥300, ±10% | Month 7–12 |
| Tech scheduling | 90% over ≥200 | Month 9–15 |
| Invoice generation | 98% over ≥300, ±5% | Month 12+ |
Graduated autonomy and the safety interlocks
Crossing the threshold does not activate anything. It raises an Auto-Pilot review request. The owner must explicitly tap "Enable Auto-Pilot" for that specific workflow. This guards against a scoring bug or data anomaly silently handing a workflow to the machine. The result is graduated autonomy — a business may run AI quoting in production for months while scheduling is still human, because scheduling has not yet converged.
Once live, three interlocks remain armed:
- Continuous monitoring. Auto-Pilot workflows are scored against real outcomes — completed jobs, no rework, no disputes, profit margin within 5% of the human baseline.
- Automatic reversion. If accuracy drops below the workflow-specific auto-revert floor, the workflow reverts to human review automatically, with an owner alert. No human has to notice the regression first.
- Re-qualification. A disabled or reverted workflow must re-enter Shadow Mode and re-converge over 200–300 fresh decisions before it can be re-enabled. A converged workflow does not auto-resume after a change to the tech roster, pricing strategy, job mix, or AI model version — any of which can invalidate prior proof.
A separate hard guard sits in front of all of this: before any outbound customer-facing action, the platform checks the customer's status. If a customer is flagged dispute_open, do_not_contact, or ccpa_deleted, the action is suppressed and logged — an automated review request or payment reminder never fires at an aggrieved or opted-out customer.
03 The Data Moat — Why Convergence Data Does Not Transfer
The thesis asserts that convergence data is non-transferable. The objection a sophisticated investor raises is the obvious one: if a competitor accumulates the same kind of data, doesn't the moat erode? The answer turns on specificity, and it is worth making precise.
The specificity problem
Convergence is never measured at the level of "the AI is good at quoting." It is measured at the level of a single business, a single workflow, a single job type, in a single market: "quoting for residential EV-charger installs in San Mateo County, for this contractor's customer base, is 95% accurate over the last 300 quotes." Every term in that sentence is load-bearing:
- Geography. Pricing is set by local labor rates, local permit and inspection regimes, local material costs, and local competitive density. A converged quoting model for electrical work in San Mateo encodes San Mateo's permit fees, its inspector behavior, its prevailing wage. None of that is true in Houston.
- Trade. The decision structure of HVAC dispatch (seasonal demand, equipment failure modes, refrigerant handling) shares almost nothing with electrical panel upgrades or EV-charger load calculations. The workflows are different shapes.
- Customer mix. A book skewed to condo HOAs and small commercial converges to different pricing and scheduling behavior than one skewed to single-family homeowners.
- Job mix. Convergence is per job type. A business heavy on $1,500 installs and one heavy on $5,000 panel upgrades reach convergence on different curves, at different volumes.
So a competitor's reviewed-decision corpus from HVAC in Houston does essentially nothing for electrical work in San Mateo. It is the wrong trade, the wrong geography, the wrong customer base, the wrong job mix. The data is not a general-purpose asset that compounds across the industry; it is a local asset that compounds only within a tight trade-plus-geography cluster.
Where the data does compound — and why that helps us, not them
Within a vertical-and-region cluster, learning transfers. Patterns proven on the third HVAC business in a metro accelerate convergence for the fourth. The platform tests micro-optimizations across like businesses and propagates the ones that hold. This is real, and it is why the marginal acquisition in a vertical converges faster than the first — by the tenth business in a vertical, pre-configured templates can roughly halve convergence time.
But this network effect is ours, accruing inside the portfolio, precisely because it requires owning the businesses to see their complete operational data. A SaaS competitor selling tools to independent owners never assembles a clean, comparable, fully instrumented corpus across a cluster — each customer is a walled, partial dataset on a different stack. Ownership is what turns many local datasets into one queryable training corpus with vertical-specific calibration.
Because convergence accrues only in calendar time and reviewed-decision volume, a competitor who deploys identical architecture tomorrow starts every workflow at zero and must wait out the same 6–18 month clock, per business, per workflow, in every local cluster they want to enter. The moat is not a secret algorithm a competitor could copy. It is a head start measured in months that widens with every job and every acquisition — and that they cannot buy back, because the only way to accumulate it is to have started earlier.
This is an honest moat, not a permanent one. No technology advantage is permanent. But in a market consolidating on a demographic clock, a structural two-to-three-year lead per cluster is sufficient to build meaningful scale before the advantage is competed away.
04 The Agent Architecture
Entropiex OS is a two-layer, multi-tenant agent system built on a strict separation of concerns: a platform layer that serves any business, and a tenant layer carrying the domain knowledge specific to one business. The distinction matters for the economics — it is what makes the marginal acquisition nearly free to operate.
Live in production: the multi-tenant Fastify/tRPC API and data model (jobs, quotes, invoices, customers, payments via Stripe/Square, the shadow_decisions / convergence_logs / auto_pilot_config ledger, and a native financial backbone — chart of accounts, expenses, bank feeds, depreciation, mileage); the Office Manager orchestrator and the SMS/notifications worker on BullMQ; the GPT-4o/Ollama vision pipeline for site assessments; the quoting agent's live decision logic; Receptionist Agent, the per-tenant receptionist, on the electrical contractor site; and the acquisition-diligence and zero-config onboarding pipelines.
Deployed but not yet autonomous: every agent runs in Shadow Mode — it proposes and logs, and a human executes. Convergence is tracked per workflow, but Auto-Pilot execution is not yet wired, so no agent acts automatically regardless of confidence.
Specified, not built: the CFO, HR, and Legal agents (Phase 4 / v2.5, Section 05); Auto-Pilot execution; and the scheduling, dispatch, billing, and follow-up agents beyond their current scaffolding.
Legacy, being retired: the original pilot-tenant-specific lead-intake service, superseded by the multi-tenant API.
Two roles, two layers
The architecture maps cleanly onto two distinct human roles, and the distinction matters because future tenants are not the Entropiex Founder.
- The Entropiex Founder sits at the platform level — the platform owner. The Founder acquires businesses, deploys the platform into them, and monitors portfolio-level metrics across every tenant. The Founder does not run any one business's day-to-day operations.
- The Tenant GM / business owner sits at the tenant level — one per acquired business. The Tenant GM is the day-to-day operator of that specific business and is the human the platform's Receptionist Agent and dispatcher workflows route to — quote approvals, dispatch exceptions, customer escalations all land with the Tenant GM, not with the Founder. In the pilot one person currently plays both roles; in the steady-state portfolio they are different people, and the architecture is drawn that way from day one.
The hierarchy as deployed
Two points orient the topology. First, the Office Manager is the orchestrator. Multi-tenant ingress lives in the Fastify/tRPC API: it authenticates each request, scopes it — and every database query — by businessId, and for any event an agent should see, enqueues it onto a durable BullMQ queue. The platform runs four (ai_agent, sms, email, invoice). The Office Manager consumes the ai_agent queue and is the hub-and-spoke center: it routes each event to the relevant specialist agents, enforces the confidence gates, writes the Shadow Mode ledger and audit log, runs the per-agent circuit breakers, and escalates to the Tenant GM. There is no separate routing tier above it. Second, Receptionist Agent is the only tenant-specific component. The customer-facing receptionist lives on each business's own server with its own knowledge base and phone number, and reaches the platform only over the public receptionist REST API (/api/v1/receptionist). Every other agent is a generic, tenant-aware worker — the same Quoting Agent serves every business, parameterized by businessId.
A separate pilot-tenant-specific lead-intake service (a pre-multi-tenant Express app) still handles that tenant's photo and Green-Button intake as a standalone service. It is legacy — being folded into the multi-tenant API — and is not part of the v1 platform path described here.
Why hub-and-spoke, not a mesh
Agents never talk to each other directly. At ten-plus agents, a mesh produces ninety-plus communication paths — impossible to debug, impossible to isolate by tenant, impossible to audit. Hub-and-spoke gives a single point of multi-tenant control, a clean audit trail, and traceable decision chains. Adding a specialist means registering one worker behind the Office Manager. Adding a tenant means a new Receptionist Agent plus config — no new platform code.
The full agent inventory
| Agent | Layer | Function | Status |
|---|---|---|---|
| Fastify / tRPC API | Platform | Multi-tenant platform entry point and event producer. Authenticates, scopes every request and query by businessId, enqueues domain events onto BullMQ. | Live |
| Office Manager | Platform | Hub-and-spoke orchestrator. Consumes the ai_agent queue, routes events to specialists, enforces confidence gates, runs per-agent circuit breakers, writes shadow_decisions, manages the Shadow Mode → Auto-Pilot lifecycle, escalates to humans. | Live (BullMQ worker) |
| Quoting Agent | Platform | Generates line-item quotes from the site assessment, price book, and labor model. The one specialist carrying live decision logic. | Shadow Mode (live logic) |
| Scheduling Agent | Platform | Tech assignment by skills, location, availability, job type. | Shadow Mode (scaffolded) |
| Dispatch Agent | Platform | Status-driven customer notifications; ETA / “on my way” workflow. | Shadow Mode (scaffolded) |
| Billing Agent | Platform | Invoice generation, payment terms, reminders. | Shadow Mode (scaffolded) |
| Follow-Up Agent | Platform | Review requests, satisfaction checks, seasonal reminders. | Shadow Mode (scaffolded) |
| Vision pipeline | Platform | Extracts panel / site-assessment data from job photos (GPT-4o primary, local Ollama fallback); a health monitor tracks the local model host. | Live (receptionist + quoting) |
| Receptionist Agent (per tenant) | Tenant | Customer-facing receptionist. Answers calls/SMS, qualifies leads, books jobs over the receptionist REST API. Carries trade-vertical knowledge. | Live — electrical contractor tenant |
| CFO / HR / Legal | Platform | Back-office operations layer. See Section 05. | v2.5 — specified, not built |
Confidence-gated autonomy
Every agent action carries a confidence score in [0, 1]. The score governs behavior — but only after a workflow is in Auto-Pilot. In v1 / Shadow Mode, the right-hand column is the only one that runs:
| Confidence | Auto-Pilot mode (post-convergence) | Shadow Mode / v1 (always) |
|---|---|---|
| ≥ 0.95 | Auto-execute (only after owner approval + convergence) | Propose only → logged → human dispatcher executes |
| 0.70–0.94 | Flag for human review | Propose only → logged → human reviews |
| < 0.70 | Reject / escalate | Reject / escalate; logged as low_confidence |
The rules layer — propose, never execute
Inside the Office Manager sits a deterministic rules layer that pre-computes suggestions for the most common cases (a standard L2 install, a panel upgrade, a service call). Its purpose is to save LLM cost and latency and to let high-frequency job types accumulate reviewed decisions fast enough to converge at pilot volume. It does not short-circuit the Shadow Mode contract: every rule match writes a shadow_decisions row tagged source: 'rules_engine' and returns a proposal for the dispatcher to review. A rule becomes an execution path only after that rule's own shadow accuracy clears the workflow threshold over ≥200 reviewed decisions and the owner enables Auto-Pilot. Rules propose; they do not execute in v1.
Resilience
An AI-native operating company has to assume its agents will fail and stay correct anyway. The architecture is built around that assumption:
- Circuit breakers per agent. Three consecutive failures opens an agent's circuit; its work routes to human review until a probe request succeeds. One agent failing never cascades into system-wide degradation. In v1 a single Office Manager instance holds breaker state in process, keyed per
businessId×agent; externalizing it to Redis (cb:{businessId}:{agent}) so redundant instances can share it is the planned v2 step that pairs with the redundant Office Manager noted below. - Idempotency on every side effect. BullMQ guarantees at-least-once delivery, so the Office Manager guarantees idempotent processing — composite keys (
{action}:{targetId}:{eventId}), Stripe's native idempotency keys, and ansms_sent_logtable for Twilio. A replayed event after a crash is a no-op, not a double-invoice. - Append-only Shadow ledger. Shadow decisions are written before any shared-state compare-and-swap, so a context write conflict never discards a proposal — the evidence is preserved regardless.
- Bounded blast radius. Per-event 30-second timeouts, a 20-job concurrency cap, queue-age alerting, and a 4-business-hour human-review SLA that auto-escalates. The deterministic FSM core keeps running even if Redis is briefly unavailable.
The Office Manager is a single logical point of coordination, which makes it the obvious single point of failure. It is mitigated, not ignored: durable queues, externalized state in Redis, health checks, supervised restart, and a redundant instance once any business reaches Auto-Pilot or the portfolio reaches three businesses.
05 Phase 4 — The Platform Back Office
The thesis frames Phase 4 as the structural inversion: deploy CFO, HR, and Legal capability once, at the platform level, and every business in the portfolio — present and future — inherits it at zero marginal engineering cost. This section is the technical specification behind that claim. These are businessId-scoped platform agents served by the same workers as every other agent; onboarding tenant #2 means they immediately inherit all three with no rebuild.
Return to the owner from the first page — the one who is the receptionist, the CFO, the HR department, and the legal desk, all at once and all stretched thin. Phase 4 is where that owner finally gets a bench. Receptionist Agent already answers the phone. The CFO replaces the midnight cash-flow guess; HR replaces the W-9 chased from the cab of the truck; Legal replaces lien law Googled on a job site. For the first time, the owner has the back office a $30M company runs on — a team no lower-middle-market business could ever afford to hire — and it is on the job the day the acquisition closes. A traditional acquirer rebuilds that back office company by company, hire by hire; Entropiex hands it to every business at once.
CFO Agent
The problem: the owner doesn't know if the business is making money until the accountant calls; cash runs dry the week of payroll; quarterly taxes arrive as a surprise; profitable-feeling jobs are losing money.
| Inputs | Outputs / actions |
|---|---|
| Job + invoice data (revenue, materials cost, sub labor); Mercury bank feed (real-time balance + transactions); Square/Stripe payment feed (AR, timing); vendor/expense records from the v1.7 Financial Backbone. | Cash-flow dashboard — balance, AR by aging bucket (0–30 / 31–60 / 60+), projected inflows from open quotes and scheduled jobs. Payroll-timing alerts — e.g. "$12K AR due this week, $8K sub payroll Friday — fine, but if invoice #47 isn't collected by Thursday, defer non-essential spend." Job-profitability report — revenue − materials − sub labor − permit = gross margin per job, weekly; flags jobs below 30%. Quarterly tax + 1099 reminders — SE-tax estimates prefilled with YTD net income; alerts when a vendor crosses $600/yr. Plain-English monthly P&L — "February: revenue $28K, gross margin 44%; panel upgrades outperformed installs by 12 points." |
Integration: jobs, invoices, payments, expenses, vendors tables; Mercury + Square/Stripe webhooks. Monetization: base subscription for all tenants; premium tier adds accountant-ready tax packages, depreciation scheduling, and multi-entity consolidation for the portfolio view.
HR Agent
The problem: a W-9 still missing from a sub paid three times; a certificate of insurance expired two months ago; a workers'-comp audit next week with half the subs' certificates not on file; the first W-2 hire feeling impossible without an HR department.
| Inputs | Outputs / actions |
|---|---|
| Job + sub-assignment data; document storage (W-9s, COIs, license certs); the job schedule (to detect active subs without current certs). | Sub-onboarding checklist — on a sub's first assignment: W-9, COI (business named as additional insured), CSLB license verification, signed sub agreement. COI expiration tracking — alerts 30 days out; can gate an expired-COI sub from new assignments. Workers'-comp renewal reminders — 45 days out. First-employee handbook — CA-compliant template (at-will, meal breaks, PTO, harassment) when the owner signals readiness; plus the I-9 / new-hire checklist. |
California's AB5 (Labor Code §2775) creates real liability when a contractor misclassifies a W-2 employee as a 1099 sub. The HR Agent watches for red flags — the same sub on more than 50% of jobs in a rolling 90-day window, a sub working exclusively for the business, the business controlling how the work is done rather than the outcome — and, when they accumulate, alerts the owner to consult an employment attorney before the relationship creates exposure. This is the kind of latent liability that destroys exit multiples and that no FSM vendor monitors.
Integration: jobs, technicians, vendors; document storage (Cloudflare R2); CSLB lookup API. Monetization: base (onboarding + COI tracking); premium adds handbook generation, first-hire workflow, multi-employee time tracking.
Legal Agent
Provides information and automated tracking only — not legal advice. Specific questions route to a licensed California contractor attorney.
The problem: a contract template from 2019 that's never been reviewed; uncertainty over which California lien deadlines apply to a direct contractor versus its subs and suppliers; an HOA dispute sitting unanswered for three weeks.
| Inputs | Outputs / actions |
|---|---|
| Job data (start date, address, property type); document uploads (sub agreements, customer contracts, HOA letters, permit docs); job status + invoice data for lien timelines. | Contract review — flags non-standard clauses, missing CA-required disclosures (mechanics-lien rights, contractor's-license disclosure), and overbroad indemnification; produces a plain-English redline. California lien-deadline tracking — correctly handles that a direct contractor is exempt from the 20-day preliminary notice and preserves lien rights by recording within 90 days of completion, while monitoring whether subcontractors have filed their own §8200 preliminary notices. CSLB license-expiration alerts (90 and 30 days), permit-status tracking, structured HOA/dispute response templates, and conditional/unconditional lien-waiver generation per Civil Code §8132. |
Integration: jobs, customers, invoices, permits; document storage; CSLB API. Monetization: premium add-on (~$50–100/mo incremental) — one avoided lien mistake or HOA dispute pays for years of subscription.
Delivery phasing
| Agent | v2.5 MVP scope | v3 full scope |
|---|---|---|
| CFO | Cash-flow dashboard + job profitability + tax reminders | P&L narrative, forecasting, multi-entity view |
| HR | Sub-onboarding checklist + COI tracking | Handbook gen, first-hire workflow, time tracking |
| Legal | Sub/supplier preliminary-notice tracking + CSLB expiration | Contract review, lien waivers, dispute guidance |
The FSM layer replaces Housecall Pro. The v1.7 Financial Backbone replaces QuickBooks Online — native P&L, balance sheet, and tax-ready exports that the incumbents all outsource to QBO. Phase 4 replaces a three-person back office. No competitor offers any one of these natively, let alone all three on one owned platform — and each one is deployed once and inherited by every acquisition.
06 Verticals — Sizing & Exit Comparables
The thesis names the verticals and the sequencing. This is the underwriting view: market depth, waste profile, decision-volume characteristics that govern convergence speed, and the exit comparable that sets the terminal multiple.
| Vertical | Target firms | Market size | Typical waste | Exit multiple |
|---|---|---|---|---|
| HVAC / Plumbing | ~350,000 | $220B | 35–45% | 4–6× EBITDA |
| Electrical | ~280,000 | $190B | 30–40% | 4–5× EBITDA |
| Insurance (independent) | ~39,000 | $150B | 40–50% | 6–10× EBITDA |
| CPA / Accounting | ~89,000 | $160B | 45–55% | 3–5× revenue |
| Immigration law | ~20,000 | $14B | 50–60% | 2–4× revenue |
| Dental practices | ~190,000 | $160B | 30–40% | 5–8× EBITDA |
| Property management | ~85,000 | $90B | 35–45% | 3–5× EBITDA |
| Pest control | ~27,000 | $17B | 25–35% | 4–7× EBITDA |
Natural buyers — the exit is liquid and active
The terminal multiple is not theoretical; there is a standing population of consolidators paying platform prices for systematized assets. In 2025 Capstone Partners tracked 149 HVAC M&A transactions, up 13% year over year — one vertical's slice of a broad consolidation.
| Vertical | Representative consolidators | Typical multiple paid |
|---|---|---|
| HVAC / Plumbing | Service Logic, Wrench Group, ARS | 4–6× EBITDA |
| Electrical | Comfort Systems, EMCOR, Sonepar | 4–5× EBITDA |
| Insurance | Acrisure, Hub, AssuredPartners | 8–12× EBITDA |
| Dental | Heartland, Aspen, MB2 | 5–8× EBITDA |
These buyers consistently struggle to integrate traditional acquisitions, because an owner-operator's decades of relationships and undocumented judgment do not transfer cleanly into a corporate structure. An Entropiex business resolves exactly that friction: operations already run on documented, instrumented AI workflows with a performance record attached, so the asset transfers as a system rather than as a person who has just left.
Why these eight, and in this order
Every vertical clears the same five tests: enough recurring decisions (scheduling, quoting, dispatch, billing) to drive convergence; schedulable work; licensing or certification as an acquisition moat; fragmented ownership under active consolidation; and industry FSM adoption below ~40% (manual operations are the raw material). The decision-volume test is what couples vertical choice to the convergence math in Section 02 — and it cuts across the residential/commercial line. A commercial electrical contractor doing three large installs a week can generate as many trainable decisions as a residential firm doing fifteen service calls, because each commercial job carries more discrete decision points.
Sequencing follows two axes: operator domain expertise and exit-market depth, traded against convergence difficulty under regulatory complexity.
- Phase 1 — HVAC & Electrical. Deepest in-house expertise, highest decision volume (fastest convergence), most mature and liquid PE exit market. This is where the playbook is proven.
- Phase 2 — Insurance & Accounting. The highest exit multiples in the set (insurance at 6–12×), at the cost of slower convergence under regulatory complexity and lower-frequency, higher-stakes decisions.
- Phase 3 — Healthcare, Legal, Mortgage. Entered as the platform and vertical-specific agents mature enough to handle the compliance surface.
07 The Acquisition Engine
Two instruments govern capital deployment. The Entropiex Score decides whether to buy. The AI Value Creation Index decides what to automate first once owned. They are different layers and should not be conflated.
The Entropiex Score — the buy screen
A 100-point framework measuring the dimensions a conventional acquirer cannot see, because conventional diligence stops at the financials:
| Dimension | Points | What it measures |
|---|---|---|
| Operational Waste Density | 0–30 | Recoverable revenue leaking through missed calls, slow quotes, scheduling gaps, unbilled work — measured pre-close via mystery shopping, operator interviews, and transactional analysis. |
| AI Addressability | 0–30 | Share of identified waste that maps to workflows an agent can handle. High for HVAC dispatch and routine quoting; low for bespoke custom fabrication. |
| Data Volume Threshold | 0–20 | Whether transaction volume can reach the convergence floor inside the hold. The direct link to Section 02: below ~10 jobs/week, convergence stretches past the target hold. |
| Structural Defensibility | 0–20 | Licensing, recurring maintenance agreements, geographic density — the determinants of exit multiple. |
Kill criteria — when to walk
- Score < 50: fundamental issues AI cannot address.
- Revenue < ~$500K: economics don't support deployment, and decision volume can't reach convergence in the hold.
- Owner-relationship-dependent pipeline: revenue living in the owner's personal network rather than in operational workflows cannot transfer to AI or to a new operator.
- Genuine regulatory/legal barriers: pending litigation, license-revocation risk, compliance failures that cannot be engineered out.
- Uncodifiable single-operator judgment: value resting on one person's high-stakes, low-volume judgment with no handoff path.
What is deliberately not a kill criterion: tacit operational knowledge held by a retiring owner. That is not a risk — it is the thesis. The 12–24 month consulting period is the window in which Shadow Mode captures that knowledge into the system while the owner is still present to answer edge-case questions. The discipline of the kill list is in separating operational chaos (fixable, and the source of the entry discount) from structural flaws (permanent).
The AI Value Creation Index — the deployment queue
Once a business is owned, every workflow is ranked by a single formula that sets the sequence of automation:
AI VC Index = (Value Potential × AI Leverage × Repeatability) / Complexity
Value Potential is dollar impact at full automation; AI Leverage is the share an agent captures versus a human; Repeatability is firing frequency — the engine of compounding. Complexity (integration friction, edge-case density, time-to-convergence) sits in the denominator, so a high-value workflow that needs bespoke integration ranks below a simpler one with two-thirds the payoff. This is why opportunity capture (inbound call handling) was the pilot's first deployment: highest value potential, proven addressability, fastest convergence. Retention and pricing — higher-leverage but more complex — are sequenced for months 6–18.
Financial thresholds & deal structure
| Metric | Minimum | Preferred | Rationale |
|---|---|---|---|
| Annual revenue | $500K | $1.5–3M | Economics support deployment; volume supports convergence |
| SDE margin | 15% | 20–30% | Room for operational improvement |
| Customer count | 200 | 500+ | Diversified revenue base |
| Years operating | 5 | 10+ | Established reputation |
| Entry multiple | 1.5× SDE | 2.0–2.5× SDE | Chaos discount captured at entry |
| Geographic density | 80% of revenue within a 30-mile radius | Route efficiency + local-market convergence | |
The Acquisition Capital Framework
Capital is deployed across three tiers, sized to each target's cash flow profile and AI leverage potential:
| Tier | Target profile | SDE range | Acquisition capital |
|---|---|---|---|
| Tier 1 | Founder-owned, single-location service businesses | $200–500K SDE | $400–700K |
| Tier 2 | Established operators, regional presence | $500K–1.5M SDE | $1–3M |
| Tier 3 | Multi-location, category leaders | $1.5M+ SDE | $3–8M |
Standard structure optimizes cash efficiency and aligns the seller through transition: 40–50% cash at close, 30–40% seller note (3–5 yr at market rates), 10–20% earnout tied to transition, an asset purchase for clean liability separation, and a 12–24 month consulting agreement — the knowledge-capture window. The quantitative screen is automated (financial documents to a scored memo in under 90 seconds); the qualitative judgment stays human: does the owner genuinely want out, will the lead tech stay, do customers call for the brand or for the founder.
08 The Financial Model
The thesis states the return. This section exposes the assumptions, the leverage that converts an enterprise return into an equity return, and the platform cost structure that makes the portfolio model work — including where it does not yet pencil.
Unit economics — a representative Tier-1 deal
A licensed service business with $500K SDE, acquired through the Entropiex acquisition vehicle. The model is built bottom-up and stated at two levels: the unlevered enterprise return, and the levered cash-on-cash return on the equity actually deployed after deal-level leverage.
| Line | Value | Assumption |
|---|---|---|
| Entry price | $800K | $500K SDE × 1.6× (chaos discount; Tier-1 range 1.5–2.5×) |
| SDE at exit | $750–900K | 90-day capacity recovery + per-workflow Auto-Pilot over the hold |
| Exit price | $2.6–3.6M | 3.5–4.5× SDE to a standalone consolidator |
| Unlevered MOIC | ~3.3–4.5× | Enterprise value growth, before financing |
| Equity deployed | ~$400–500K | Acquisition vehicle equity into a Tier-1 deal, net of seller note and earnout |
| Seller-note leverage | ~$240–320K | 30–40% seller note (3–5 yr, market rates), serviced from operating cash flow |
| Levered return | 5–8× cash-on-cash | At the upper end of a 24–36 month hold |
The two figures are not in tension; they measure different things. Unlevered: $800K of enterprise value grows to ~$2.9M — about 3.6×. Levered: only ~$400–500K of that $800K is investor equity; the balance is seller note and earnout serviced out of the business's own cash flow over the hold. At exit, equity value is the sale price less the remaining seller balance — on the order of $2.4–3.2M against ~$450K in — which is the 5–8× cash-on-cash. The enterprise return is the operating result; the equity return is that result amplified by disciplined, cash-flow-serviced deal leverage. The integrated-portfolio exit (6–8× SDE) sits above this entirely.
Where the value comes from — the four-layer decomposition
The return is not one event. It is four compounding layers, each separable and each with its own driver:
| Layer | Horizon | Mechanism & illustrative contribution |
|---|---|---|
| 1 · Revenue recovery | 0–6 mo | 24/7 capture, instant response, systematic follow-up. Pilot ran ~+20% in 90 days. Capacity expands at zero incremental headcount. |
| 2 · Retention & pricing | 6–18 mo | Churn prediction, maintenance-agreement conversion, dynamic quote calibration, margin-aware bundling. Re-activates a paid-for customer database the seller valued at zero — "distribution alpha." Plus 15–20% scheduling-density gain. |
| 3 · Capital efficiency | 9–24 mo | Receivables acceleration + inventory right-sizing. Pulling 30 days of DSO and 20% of parts inventory from a business with $200K AR / $150K inventory releases $100K+ — balance-sheet alpha, invisible to an SDE-only buyer. |
| 4 · Multiple expansion | 18–36 mo | Documented AI workflows + a performance record + captured founder knowledge move the exit from ~2–3× (founder-dependent) to 4–5× (systematized), and into 6–8× integrated. |
The differential against a conventional search fund (buy at ~2.5×, grind five to seven years, exit at ~3.5× for ~1.75× gross) comes from all four at once: a lower entry multiple, faster P&L creation, released working capital, and a higher exit multiple — each compounding the others.
Platform cost structure — and the honest break-even
The portfolio model rests on the marginal cost of operating the next acquisition approaching zero. The infrastructure curve shows why — and shows candidly that the economics are unattractive below ~5 businesses on infrastructure alone:
| Scale | Entropiex infra/mo | + maintenance | Legacy FSM licensing/mo | Net |
|---|---|---|---|---|
| 1 business | ~$92 | $492 | $219 | −$273 (worse) |
| 2 businesses | ~$259 | $659 | $568 | −$91 (worse) |
| 5 businesses | ~$764 | $1,364 | $1,495 | +$131 (better) |
| 20 businesses | ~$2,019 | $3,219 | $5,980 | +$2,761 (better) |
The point of the build was never the monthly infrastructure saving at small scale — on that line, licensing wins until five businesses. The build is justified by what licensing cannot provide at any price: native AI autonomy (no vendor offers Shadow Mode → Auto-Pilot), owned IP with zero legacy dependency, the exit narrative of a proprietary AI-native platform, and an eventual external SaaS revenue stream. One-time v1 build cost is ~$6–10K (AI tokens for code generation plus integration buffer) against a roughly 12-week, two-workstream effort — an extraordinary capital efficiency for a system that displaces a perpetual per-business SaaS dependency and a per-acquisition back office.
09 Proof of Concept — Pilot Results
In March 2026 the first AI workflow — inbound call handling, qualification, and scheduling — went live on the Bay Area C-10 electrical contractor. It is one workflow on one business; it is also the first end-to-end validation of the methodology in production, and it was chosen deliberately as the shortest path to a measurable result.
What the pilot proves — and what it does not
The operational metrics are confirmed against real customer interactions and call-tracking data: after-hours leads that would have gone to voicemail were captured; response time collapsed from a day-plus to minutes; close rate rose above the human baseline, which is the meaningful result — customers respond to speed, not to who is answering. Revenue attribution remains preliminary and is being tracked through Q2 for confirmation. The close-rate improvement is statistically significant at the pilot's lead volume.
What is honestly not yet proven, and what the remaining hold and the second acquisition exist to test:
- That the Shadow-Mode specialist agents follow the same convergence pattern across workflow types — today the quoting agent carries live decision logic while scheduling, dispatch, billing, and follow-up are scaffolded behind the same harness. Convergence proof is a 6–18 month outcome and arrives faster at a higher-volume second business than at the low-volume pilot (Section 02).
- That the methodology generalizes beyond residential electrical into other verticals.
- That cross-business learning measurably accelerates per-business convergence (Section 03).
- That the 4–5× → 6–8× integrated-portfolio exit premium is realized in a transaction.
The deliberate sequence is: prove the easiest, fastest-converging, lowest-integration-risk workflow first; sequence the higher-leverage retention and pricing workflows into months 6–18; let the compounding begin after the easy win is banked. The platform today is one proven live workflow (inbound call handling) plus the live orchestration layer — the multi-tenant API, the Office Manager, and the Shadow-Mode agent harness in which the quoting agent runs live decision logic while the other workflows are scaffolded; Auto-Pilot execution and Phase 4 (CFO/HR/Legal) are specified for later builds, not yet shipped.
10 Risk Framework
The risks worth underwriting fall into three groups: thesis risks (does the model work), execution risks (can this team ship and operate it), and statistical/compliance risks specific to an AI-native operating company. Each is paired with its actual mitigation, not a reassurance.
One workflow is proven in production. The architecture accrues value workflow by workflow, not all-or-nothing — even partial convergence across a portfolio justifies the investment. The deterministic FSM core operates independently of agent autonomy, so the business runs even if every agent stays in Shadow Mode indefinitely.
Shadow Mode keeps a human in the loop at every point until convergence; rollout is per-workflow, so customer acceptance is tested before any workflow goes autonomous. The pilot's above-baseline close rate is direct evidence that customers respond to speed of response, independent of who answers.
The single most important internal guardrail. "95% over 50 jobs" is statistically meaningless — the confidence interval spans below the failure threshold (Section 02). Convergence therefore requires the per-workflow accuracy and a 200–300 reviewed-decision floor and explicit owner approval. Continuous monitoring auto-reverts a degrading workflow; a reverted workflow must re-converge before re-enabling.
A hard pre-flight guard checks customers.status before any outbound action. A customer flagged dispute_open, do_not_contact, or ccpa_deleted is suppressed and logged — no review request or payment reminder reaches an aggrieved party. On a chargeback webhook, the customer is auto-flagged and all outbound automation halts for them. CCPA deletion is handled by a documented runbook scrubbing PII across every bearing table, not just the customer row.
Mitigated structurally: durable BullMQ queues with at-least-once delivery and idempotency keys, externalized state in Redis, per-agent circuit breakers, health checks with supervised restart, and a redundant instance once any workflow reaches Auto-Pilot or the portfolio reaches three businesses. A crash pauses new AI proposals; it does not lose data or stop the deterministic core.
The catastrophic multi-tenant failure. Today every query is scoped to the caller's businessId at the application layer, set from the JWT by Fastify middleware on each request — correct, but enforced query by query rather than by a database backstop. The hardening that turns this into true defense-in-depth — Postgres row-level security, a Prisma extension that injects business_id into every query, and an automated per-endpoint isolation regression test — is specified and is a hard precondition for onboarding the second business. It is not yet in place, which is one reason no tenant beyond the pilot has been provisioned.
A2P 10DLC SMS registration is slow and rejection-prone; it is submitted day one with two documented fallbacks (toll-free verified sender, then email-only) so go-live is never blocked on it. Key-person risk on Entropiex itself is addressed with runbooks (Office Manager restart, queue replay, re-auth) executable by a non-founder operator. Infrastructure is deliberately cheap and snapshot-backed — the whole stack can be mothballed for ~$92/mo without data loss.
Two different competitors, two different misses. FSM incumbents bolt AI onto a legacy architecture — structurally different from native AI — and lack the acquisition vehicle. Enterprise AI players (Wonderful.ai and peers) build for companies that already have an ops team and a CRM to plug into; the lower-middle-market owner has neither, so that product never reaches this buyer. Neither owns the businesses, so neither can assemble the moat (Section 03): the owned, time-locked convergence corpus they cannot retrofit. On multiples: service businesses are relatively counter-cyclical, entry at 1.5–2.5× SDE provides cushion, and even at conventional search-fund exit multiples (~3.5×) the returns remain attractive. Conservative modeling assumes only 60% of projected improvements are realized.
11 Why Own, Not License
The natural challenge: if the OS is the value, why not sell it as SaaS to the millions of existing owners rather than buy businesses one at a time? Four structural reasons make ownership the superior vehicle — and they are the same reasons the moat holds.
- Data access. Shadow Mode requires complete operational data — every call, quote, scheduling decision, and outcome. Independent owners do not grant a vendor that depth. Owners of the business do, by definition. No ownership, no convergence corpus, no moat.
- A clean architectural slate. The acquisition target is chosen because it is system-light: no FSM, no CRM, no middle-management layer to route information through. There is nothing legacy to migrate or break, so the AI layer runs end-to-end from day one. The chaos that depresses the entry price is the same chaos that makes deployment clean.
- Value capture. A SaaS subscription captures 5–10% of the value created. Ownership captures all of it — through margin expansion and multiple expansion at exit. The same deployment that would generate a five-figure annual subscription instead generates seven figures of exit-value appreciation.
- Adoption friction. Owners who have operated manually for twenty years rarely adopt complex technology voluntarily — the low industry AI-adoption rate is the evidence. Acquisition removes the adoption problem entirely: deployment is a decision the owner makes, because the owner is us.
Licensing the platform externally remains a real future revenue stream (v3), but as an addition to the ownership model, not a substitute for it. The economics and the moat both run through control of the data.
12 The Team
This is not a thesis written by people who have never run a P&L or shipped a system. Between the principals, the relevant track record is concrete:
- Hundreds of millions in capital-expenditure programs deployed across Fortune 500 manufacturing and infrastructure operations — the discipline of underwriting, financing, and operating capital-intensive assets.
- Hundreds of millions in AI-transformation engagements sold and delivered to C-suite buyers worldwide — knowing what AI does and does not do inside a real operating business, not in a demo.
- Production AI systems architected and shipped — software and hardware — at one of the world's largest cloud platforms. The platform in this document is built, in production, and run by the people who designed it.
We took that and pointed it at the businesses no one else will touch: licensed trades run by one exhausted owner. We deployed Entropiex on a live electrical contractor, found the leaked revenue, closed it, and gave the owner his evenings back. We are operators and builders who underwrite, not theorists who pitch. Full biographies and references are available in the data room.
[ Detailed founder biographies and prior outcomes to be finalized for the data-room version. ]
13 The Ask — Terms & Next Step
One business is live and proving the model. We are raising to acquire the next cohort, harden the platform for multi-tenant operation, and turn a single proof point into a repeatable machine.
What we are raising, and what it buys
Capital is deployed against acquisitions and the one-time platform hardening that lets the second, third, and tenth business run at near-zero marginal cost. The build is already done and cheap to maintain — the capital goes into assets that compound, not into burn.
| Use of funds | Allocation | What it produces |
|---|---|---|
| Acquisition equity (first cohort) | ~75–85% | Equity deployed from the Entropiex acquisition vehicle across the first cohort of Tier-1 deals (see Section 07 for the tier framework). Each business is structured to be cash-flow positive from month one, with seller financing layered in where available. |
| Platform hardening | ~10–15% | Postgres row-level security, tenant-isolation regression suite, redundant Office Manager, Auto-Pilot execution path — the hard precondition for tenant #2 (Section 10). |
| Operating reserve | ~5–10% | Diligence, legal, transition consulting, and a runway buffer per acquisition. |
What you get
- Asset-backed downside. Each deal is a profitable, cash-flowing licensed business bought below market, not a pre-revenue bet. The deterministic core runs with or without AI — the floor is a real operating company, not zero.
- A proven, owned operating system — not a third-party dependency. The convergence corpus, the agent platform, and the financial backbone are owned IP that compound with every job and every acquisition.
- Modeled conservatively. The return stack assumes only 60% of projected improvements land, and still clears attractive returns at conventional ~3.5× exit multiples.
Exactly what happens next
- 30-minute call. Email founder@entropiex.com — we walk the live pilot dashboard and the Shadow Mode ledger on screen, real data, no slideware.
- Data room. Sign a mutual NDA and receive the full room: pilot financials, the convergence logs, the architecture repo walkthrough, term sheet, and founder references.
- First deal. Review a live acquisition target scored on the Entropiex framework (Section 07) and commit to the first SPV.
Deals are still underwritten on historical performance, not transformed potential — which is exactly why the entry multiples are low and the arbitrage is open. That asymmetry closes as AI-driven value creation gets priced in. The advantage belongs to whoever builds the operating capability now, deploys it repeatedly, and accumulates the proprietary performance data that compounds with every business. That work has started. This is the entry point.
1 Exit Planning Institute, "State of Owner Readiness Report" (2025); McKinsey Global Institute, "The Coming SMB Succession Crisis" (2026). 2 U.S. Small Business Administration, Office of Advocacy, "Small Business Facts" (2026). 3 Capstone Partners, "HVAC Services M&A Report" (Q4 2025). 4 Convergence thresholds, the agent map, and Phase 4 specifications are drawn from the Entropiex OS Product Requirements Document and Software Architecture Document, which are co-authoritative; figures here reflect those documents as of April 2026. Wilson confidence intervals are computed for an observed proportion at the stated sample sizes.
This document represents the strategic and technical state of Entropiex as of April 2026. Financial projections are forward-looking, illustrative, and subject to risks and uncertainties; convergence timelines are estimates calibrated to the current pilot's volume and will vary by business. Not legal, tax, or investment advice.