The owner-run mitigation company: a 2 a.m. burst pipe, an office by 7.

Running a water mitigation company alone means two businesses share one person: an emergency service that works at night, and a documentation business that has to be right by morning. AI assistants can carry a real share of the second. They cannot touch the first. The call, the dispatch, the decisions on site and every message to a customer or carrier stay with the owner.

The one-man army model has a single owner directing a handful of named AI assistants, each preparing one kind of work for the owner to decide on. Grok Bot provides the pieces used here: named Bots on a shared cloud computer, scheduled routines, messages between Bots and group chats. The pillar article on the one-man army explains the model; this one follows a single night.

Based on the Grok Bot documentation at docs.x.ai as checked on 13 October 2026. Its statements on Bot rules, Bot-to-Bot messaging, routine triggers, connected apps, approval expiry and payments were rechecked against docs.x.ai and Cursor's help pages on 26 October 2026. The trade examples are Aevrion's illustrations, not documented Grok Bot use cases. Aevrion Ops is an independent consultancy. It is not affiliated with, endorsed by or a partner of xAI, SpaceXSI or Cursor. Grok Bot is named here only to describe it.

Consider an owner-run mitigation company in this illustration: the owner, two technicians, one van and a trailer of drying equipment. At two in the morning a supply line bursts under an upstairs bathroom sink. The homeowner calls the company number and the answering service the company already uses takes the call, records the details and pages the owner, who is on call. The owner calls back, walks the homeowner through the company's own shut-off script, decides the job cannot wait, and wakes one technician.

No assistant is in that loop, and none should be. Grok Bot has no telephony: it cannot answer the call, take a voicemail or text the homeowner. Its routines run on schedules no closer together than five minutes, which is the wrong shape for a burst pipe. The response to the emergency is the owner's, and so is the judgment about whether to go.

On site, everything that follows is licensed or safety judgment. The owner checks that the water is off, the power is safe and the ceiling below is not sagging. The source repair belongs to the homeowner: the IICRC's page for the S500 water damage standard (checked on 13 October 2026) puts finding and correcting the source on the property owner, not the restorer, so a plumber is called in the morning. The owner takes the first readings and photos, makes the preliminary category and class determinations, has the work authorization signed, extracts and sets the equipment.

Back in the van, the owner does what used to wait until the next evening. The answering-service email is already in the company inbox; a custom integration Aevrion would build forwards it to a folder the Bots can read, because the documentation names no connector for answering-service or restoration software. The owner attaches the meter photos and the site photos to the intake Bot's conversation, types a few lines (rooms affected, equipment placed, the plumber still to call) and adds one instruction: prepare everything, send nothing.

The intake Bot builds the loss record from the email and the notes and messages the documentation Bot that a new job exists. Messages between Bots are asynchronous: the receiving Bot picks up the request, handles it and replies later, with the handoff visible in the conversation. The meter photos go to the documentation Bot directly, not through a group, because the documentation says handoff messages to a group are currently text-only and an image a Bot must inspect should be sent to it directly.

The owner sleeps for two hours. In this design nothing the Bots prepare is meant to reach a customer, a plumber or a carrier before the owner wakes: every outgoing message is held as a draft, and the owner's approval rules stop sends.

Suppose the documentation Bot, working from the intake Bot's message, reached an action that needed approval at a quarter to five. Grok Bot's documentation is specific: an approval raised by work started without the user, such as a routine, a trigger or another Bot's message, expires after about ten minutes (Cursor's help pages say thirty), shows as Expired, and the action does not run. The owner would have to ask for it again in the morning. An approval does not undo work already done either, so the safe design is the one that does not depend on approvals at night at all.

So the overnight work is preparation only. The customer update and the note to the carrier are written as drafts. The documentation describes editable email drafts that show recipients and body, and the user chooses to send or discard each one. The standing rule, never send to a customer, carrier or plumber, sits in each Bot's memory as a lasting rule, which the documentation treats as guidance rather than a technical control. The real protection is that the drafts wait for a person.

At six a routine on the coordinator Bot gathers what the night produced, and by seven the morning group is ready. The group holds four Bots, inside the documented limit of two to six: intake, documentation, billing and a coordinator. In Aevrion's pattern the coordinator posts the queue and assigns the next step. The documentation's own group example has a coordinator that can assign work; a Bot that supervises the whole roster is not a documented feature, so this one routes and reports and decides nothing.

The owner reads the queue, then goes to each Bot's own conversation to act. That is not a preference: approval requests, login requests and email drafts are never shown inside a group chat, so the customer update is approved where the intake Bot shows it, and the carrier note where the billing Bot shows it.

1. 01

   Loss reported

   Owner

   The answering service, then the owner

   Advances when

   The owner returns the call and decides to dispatch

2. 02

   On site

   Owner

   The owner and one technician

   Advances when

   Water off, safety checked, readings and photos taken, category and class determined, authorization signed, equipment set

3. 03

   Notes handed over

   Owner

   Intake Bot

   Advances when

   Loss record built and missing fields listed

   Ends when

   If the answering-service email never arrived, the Bot says so and stops

4. 04

   Day-two checklist

   Owner

   Documentation Bot

   Advances when

   Moisture-map checklist drafted from the meter photos and notes

5. 05

   Carrier list

   Owner

   Billing Bot

   Advances when

   Documents the carrier will need are listed against what already exists

6. 06

   Morning queue

   Owner

   Coordinator Bot (Aevrion pattern)

   Advances when

   The three outputs are posted in the group with what needs the owner

7. 07

   Owner review

   Owner

   The owner

   Advances when

   Drafts edited, sent or discarded in each Bot's own chat

   Ends when

   In this design, nothing is sent to the homeowner, plumber or carrier before this state

The documentation Bot does not draw the moisture map and does not take readings. It drafts a checklist from the night's photos and notes so the technician who goes back on day two knows what the record has to contain. A restoration trainer writing for Accuserve (checked on 13 October 2026) lists what a drying record should show, including daily temperature and humidity readings inside and outside the affected area and at each dehumidifier, labeled moisture maps, and photos of the first readings and equipment. The checklist follows that shape.

• ROOMS

  Every room in the loss record, including the ceiling below, so none is missed on the second visit.

• READING POINTS

  The points marked on night one, by room, wall and material, so day two reads the same places.

• ATMOSPHERE

  Temperature and humidity in the affected area, an unaffected area and at each dehumidifier.

• EQUIPMENT

  What was placed where on night one, for the technician to confirm or correct.

• PHOTOS

  Meter readings in frame, equipment set-up, and anything the owner flagged at 3 a.m.

• OPEN QUESTIONS

  Anything the notes left unclear, written as a question for the technician, never filled in.

The billing Bot's overnight output is a plain list: claim number and policyholder if known, the signed work authorization, the first photo set, the moisture map, the daily logs as they accumulate, the equipment log, and the program checklist if the job came through a carrier program. Each item is marked present or missing. The program's requirements come from the document the owner keeps, not from the Bot's memory, which the documentation says is not an authoritative source.

The list is for the owner. What is said to the carrier, and when, is the owner's decision, and the billing Bot's drafts never discuss coverage. A related article in this series covers the daily drying log itself and the morning check that keeps it complete.

In this illustration the owner still did every part of the night that mattered: the call, the dispatch, the safety checks, the determinations, the signature, the equipment. What changed is the morning. Instead of reconstructing the night from memory and a camera roll, the owner starts from a loss record, a checklist and a document list, and spends the time deciding instead of typing.

Two set-up facts belong in any honest version of this. Every Bot on the account works on one cloud computer, so they all share its files and its browser sign-ins; separate Bots are not a security boundary, and an insurer or program portal that must be kept apart needs its own user account. And someone has to read the queue every morning, because drafts that nobody opens help no one.

Aevrion Ops can set this up with an owner-run restoration company: the loss-record format, the checklists, the routine, the Bots' standing rules and the custom integration that brings answering-service notes to them, where the answering service's API or terms allow it and after testing. If that is the shape of your nights, contact us to scope it.

1. The owner answers, dispatches and decides on site; Grok Bot has no telephony and is not an emergency responder.
2. Overnight, Bots prepare: a loss record, a moisture-map checklist and a carrier document list, with every message held as a draft.
3. Approvals raised by unattended work expire after about ten minutes (Cursor's help pages say thirty) and do not run, so the night is designed to need none.
4. The morning group holds two to six Bots; approvals and drafts appear only in each Bot's own conversation.
5. Meter photos go Bot to Bot directly, because group handoffs are text-only.
6. All Bots share one computer and its sign-ins; keep sensitive portals in a separate user account.