An independent magazine about AI at work in construction. Every story starts on a real job site, with the people who used the technology and the results they will answer for.
Roofing Contractor Puts Grok Bot on Permits, Inspections, and Insurer Forms | ConstructionMagazine.ai
Roofing Contractor Puts Grok Bot on Permits, Inspections, and Insurer Forms
A roofing contractor put the new persistent agent on a permit, an inspection booking and insurer notifications. The useful part is the handoff, and the limit.
Nine days after Grok Bot appeared, roofing contractor Price Foulger posted what he had used it for over two days. It filled out and pulled an online roofing permit. It filled out and booked a roof inspection through an online form with a captcha. It filled out and emailed two job notification forms to his insurer.
Foulger posted the list on X on August 20. Each job crossed a city portal, a web form, or an insurer's inbox, and each ended with a filed document. The post does not say how long the runs took, how often he stepped in, or what he checked before the permit went out.
The three filings in order: the permit form, the inspection booking, and the insurer notices. AI-assisted illustration.
The cloud computer changes the assignment
SpaceXAI introduced Grok Bot on August 11 as an early beta. Each named Bot runs on a persistent cloud computer with a browser, filesystem and terminal. It can use plugins or MCP connectors where they exist, then fall back to the browser for software that has no clean integration. A Bot keeps its files, sessions and working context after the conversation closes, and scheduled routines can continue while the user's laptop is shut.
The product also lets several Bots work in parallel and hand tasks to one another. Under the hood, those Bots share one user-scoped computer. That makes a handoff cheap: a permit Bot and an estimating Bot can see the same file and browser session. It also means they are not isolated from one another.
SpaceXAI describes the product as teammates rather than tools, and the description matters for how it fails. A Bot is meant to finish a job end to end and return only when something needs approval. Inside the company, the launch post says, a sales Bot updates the CRM from call transcripts and drafts follow-ups, an operations Bot processes invoices that arrive in Gmail, and an engineering Bot reproduces a bug, files the ticket, and hands the fix to another Bot. Each of those is a chain of small writes into systems of record. The permit run is the construction version of the same chain, and the writes are into a city's records instead of a CRM.
The feature contractors will notice first is the routine. A user runs a job once with the Bot watching, corrects it, and the Bot saves the sequence and runs it on its own next time. That is how the permit run becomes repeatable: the portal, the form fields, the document to attach, and the confirmation page to save are learned from one supervised pass. It is also how a mistake becomes repeatable. A routine learned from a run where the wrong parcel number was accepted will file the wrong parcel number on schedule.
Why the roofing test is revealing
Construction administration is full of work that is easy to describe and awkward to automate. The permit address starts in one system. The inspection form lives on a city website. Measurements arrive as a PDF. The proposal belongs in an estimating tool. The signed subcontract and COI need to land in the correct record. A conventional integration project has to wire each edge separately. A computer-using agent can attempt the handoffs through the interfaces employees already use.
Foulger's thread is a self-reported early test, not an independent production benchmark. It does not establish error rates, total supervision time or what happens when the permit portal changes. It does show why contractors are interested. The job crossed documents, websites, email and judgment gates without requiring a purpose-built workflow for every step.
A permit is a legal act, not a form
Pulling a building permit is not data entry. In most jurisdictions the application is made under a contractor's license, the licensee attests to the accuracy of the application, and the permit carries obligations: inspections at named stages, posting on site, and expiry if work does not start. An application filed with a wrong scope or a stale insurance certificate is the licensee's problem, not the software's. That is the frame in which Foulger's two days should be read. The Bot filled out and submitted forms. The contractor remained the applicant of record, and the value of the run depends on what he checked before he let it submit.
The same applies to the inspection booking and the insurer notices. An inspection booked for the wrong day costs a crew a morning. A notice to an insurer is a statement the policyholder is making. None of that argues against the tool. It argues for the approval step the product already offers, placed before the external write rather than after it.
A plumbing company put it between six systems
Jon O'Neill, who owns a plumbing and drain company, posted on August 12 that he was using the Bot "to automate a ton of office manager work." In replies he named Gmail, Slack, ServiceTitan, and Quo, the texting tool his office uses for appointment times. He also said credentials "are generally speaking shared across all the agents." The value he described was continuity: one agent carrying a request through systems that each hold only part of the answer.
On August 23, Curt Mills said he was using more than 30 agents for administrative work at a midsize general contractor, with Slack bridges between some of them. His post offers less detail about individual runs, so read it as an adoption report, not as proof that any one workflow is reliable. The three accounts put the first construction users on coordination work.
Give the first Bot a narrow desk
The best starting assignment has a clear inbox, a repeatable path and a finished artifact that a person already knows how to check. The product documentation makes the same point in different terms: give each Bot a distinct job, the tools and sources it needs, and an explicit approval boundary.
Assemble a morning list of new bid invitations, deadlines and missing documents, with links back to every source.
Compare insurance requirements with the COI on file and draft the broker request when they differ.
Prepare an inspection packet from the approved permit set and leave submission to the project manager.
Reconcile a supplier order against the approved estimate and flag substitutions or quantity changes.
Collect closeout documents, name the missing items and draft follow-ups without sending them.
Assemble, compare, prepare, reconcile and collect can all end at a review screen. Sending a subcontract, changing a schedule, committing a purchase, filing with an authority or answering a contractual question should require a named person. A good routine records what the Bot read, what it changed and which step is waiting for approval.
One computer means one security boundary
SpaceXAI's documentation is direct about the shared machine: files, browser sessions and app logins placed on it are available to every Bot on the account. Creating a second Bot does not create a second security boundary. A contractor that mixes estimating, payroll, safety and customer systems on one machine should assume every Bot can reach the same signed-in environment unless the connected service enforces narrower permissions.
Grok Bot signs users in through Cursor accounts, and its data settings follow the Cursor account. Cursor's getting-started guide tells users to sign into websites themselves and warns against pasting API keys or credentials into chat or ordinary files. Connectors are preferable when they provide scoped access and an audit trail. Browser control is useful for the long tail of construction portals, but it should start with a limited account, test data where possible and approvals before any external write.
Who can get it, and what it costs
Grok Bot launched in early beta on August 11 for SuperGrok, SuperGrok Plus, and SuperGrok Heavy subscribers, and for Cursor Pro, Pro Plus, Ultra, and Teams plans, on desktop and iOS, with an enterprise waitlist. Its usage is metered separately from the Grok and Cursor plans it comes with, so work handed to a Bot does not draw down the user's chat allowance. Early users on X spent the first week working out which plan unlocked it, since two different subscriptions at two different prices both do. For a contractor, the practical reading is that access runs through an individual subscription, not a company contract, and the account that signs in is the boundary the company gets.
This draft took the same route
ConstructionMagazine.ai used its own remote editorial interface to place this article in the CMS. The agent found the site through llms.txt and OpenAPI, requested a short-lived editing claim, and waited for a Google-authenticated editor to approve it. The first token could upload the hero, create the draft, and save revisions, and nothing more. Publishing this revision took a second claim in which the editor granted the approve and publish scopes by name. The boundary moved because a person moved it, and the record shows who.
Contractors already have software that stores the permit, work order, COI, estimate and change order. Grok Bot is aimed at the handoffs between them. The test is whether it can leave a record clear enough for the estimator, project manager, controller or superintendent who signs next.
Give the first Bot one desk and one inbox, and name the person who owns its output.
Sign into portals yourself and keep the Bot on a limited account with no payment method attached.
Put the approval step before any filing, sending, or purchase, and keep it there until the routine has run clean for a month.
Read the confirmation page after every external write, and save it to the project record.
Assume every Bot on the account can see every file and session on the shared computer, and keep payroll and customer systems off it.