A two-tech alarm dealer, three Bots, and the systems no Bot touches.

Consider an alarm dealer of two: an owner who sells, designs and installs, and one technician who installs and services. In this illustration their week holds five installs, two permit registrations in two different cities, and one false-alarm letter forwarded by a homeowner. That is enough paperwork to take every evening, and three Bots can prepare most of it, provided one thing is settled before any Bot exists: the systems no Bot ever touches.

Aevrion's one-man army article describes a small owner directing a few named AI assistants, each with one job, while keeping every decision. This page applies that model to a trade where part of the work cannot be handed to an assistant at any level of supervision, and follows the week from the line drawn on Sunday to the handover packs on Friday.

The company in this illustration installs monitored intrusion systems, video doorbells, cameras and smart locks for homeowners, with monitoring through a central station under a dealer program. It works in California, so the business holds an alarm company operator license from the Bureau of Security and Investigative Services, the owner is its qualified manager, and the technician is registered with the bureau as an alarm agent.

The installing pays. The evenings are where it goes wrong: Thursday's proposal still unwritten, two addresses in two cities with permit questions nobody has looked up, a motion detector on back order, and a letter from a city about an alarm the homeowner says she never meant to set off. None of that needs a license to prepare. All of it needs a licensed person to decide.

The owner writes two lists. The Bots' list: the job schedule, the parts sheet, the proposal template and price book, the permit tracker, and the public pages of the cities the company installs in. The people's list: the monitoring platform and its call lists, the panel programming software, the customers' alarm and smart-home apps, the camera feeds, and every code and passcode. Everything on the people's list stays on the owner's and the technician's own devices, and none of it is ever signed in on the Bots' computer.

The reason is one documented fact: every Bot on the owner's account works on the same persistent cloud computer, with the same files and browser sessions, and the documentation says separate Bots are not a security boundary. The guide to AI for alarm and smart-home installers sets out what follows from that; for this company it means the line is held by what never goes onto that computer, not by what the Bots are told.

A second user account, which the documentation describes for work that needs its own computer and credentials, changes nothing here: the protection systems get no assistant on any account.

Based on the Grok Bot documentation at docs.x.ai as checked on 15 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.

The owner creates three Bots under Aevrion's pattern. Proposal drafts from the survey summary the owner writes and the price book, reading the prices fresh each time. Permits looks up each install address's alarm rules and keeps the tracker. Schedule drafts the install sequence from the job board and parts sheet. On Monday morning the owner puts all three in one group chat (the documentation permits between two and six Bots in a group) and asks Schedule to post the week's plan and hand the open questions to the other two; a coordinating Bot in a group can assign work.

Handoffs between Bots in a group are text only, so Schedule's plan is a list of jobs, dates and blockers. Cursor's help pages say no switch turns off messaging between Bots; a Bot follows instructions about it. Drafts and approval cards never appear in the group. Every email the week needs shows up in the owner's own conversation with the Bot that wrote it, where he edits it and decides whether it goes.

The table shows what each side did for each job. The left-hand column is all drafts and checks; the right-hand column is all hands, codes and accounts.

Because no Bot can see the monitoring platform, nothing a Bot prepares can say that a system is protected. When the technician finishes testing a job, he tells the owner, and the owner marks it as monitoring live in the job system. That mark, entered by a person, is the only thing the Bots see the next morning. A job with no mark stays open on Schedule's list however many days pass, which is the right failure: the list nags a person rather than assuming anything.

Wednesday's and Thursday's jobs sit in different cities. Permits reads each city's published alarm pages with the browser on its computer, the supervised browser use the documentation describes for many web tools, while noting that sites can block automation or need a human step. For each address it records whether a user permit is required, who applies, how the number reaches the alarm company, the renewal cycle, and the link and date it checked. In the SIAC model ordinance the alarm user applies; each city's own text decides.

In this illustration the first city takes applications online from the homeowner, so Permits drafts a short email for the owner to send with the city's link and a request to forward the permit number when it arrives. The second city uses a signed form, so that draft points to the form instead. When the first number comes back, the owner, not a Bot, enters it into the monitoring account, since under the model ordinance that number is what the alarm company gives the police dispatch center. Permits records only that the number arrived, that it was entered, and by whom. The permits guide in this series sets out the tracker itself.

On Wednesday a homeowner from last spring's install forwards a letter from her city about a false alarm. The owner passes it to Permits, which files it with the job as the permits guide in this series describes and drafts a reply offering a service visit. Permits cannot see the event history in the monitoring platform, and it does not guess why the alarm went off.

The technician looks up the event history on his own device and visits on Friday. In this illustration he finds a back-door contact that no longer lines up with its magnet since the door was rehung. He realigns it, tests it with the central station and writes the cause in the job record. Whether to contest the letter is the homeowner's decision under her city's process; the owner tells her what was found. Schedule then drafts a one-page note on arming and canceling for the owner to send, in plain words and with no codes in it.

By Friday afternoon each job has a handover pack the Bots drafted: the device list, the user-guide sheet, the permit status for that address and the service contact. Codes and passcodes are not in it; the technician sets those with the homeowner at the keypad. The owner reads every pack against what was actually fitted, because the Bots know only what the job record says, and corrects the two where a device changed on site.

Thursday's job is still open: the second city's form has not come back, and the tracker shows it. Next Monday's plan starts from that open line and from the survey notes for the following week, not from anything a Bot remembers, because a Bot's memory, by the documentation's own account, is not an authoritative record.

If this week looks like yours, write down where last week's evenings went: each proposal, permit question, letter and handover pack, and whether it needed a licensed person's judgment or only their time. The items that needed only time are the ones three Bots would prepare. A scoping conversation through the contact page can start from that list, with the line around the security systems drawn first, as on Sunday. Aevrion Ops can design the three Bots, the lasting rules each is given and Permits' weekly routine, and connect the job system or parts sheet by custom integration where each vendor's API or terms allow it, once tested. The protection side stays out of scope from the first call.

1. In this illustrative two-person week, three Bots prepare proposals, permit research and install plans; people do every install, code and account.
2. The line is drawn before any Bot exists: monitoring, panel programming, customer apps, camera feeds and codes are never signed in on the Bots' computer.
3. The group chat carries the plan as text; every draft waits in the owner's own conversation with the Bot that wrote it.
4. Only a person can mark a job as monitoring live, because no Bot can see the monitoring platform.
5. Permit numbers are entered into the monitoring account by a person; the Bot records that it happened.
6. A false-alarm letter is logged and answered in draft by a Bot; its cause is the technician's finding and any appeal is the homeowner's choice.