One licensed irrigator, five hundred blowouts: an illustrated freeze season.

A sprinkler company with one licensed irrigator cannot put a second irrigator on the road mid-season. What it can control is sequence: which areas go first, which customers can wait, and what happens to the list when the forecast turns. Whoever is served last carries the most exposure to an early freeze, so the order is a judgment about risk, not a scheduling chore.

This article follows an invented company through one autumn to show where AI assistants fit. Everything about the company, its customers and its numbers is an illustration, made up to make the design concrete; it reports no result and stands for no real firm. In the One-Man Army model, an owner runs several small AI departments, each a named Bot with one job, and keeps every judgment for themselves. The pillar article explains the model; this one applies it to blowout season.

In the illustration, the owner is the company's only licensed irrigator. He does every blowout himself from a truck with a towed compressor, and a part-time bookkeeper handles the bank on Fridays. The winterization list holds five hundred residential customers. He has decided the season runs six weeks, six days a week, which works out at roughly fourteen stops a day before any rain day or callback.

That number only holds if the stops are close together. Fourteen blowouts across one subdivision is a long day; fourteen spread across the whole service area is impossible. So the list has to be built around places, not around the order in which customers happened to ask.

The owner already has a customer spreadsheet with addresses, last season's visit notes and each customer's preferred contact. It is the source of truth for everything that follows, and he exports it each evening into the shared folder on his Bots' computer.

Following Aevrion's pattern, the owner creates three Bots in Grok Bot. The Route Bot owns the winterization list and the booking drafts. The Forecast Bot owns a routine that reads the weather forecast for his service area. The Billing Bot turns finished stops into lines on an invoice sheet. Each Bot keeps its own conversation and role, but all three work on the same persistent cloud computer and read the same exported spreadsheet from its shared folder.

He puts the three into one group chat. Groups hold two to six Bots, and the documentation's own example has a coordinator in a group who can assign work; here the Route Bot plays that part. When the Forecast Bot sees a change, it messages the Route Bot directly, and the handoff is visible in the conversation. Cursor's help pages say no switch turns that Bot-to-Bot channel off; a Bot follows instructions about it.

The documentation also limits what a group shows. A group shows no approval requests and no email drafts, which keeps every customer email in the Route Bot's own conversation, where only the owner can send it. And handoffs between Bots in a group are text only for now, so if the Route Bot needs the Billing Bot to see a photo of a cracked valve box, it sends the image to that Bot directly; the owner's own messages in the group can still carry attachments.

The Route Bot coordinating the others is Aevrion's design built from documented parts. The documentation's Chief of Staff example is a digest that briefs a person; a Bot that supervises other Bots is not a documented feature.

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 divides his territory into areas he can cover in a day and gives each one a weekday. The Route Bot reads the spreadsheet, places every customer in an area, and produces a draft calendar: which areas fall in which week, how many stops each holds, and which customers it could not place because an address is missing or sits outside every area.

For each area it then drafts one booking email: the two days the owner has set aside, a request to leave the controller accessible and the backflow assembly uncovered, and a line asking customers to reply if they will be away. The owner reads each draft in the Route Bot's conversation, edits it and chooses Send. Customers reply to the owner, and he adds any reply that changes a booking to the Route Bot's conversation as a note.

The Bot re-reads the spreadsheet every evening rather than trusting what it remembers; the documentation treats the source system, not what a Bot recalls, as the authority. Reaching a scheduling or field-service product instead of a spreadsheet would be a custom integration, or supervised browser use where the vendor permits it, subject to testing.

The Forecast Bot runs a routine twice a day, at times the owner picked; routines can be scheduled no closer than five minutes apart, which is no constraint here. It opens the National Weather Service forecast pages for the towns in his service area, records the overnight lows for the next several days, and looks for a freeze watch or a freeze warning.

The terms mean different things. The Weather Service's glossary describes a freeze watch as a sign that widespread freezing temperatures are possible but their occurrence, location or timing is still uncertain, and a freeze warning, issued during the growing season, as an expectation of below-freezing temperatures over a large area for an extended period (as checked on 16 October 2026). Because warnings belong to the growing season, the overnight lows the routine records carry the signal late in the year. The routine records which one, if either, appears for each town, with the link and the time it read the page.

When something changes, the Forecast Bot sends the Route Bot a short message: which towns, which product, which nights. The Route Bot then posts a revised layout to the group showing the areas still waiting, nearest freeze first, and drafts, in its own conversation, a notice to any customers whose day would move. The routine itself never changes a booking and never sends anything. If the forecast page cannot be opened, the note says so plainly instead of repeating yesterday's numbers.

There is no automatic retry and no failure alert in the documentation. The owner checks the Forecast Bot's run history each morning before he leaves, because in this season a routine that quietly failed is the worst kind of silence.

A forecast that brings the first freeze forward by four days leaves the same number of stops and fewer days. Somebody moves to the back. The Route Bot can show exactly who: the areas that would now fall after the forecast freeze, the customers in each, and anything the owner noted against them last season.

Deciding what to do about it is not a scheduling task. In the illustration the owner has given the Route Bot his own priorities as lasting rules before the season began: customers who have told him they will be away all winter move earlier, customers he has rescheduled once already are not moved again, and an area is never split across a week unless he says so. Those are his judgments about his customers' systems, not rules this article can supply, and a remembered rule guides the Bot without enforcing anything. The Route Bot proposes an order that follows them and marks every place where they conflict. He settles each conflict himself.

What the late customers are told is also his. The Route Bot drafts a plain notice: the new date, the reason, and an invitation to reply if the date is impossible. It never says a system is safe until then, never estimates what a freeze might cost and never offers advice on draining a system themselves. If the owner wants to give that advice, he writes it.

Between stops the owner dictates a line into the Billing Bot's conversation from his phone: the address, done or not done, and anything he found, such as a head that will need replacing in spring. The Billing Bot matches the address to the spreadsheet, applies the owner's own winterization price and any extras he named, and adds a line for each finished stop to an invoice sheet, a file it keeps in the shared folder.

Each evening it posts a summary to the group: how many stops reached the sheet, which notes it could not match to a customer, and which mentioned a repair. The owner checks the sheet in the Billing Bot's own conversation, corrects it, and raises and sends the invoices himself from his invoicing software. Having the Bot enter them there would be a custom integration, possible only where the vendor's API or terms allow it, and only once tested. Taking a payment is never the Bot's step; the documentation routes payment confirmations to a human takeover of the computer. 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.

The repair notes are the quiet value of the season. A head the owner flagged in October is a spring repair already listed, which is where the company's next wave begins.

The season does not end on a date; it ends when the last area is cleared or the owner calls it. At that point the Route Bot drafts a short note to anyone still unserved, explaining what happened and what the owner proposes, and the owner decides whether it goes. The Billing Bot lists unpaid invoices for the bookkeeper. The Forecast Bot's routine is paused, since the documentation lets an owner pause a routine and restart it next year rather than deleting it.

Before the truck is put away, the owner asks the Route Bot for one more file: every customer whose notes mention a fault, grouped by area, as the opening draft of the spring start-up list.

The workflow to examine first is the winterization booking itself. The workflow automation readiness assessment takes one workflow, scores it on twelve fixed dimensions and returns a result straight away, with the blockers it found and a next step; it costs nothing and asks for no sign-up. Expect exception frequency to score low if every forecast reshuffles the list by hand, and rule clarity to score low if the priority rules have never left the owner's head, which caps the result. When the result points to a starting Bot, Aevrion Ops can design with you the group, its approval points and any custom integration the vendor's API or terms allow, once tested.

1. With one irrigator and one compressor, the blowout season is a sequencing problem, and the customer served last carries the freeze exposure.
2. Customers are grouped into areas with set weekdays, and each area's booking email is a draft the owner sends from the Route Bot's conversation.
3. A twice-daily forecast routine records freeze watches and warnings and messages the Route Bot; it never moves a booking or contacts a customer.
4. The owner's written priorities guide the proposed order, conflicts are marked, and the owner decides who moves and what they are told.
5. Dictated stop notes become lines on an invoice sheet the owner checks before he invoices, and the repair notes gathered in autumn seed the spring start-up list.