Opening season with one pool tech: a full route and a wave of openings.

Consider, as this article's illustration, an owner who is also the company's only technician. They carry one hundred and twenty weekly accounts, and this spring eighty customers want their pools opened, all within the same four weeks. The weekly stops are fixed by day and by street; the openings are one-off, longer, and every customer would like theirs first. Nobody can do that much planning at the end of a route day with wet hands, so the question is which parts of it can be prepared in advance.

One owner, several narrowly scoped Bots and no decision handed over: that is the one-man army model, set out in its pillar article. What follows is the season as it runs: the arithmetic, the wave plan, the Bots, the morning sheets, the parts and the evening summaries.

In the illustration the route runs five days a week, about two dozen stops a day, each day covering one part of town. Eighty openings over four weeks is twenty a week, or four a day if they spread evenly, which they will not: the early requests bunch up, a cluster of late ones arrives in the third week, and the owner expects some pools to need a return visit once the water has had a few days. By the owner's own estimate an opening takes several times as long as a weekly stop, so four in a day is a second shift.

The constraint the owner writes down is short. Each opening goes on the route day that already passes its street, no day takes more openings than the owner's cap, and a request that cannot fit before the customer's date goes to the owner rather than being squeezed in. That rule is what the assistants apply, and the owner can change it on any morning.

The wave Bot owns the plan. A routine on it runs on Sunday evenings: it reads the list of opening requests and the route-day list exported from the company's route software, applies the owner's rule, and drafts next week's wave, showing each opening against the day it joins, each day's total, and every request that did not fit. Getting those lists out of the route software is a custom integration or supervised browser use where the vendor permits it, subject to testing. Both lists are pulled fresh on every run, since a remembered copy is exactly what the docs say not to trust in place of the record.

The routine prepares and stops. It confirms nothing with customers and moves nothing in the software. Every yes in the wave is the owner's, given in the wave Bot's conversation. On Monday morning the owner reads the plan, moves the two openings they know will be awkward, and asks the wave Bot for the confirmation emails, each an editable draft the owner sends or discards.

1. 01

   Requested

   Owner

   The customer, then the wave Bot

   Advances when

   The request appears in the export and is matched to a route day

2. 02

   Placed in a wave

   Owner

   Wave Bot

   Advances when

   Sunday's draft puts it on a day under the owner's cap

   Ends when

   If it cannot fit before the customer's date, it goes to the owner's list instead

3. 03

   Confirmed

   Owner

   The owner

   Advances when

   The owner sends the confirmation draft

4. 04

   Opened

   Owner

   The owner, as technician

   Advances when

   Equipment started and first readings logged at the pool

5. 05

   Parts or return visit

   Owner

   Parts Bot, then the owner

   Advances when

   Missing parts drafted into an order; a return visit placed in the next wave

6. 06

   On the weekly route

   Owner

   The owner

   Advances when

   The pool joins its route day's regular stops

   Ends when

   The last summary is sent and the opening is closed

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.

In Grok Bot each assistant carries a name, a job and a conversation of its own, and the four here share a single persistent cloud computer equipped with a browser and a file system. Routines run on a schedule, at least five minutes apart. Bots can sit together in a group chat of two to six, where they post and pass work among themselves, and a Bot can send an asynchronous message straight to another Bot, with the handoff visible. Cursor's help pages say no switch turns off messaging between Bots; a Bot follows instructions about it. The documentation describes no phone calls or text messaging, so customers who ring still reach the owner.

Following Aevrion's pattern, the owner sets up four: the wave Bot, a day-sheet Bot that prepares each morning's sheet, a parts Bot and a summary Bot. In the documentation's example of a group, a coordinator can assign work; here the wave Bot takes that seat, posting the confirmed week and handing each day to the day-sheet Bot. The docs describe no supervising Bot that makes decisions for the rest, and the wave Bot makes none.

The group never shows approval cards, sign-in requests or email drafts; each confirmation, order and summary is handled in the conversation of the Bot that drafted it. Group handoffs are text-only for now, so when the summary Bot needs the parts Bot to look at the owner's photo of a cracked lid, it sends the image to that Bot directly rather than through the group. All four also share one computer and its sign-ins, so nothing the owner would keep from one Bot is saved there for another.

At six each morning a routine on the day-sheet Bot drafts the day: the fixed stops in their usual order, the openings inserted where the street fits, each customer's notes from the record, and the owner's own notes from closing each pool last autumn. It is a sheet, not a change to the schedule; the owner reorders it over coffee if the weather or a supplier says otherwise.

Opening season is also when chemical containers come out after months in storage. CDC's 2019 injury report, read on 16 October 2026, found that about two-thirds of the emergency department visits it estimated fell between Memorial Day weekend and Labor Day, and that patients were most often hurt by breathing in fumes or dust, particularly while opening containers. Its prevention advice includes reading the whole label or safety data sheet first, wearing goggles, gloves and a mask, working where ventilation is good, and opening one container at a time and closing it before the next.

So the top of each sheet carries the owner's handling rules, written once from that advice and reproduced word for word every day. The day-sheet Bot copies them; it does not adapt them, add to them or decide which apply at which pool. What goes in the water at each opening is the owner's decision as technician, made at the pool.

Openings find the winter's damage: a cracked lid, a gauge that reads nothing, a perished seal, a pump that will not prime. The owner notes each one, with a photo, in the parts Bot's conversation. The parts Bot keeps a running list priced from the owner's price list and, on Tuesday and Friday mornings, drafts one consolidated supplier order, each line tied to the pool it is for.

Buying appears on the documentation's list of steps to keep behind a clear approval line, and the parts Bot's lasting rules say the same in the owner's words. A remembered rule guides a Bot rather than locking it, and whether a given step stops for approval depends on the tool, its risk and the rules in force, so the owner treats the approval card as the real control: each order is answered with Allow once, and no standing rule is saved. The order is approved in the parts Bot's own conversation while the owner is there to answer, any payment on the supplier's site is handed to the owner through a takeover, and an approval never reverses an order that has already gone. Cursor's help pages add that a card saved in the Bot's Vault can be used at checkout without asking each time, so this design saves no card there.

Every opening and every weekly stop in this illustration ends with a short note for the customer: what was done, the readings, anything the owner noticed. The summary Bot drafts them each evening from the day's records while the owner is in its conversation. Where summaries are emailed, each is an editable draft the owner sends or discards. Where they are posted to the customer's page in the route software, through a custom integration or supervised browser use where the vendor permits it, the owner adds a narrow approval rule for posting there, so each post stops on a card offering Allow once, Always allow or Deny.

The documentation's advice is to start with read-and-prepare work and add approved actions or routines once the results are reliable. For the first weeks of the season the owner reads every summary and answers every card with Allow once. Only when the drafts have been right week after week does the owner consider Always allow, and then for a narrow match: a routine weekly-stop note with every reading inside the owner's range and nothing else attached. A summary that mentions an out-of-range reading, a part, a gate or a drain cover is kept outside that rule, and the owner reads it every time. The documentation describes that automated review as model-based, a complement to explicit boundaries rather than a replacement, so the owner still spot-reads the notes the rule lets through.

In week four the wave thins and the return visits take its place. The Sunday draft puts every return visit first, then the remaining openings, and shows on one line the requests that still cannot fit before their customers' dates. Those go to the owner, who decides whether to work a Saturday, offer a later date or decline the job. The routine never makes that trade-off; it only shows it.

When the wave ends, the opened pools simply join their route days, and the owner switches the wave routine off until the autumn closings, which follow the same pattern in reverse. What the season involved is now on record: which weeks went over the cap, which parts kept coming up, which customers asked late. That is the raw material for next spring's rule.

For an owner-technician looking at next spring's wave, the workflow automation readiness assessment is a sensible first step. It costs nothing and asks for no email address. Choose opening-wave scheduling as the single workflow and score it across the twelve fixed dimensions; the result comes back at once as one of four outcomes, listing what held the score down and a next step. If the cap, the route-day rule and the late-request rule still exist only in the owner's head, rule clarity will score weakest, and a weak score there caps the result. Aevrion Ops can then help plan the four Bots, the written rules and the link to the route software, which depends on what the vendor allows and on testing.

1. Openings stack on a route that cannot move; the assistants' job is sequencing one-off visits around fixed ones.
2. A Sunday routine drafts next week's wave against the owner's written cap and route-day rule, and confirms nothing.
3. Each morning's sheet carries the owner's handling rules, written from CDC's advice; what goes in the water stays the owner's decision.
4. Parts orders are drafted in one place and wait for the owner's approval on every card, and payments go through a takeover.
5. Visit summaries start with Allow once on every card; any later Always allow rule is narrow and leaves out safety notes.
6. Four Bots share one group for handoffs, while approvals and drafts stay in each Bot's own conversation.