The mobile locksmith who is also the office: night lockouts, day records.

A solo locksmith cannot be at a door and at a desk at the same time, and the lockout trade puts the doors at night. What suffers is the record: a verification field skipped at one in the morning, a receipt never sent, an order from a property manager left unanswered in the inbox. None of it is urgent at two o'clock. All of it matters by nine.

A small set of assistants can work that morning shift. One checks last night's job log for gaps and hands each gap back to the person who did the job; another turns a property manager's rekey request into a reply and a unit-by-unit tracker; a coordinator posts the morning list. Every email to a customer stays a draft for the locksmith to send, and no assistant completes a verification field, decides who may enter a property or takes a call.

Take an illustrative locksmith who works alone from one van. At half past seven in the evening he makes a replacement transponder key for a driver who has lost every key to her car. At twenty to eleven he opens a house for a tenant locked out after a late shift. At ten to two he opens a car in a hospital parking lot for a nurse whose keys are inside it. Between jobs he logs each one on his phone, in a job-log form he designed himself.

When he gets home, an email is waiting from a property manager: the owner of a twelve-unit building has changed, and every unit needs rekeying before new keys go to the tenants. The night's three entries are mostly complete. Mostly is the problem. In a trade where the record of who asked for a door to be opened is the company's protection, a half-finished entry is worth less than it looks.

The one-man army model gives each recurring office job to a named Bot with a single role, and leaves every decision with the owner; the pillar article on running AI departments sets the model out in full. For this locksmith the roster is three Bots he creates under Aevrion's pattern: a Log Bot, an Orders Bot and a Morning Desk Bot that coordinates the other two.

The Bots run on Grok Bot. Each one the locksmith creates carries a name, a single job and a separate thread of conversation, and all three use the same persistent cloud computer, with its browser, stored files and terminal. One Bot can message another and pass a task across, and up to six can sit in one group chat, posting and handing work along in a single thread. Nothing in the documentation covers phone calls or text messages, so no Bot here ever reaches a customer by phone; any email a Bot prepares lands as a draft for the locksmith to check and send.

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 Log Bot runs as a routine on a weekday-morning schedule, well clear of the documented minimum of five minutes between scheduled runs. It reads an export of the job log that the locksmith saves to the Bots' shared workspace, in which identity fields show only whether they are filled; the full log, with any identity details, stays in his job system. Producing that export automatically from field-service software would be a custom integration or supervised browser use where the vendor permits it, subject to testing. It compares each of last night's entries with the list of required fields the owner wrote, and returns a short table: the job, the empty or inconsistent field, and who can close it.

The rule that matters most is given to the Bot as a lasting rule to remember: it never fills in a verification field. A remembered rule steers a Bot but is not a technical lock, so the owner also reads every gap list rather than trusting it. Only the person who stood at the door completes that part of an entry, from what was captured on site. If something was not captured, he records that it was not, and why. An entry repaired from memory the next morning is exactly the record that fails when a complaint arrives. Any applicable legal requirements need to be confirmed with a qualified adviser.

At the parking-lot job the locksmith photographed the customer's driving license instead of copying the number by hand. Whether a locksmith keeps images of identity documents at all, for how long and where, is a decision for the owner to make with legal advice for his own state; it is not a filing question. Until that policy is written, the Log Bot's instruction is to report from the export that an image is attached and do nothing else: the image stays in the job system, and no Bot reads, copies or moves it.

The shared computer makes this sharper. Every Bot on one account uses the same computer, with its files and sign-ins, and separate Bots are not a security boundary. An identity image left in a folder those Bots can reach is reachable by all of them, including any Bot later created for marketing. If the owner decides to keep such images, they belong under a separate user account, or outside the Bots' computer altogether.

While the Log Bot works, the Orders Bot reads the property manager's email and prepares two things. The first is a reply for the locksmith to review, asking for what the job needs before any van goes out: written authorization from the management company naming the building and the units, the person who may approve changes, how tenants will be told and given access, and how the new keys should be handed over and signed for. The keying itself, including whether the units stay on separate keys or share a master, is the locksmith's design to agree with the manager, not the Bot's.

The second is a tracker with one row per unit, which the Orders Bot keeps up to date as the locksmith reports progress: authorization received, access arranged, rekeyed, keys handed over, receipt signed. A row cannot be marked rekeyed while the authorization column for it is empty. The Bot drafts the confirmation emails as each day's units finish; the locksmith sends them.

The Morning Desk Bot is the coordinator: in a group chat with the Log Bot and the Orders Bot, it posts the morning list and assigns follow-ups, which the documentation's own example of a coordinator in a group allows. A supervising chief-of-staff Bot is not a documented product feature; this one only reads what the other two report and writes a summary for a human. Its list for this morning has four lines: two gaps for the technician to close, one receipt held for the owner, the property manager's reply ready to review, and the date the company's Advanced Verification details were last checked.

The group has its own documented edges. Drafts, approval requests and login requests never appear in a group, so the receipt and the property-manager reply wait in the Orders Bot's own conversation with the locksmith. Handoffs posted to a group are text-only, so no handoff carries an image, least of all an identity document. And his Bots can message each other directly; Cursor's help pages say no switch turns that off.

The calendar a locksmith forgets is the one that does not ring. California's licensing bureau, for one, issues a locksmith company license for two years, as its FAQ said on 16 October 2026; other states set their own terms. Google's Advanced Verification policy, which it applies to locksmiths advertising in the US and Canada, says re-verification may be requested once every twelve months. The Morning Desk Bot carries each of these dates from a file the owner keeps, and the garage-door article on running the office from the driveway shows how the verification folder itself is prepared for a technician who also runs the office.

A good morning ends with the next night a little easier. The house lockout's blank field shows that the phone form lets an entry be saved without it, so he makes it a required field. The parking-lot photo shows he has no written position on identity images, so he writes one, after advice, and tells the Log Bot what it says. The property manager's units are booked across two afternoons, with the authorization in the tracker before the first van leaves.

Approval timing decides when the Bots work. An approval request raised by a routine, with nobody watching, lapses after roughly ten minutes (Cursor's help pages say thirty) and the step it guarded is skipped. So the routines that run before he wakes only read and prepare; any step that needs his yes is one he asks a Bot for himself once he is up. The documentation describes no automatic alert when a routine fails, so the first thing he opens with his coffee is the morning list, and if it is missing he looks at the routine's run history before anything else.

Before any Bot exists, put the morning-after check through the workflow automation readiness assessment. It is free, open without registration, and looks at a single workflow at a time across twelve fixed dimensions, from how often the work repeats and how clear its rules are to how many exceptions it throws up and who owns it. The verdict comes back at once as one of four (not ready yet, standardize first, a good automation candidate, a high-leverage candidate), with the blockers named and a next step. Weak marks on rule clarity, ownership clarity or security and compliance readiness put a ceiling on the verdict.

For a solo locksmith the likely weak spots are easy to predict. If the required fields have never been written down, rule clarity will be the low score; if nobody is named to close a gap, ownership clarity will be. Once that check scores well, Aevrion Ops can help design the three Bots, the owner's field list and the rules around identity images in a scoping conversation.

1. For a mobile locksmith, the night's lockouts produce the records the morning has to check.
2. A Log Bot compares each entry with the owner's required-field list and hands every gap back to the technician; it never completes a verification field.
3. Identity-document images wait for a written owner policy, and never sit where every Bot on the account can reach them.
4. A property manager's rekey order becomes a reply draft asking for written authorization and a tracker with one row per unit.
5. A coordinator Bot posts the morning list to a group; drafts and approvals stay in each Bot's own conversation, and group handoffs carry no images.
6. Routines that run before the owner wakes only read and prepare; any step that needs his yes is one he asks for once he is up.