First site visit to maintenance contract: an owner-designer with two crews.

In a design-build landscaping company run by its designer, the design is the product and the designer is the bottleneck. Each revision waits for the owner's evening, and so does the proposal rebuilt around it, the order list, the client's weekly note and the maintenance quote at handover. This article follows one illustrative company through one backyard, from the first site visit to a signed maintenance agreement, and shows which tasks six assistants prepare and which stay with the owner.

The company, its crews, its client and its garden are invented for this illustration. They report no outcome and describe no real firm.

In this illustration the owner meets every prospective client, measures every site and draws every design. An install crew of three builds patios, walls and planting; a maintenance crew of two runs weekly and every-other-week routes. The office is the owner's kitchen table after dark.

The arrangement borrows from the One-Man Army pillar, in which one decision-maker hands every repeating desk task to a separate named AI assistant while keeping every decision. Here the owner creates those assistants as Bots in Grok Bot, under Aevrion's pattern, starting with the proposal.

All six Bots will share the account's one persistent cloud computer, so a supplier login one of them uses is open to the other five; the documentation says splitting work across Bots does not separate access. The crews have no access to the owner's Bots; their notes and photos arrive through the owner, attached in a conversation or saved to a folder the Bots can read. The documentation describes no calls or text messages, so a client who phones still gets the owner.

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.

Following the documentation's advice to keep the roster small, the owner adds a Bot only when a job needs its own approval point or timetable. In this illustration the owner ends the season with six, added in the order below, each with standing rules it has been told to remember. A remembered rule guides what a Bot does but locks nothing, so anything that must stop also gets an approval rule.

• QUALIFICATION BOT

  Turns each forwarded inquiry into a one-page brief: goals, the client's budget range, photos, slope and access notes, and questions for the first visit. It never tells a client whether a budget is enough.

• PROPOSAL BOT

  Rebuilds the tiered proposal from the owner's take-off after every revision, priced from the owner's sheet, changes listed first.

• PERMIT-TRIGGER BOT

  Compares each scope with the owner's written trigger notes for the garden's town and flags anything that might need a permit. It decides nothing.

• PROCUREMENT BOT

  Drafts orders from the signed tier and waits for the owner's approval before any purchase.

• CLIENT-UPDATE BOT

  Drafts acknowledgments during design, the weekly note during the build and the maintenance proposal at handover.

• COORDINATOR BOT

  Posts the crew week in a group chat and passes requests between the others. It is Aevrion's pattern built from documented group and handoff features, not a product feature.

The client in this illustration wants a patio, planting beds and lighting in a garden that falls away from the house. The model below follows that one job. The Bots prepare; every state that ends in a decision is held by a person.

1. 01

   Inquiry

   Owner

   Qualification Bot, from the email the owner forwards

   Advances when

   A brief with goals, budget range and open questions

   Ends when

   The owner declines a poor fit

2. 02

   Site visit

   Owner

   The owner

   Advances when

   Measurements, levels, sun, soil and access noted on site

3. 03

   Design

   Owner

   The owner, as designer

   Advances when

   A drawing and a line-item take-off saved to the shared workspace

4. 04

   Proposal

   Owner

   Proposal Bot drafts; the owner prices and sends

   Advances when

   Three tiers in front of the client

   Ends when

   The client walks away

5. 05

   Revision

   Owner

   The owner, as designer

   Advances when

   One list of changes per round, a redrawn plan and a rebuilt proposal

   Ends when

   The owner closes revisions and asks the client to choose

6. 06

   Trigger check

   Owner

   Permit-Trigger Bot flags; the owner decides

   Advances when

   Each flag cleared, priced as dependent, or referred to an engineer or the building department

7. 07

   Signed

   Owner

   The client

   Advances when

   A signed tier, with the deposit handled by the owner

8. 08

   Ordered and located

   Owner

   Procurement Bot drafts; the owner approves and submits

   Advances when

   Orders placed, the locate request made, deliveries on the crew week

9. 09

   Install

   Owner

   The install crew lead, reporting to the owner

   Advances when

   A walkthrough with the client

   Ends when

   Snag items closed

10. 10

    Maintenance

    Owner

    The client signs; then the maintenance crew, on a route slot the owner approved

    Advances when

    A signed agreement and a first visit from the visit sheet

    Ends when

    The client ends the agreement

The bottleneck shows first in revisions. In this illustration the client sends changes as they occur to them: wider steps one day, a different paver color the next, a question about lighting on the weekend. Each message would pull the owner back to the drawing board. Instead, the Client-Update Bot drafts an acknowledgment email for the owner to send and adds the change to the round's single list, and the owner sets the day each round closes.

When the round closes the owner redraws once and updates the take-off. The Proposal Bot rebuilds all three tiers and puts the differences at the top: lines added, removed and changed, and how far the middle tier now sits from the budget range in the brief. That last line matters most here: a client who discovers in round three that the garden has outgrown the budget may simply stop replying. Whether to offer a later phase, trim the scope or hold the design is the owner's conversation, not the Bot's.

Round two adds a retaining wall to level the patio against the fall of the garden. The Permit-Trigger Bot reads the new scope against the owner's notes for the town and flags the wall on two counts: its height, measured the way that town measures it, and what will sit above it. Rules differ by place; Portland, Oregon, for instance, wants a permit once a wall passes four feet measured up from the underside of its footing, or when it carries a surcharge (as checked on 16 October 2026). The garden here is in an unnamed town whose rules the owner copied from its building department's pages.

The flag answers nothing by itself. The owner asks the building department, and where engineering may be needed, an engineer decides whether and how the wall is designed. The proposal shows the wall as conditional on that answer, and the owner tells the client before anything is signed. The estimate-stage check itself has its own article in this series.

On signature the Procurement Bot drafts orders from the signed tier: plants by species, size and count, block and pavers by pallet, aggregate by volume, lighting by fixture. Its lasting rules say it never places an order, and the owner backs that with an Ask first rule for purchases, because approval is set by tool, by level of risk and by the rules the owner writes. The approval card offers Allow once, Always allow or Deny; for orders this owner uses Allow once.

The nursery in this illustration has its own online ordering system. Reading its availability and placing an approved order needs a custom integration or supervised browser use where the vendor permits it, subject to testing; login and payment steps are the owner's, through a takeover of the Bot's computer. Cursor's help pages add a Vault, where saved logins and cards let a Bot sign in and check out without seeing them, and no setting asks for approval each time a saved card is used, so this design saves no card there. An unavailable plant is listed with the nursery's note. Choosing its substitute is design work, so it goes back to the owner's drawing board.

If the owner is sitting in the Procurement Bot's chat, its approval card waits. If the card comes from something the owner did not start, a scheduled routine or a note from another Bot, it times out after roughly ten minutes (Cursor's help pages say thirty) and the order simply does not go; approving also never reverses work already finished.

A group chat holds all six Bots, the most a group can contain. Borrowing the documentation's own group example, where a coordinator hands out tasks, the Coordinator Bot posts the coming week every Sunday evening: the install crew's days with deliveries against them, and the maintenance routes. Nothing in the documentation describes one Bot supervising others; this coordinator posts and passes requests, Aevrion's use of documented pieces.

When rain is forecast for install days, the Coordinator Bot asks the Procurement Bot which deliveries could move and lists the options: keep the install crew on preparation, swap a day with a route, or push the job back. Bots can message each other and hand work on. Cursor's help pages say no switch turns that messaging off; a Bot follows instructions about it. Both crew leads talk the options through with the owner, who decides.

Approval cards and email drafts stay out of groups entirely, so approving and sending take place in each Bot's own conversation. A Bot's handoff into a group carries text alone at present, so a photo of the compacted base goes from one Bot to another in a direct message rather than through the group.

During the install, the Client-Update Bot drafts the client's note from the crew lead's notes and photos, which the owner attaches: what was built, what the crew starts next, which loads arrive when, and anything the client has to decide. The draft sits in the Bot's conversation with recipients and body until the owner chooses Send or Discard. It promises no finish date the owner has not set. When a plant has been substituted, the owner adds a sentence, as designer, on why the replacement suits the bed.

At the walkthrough the owner and the client go round the garden, and snag items go on a list the install crew lead closes. The Client-Update Bot then drafts a maintenance proposal from the as-built plant list and the hardscape laid: what the maintenance crew would do through the seasons, how often, and the plant warranty terms exactly as the owner wrote them. The Coordinator Bot proposes a route slot on a day the crew is already nearby.

Price, frequency and warranty terms are the owner's, and the client signs. On the first maintenance visit the crew leader works from a visit sheet drafted from the as-built list, and a garden that filled the owner's evenings is now a line on a route.

Choose the workflow that most often waits for your evening. For an owner-designer the candidates are the revision round, which eats drawing time, and the move from a finished install to a maintenance agreement, where a built garden can drift away unasked.

Score that workflow in the workflow automation readiness assessment. Anyone can use it without registering or paying; it weighs the one workflow on twelve dimensions, gives one of four results, lists what is holding the workflow back and proposes a next move. For the handover, expect ownership clarity to come out low if nobody owns the moment a finished garden becomes a maintenance client; a low score there caps the result. Aevrion Ops can then map the six desks against your own season, decide which Bot comes first and set the approval rules, and link nursery or scheduling software provided the vendor allows it in its API or terms and the link has been tested.

1. In an owner-designed landscaping company, the owner's drawing time is the constraint every Bot protects.
2. Client changes are gathered into revision rounds, and the Proposal Bot rebuilds every tier and shows how far it has moved from the budget.
3. A retaining wall or other possible permit trigger is flagged before the proposal goes out; the building department and an engineer answer it.
4. Orders wait for the owner's approval in the Procurement Bot's own conversation, and nursery systems need a tested custom integration.
5. The handover ends with a maintenance proposal drafted from the as-built plan, priced and sent by the owner.