AI for landscaping and hardscaping companies: proposals, crews and updates.

For a landscaping and hardscaping company that designs and builds, two things eat the margin quietly. The first is the revision cycle: each change a client asks for touches a dozen proposal lines, and rebuilding them by hand is evening work for the person who also draws. The second is the trigger nobody priced: a patio that grows past an area threshold or a wall that turns out taller than it looked, either of which can bring a permit, a stormwater form or an engineer into a job quoted as simple paving.

The clerical half of both can be carried by supervised AI assistants. Working from the designer's own line items and the owner's own price sheet, they can rebuild the tiered proposal after each round, compare the scope with the owner's written list of permit triggers before anything is sent, prepare the locate details before planting or digging, draft supplier orders for approval and draft the weekly note to each client with a build in progress. They do not design, price, decide whether a wall needs engineering or file anything with a building department. This page is the overview for the trade; two companion articles go deeper, one on an owner-designer's season and one on the permit triggers themselves.

A revision rarely changes one thing. Widening a patio by a few feet changes excavation, base, bedding, pavers, edge restraint, joint sand and haul-off, and it changes the total of new hard surface, which some jurisdictions measure. Swapping lawn for planting beds rewrites the plant list and often the irrigation lines. The table shows how far four common requests reach in an illustrative proposal; it is Aevrion's example, not a rule of the trade.

Revisions also move the permit picture. A wider patio raises the running total of new hard surface, a taller seat wall may change how a wall is measured, and new beds add digging areas for the locate request. In Aevrion's pattern the proposal is therefore never rebuilt without the trigger check running on the same version; how an owner-designer gathers changes into rounds is the subject of the companion article.

Grok Bot, the agent product underneath this design, is built around named Bots: durable assistants, each with a name, a job and a conversation of its own. Their workplace is a persistent cloud computer, with a web browser, storage for files and a terminal. Every Bot on an account shares that one computer, its files and its browser sign-ins, and the documentation is plain that separate Bots are not a security boundary. A landscaping company's supplier accounts, design files and client folders would all sit on the same machine, so what goes onto it is the owner's decision.

The documentation describes no telephony: a Bot does not take or return calls or send text messages, so an inquiry reaches it only as something already written down, such as a web-form email, the owner's call notes or the client's photos. Connecting design software, a nursery's ordering system or a field-service tool needs a custom integration or supervised browser use where the vendor permits it, subject to testing; an integration is built only if that vendor's API or terms allow one. Sites may block automation, and passwords, two-factor codes and payment confirmations go back to a person 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.

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.

Tiered proposals suit design-build work because a client choosing between a patio alone, a patio with planting and lighting, and the whole garden is choosing scope, not haggling over a number. Under Aevrion's pattern the owner creates a Proposal Bot that works from the designer's take-off: a spreadsheet of line items, each tagged with the tier it belongs to. The Bot assembles each tier in the company's own proposal format, carries quantities across and lists what changed since the last version.

Prices come from the owner's price sheet, read afresh for every draft. The documentation tells users not to treat what a Bot remembers as authoritative, and to keep facts that change in their source system; a paver price remembered from spring is exactly that kind of fact. A line the price sheet does not cover is listed as missing, not guessed. The output is something a person can check line by line: a spreadsheet with defined columns, and a proposal document that names the take-off rows it came from.

What goes in each tier is the designer's decision, the price is the owner's, and the proposal reaches the client only when the owner sends it. A Bot can show an email draft in its own conversation, with recipients and body, and the owner chooses Send or Discard.

Some hardscape scope crosses lines that a building or planning department draws. In Portland, Oregon, a retaining wall taller than four feet, counted from the underside of its footing up to its top, or one that holds back a surcharge, needs a building permit, and above four feet the city wants stamped drawings and calculations by an Oregon-registered engineer (as checked on 16 October 2026). In England, a hard surface of more than five square meters between the front of a house and the road needs planning permission unless it is laid in porous material or its run-off is led to a permeable part of the garden.

Neither rule travels. Each jurisdiction sets its own thresholds and measures them its own way, and its building or planning department decides what applies to a given job. An assistant can compare a proposal's scope with a list the owner has written for each place the company works and flag anything that might cross a line before the proposal leaves. It flags; it never rules. The permit-trigger article in this series sets out that check, with worked examples from Portland, a Pennsylvania municipality and England.

In the United States, the 811 service run as a Common Ground Alliance initiative says a locate request should go to 811, or through the state center's website, a few business days ahead of any digging, and it names planting trees and shrubs among the ordinary projects that need it (as checked on 16 October 2026). A request needs the address with its county and nearest cross street, the type of project and the exact area on the property where digging will happen. The site also advises waiting until every utility has responded before breaking ground.

A signed design-build proposal already holds most of that. An assistant can draft the locate details from the planting plan and hardscape layout, marking each area where holes or excavation are planned, with the planned start date. A person submits the request and records the ticket in the company's own system, not in an assistant's memory. State rules on timing and marking differ, and the excavation guide in this series covers ticket tracking.

Once the client signs, the approved tier becomes the order list. The owner-designer article follows a Procurement Bot through that step, including a plant the nursery cannot supply; this page covers only where the approval boundary sits.

The boundary is the purchase itself. The documentation recommends explicit approval boundaries for purchases, and says an approval controls the proposed action without reversing work already done. Approval is not automatic either: the documentation ties it to the tool in use, how risky the action is and the owner's own rules. So the owner gives the Procurement Bot the boundary as a lasting rule and adds a narrow Ask first rule for orders, since a remembered rule guides a Bot without locking anything. Ordering through a nursery's or supplier's own system takes a custom integration or supervised browser use where the vendor permits it, subject to testing, and payment is the owner's step.

A company that builds gardens and then looks after them runs two calendars. Install work comes in multi-day blocks that depend on materials arriving and on ground dry enough to work; maintenance comes in recurring routes that clients expect on a set day. Weather pushes both, and a rained-off install week can tempt the owner to borrow the maintenance crew, which leaves route clients waiting.

An assistant can draft the week for the owner to settle: install days with their deliveries, maintenance routes, and every clash marked for a decision. Who moves is the owner's call, after talking to the crew leads. The companion article follows an illustrative owner-designer with two crews through that kind of season, to a maintenance agreement at handover.

The weekly note to each client with a build in progress is drafted the same way, from the job record and the photos the owner passes on, and only the owner sends it.

Grok Bot's guidance is to start small: give one Bot a whole outcome to own, and add a specialist only when a role has settled into something stable and separate. It suggests a separate Bot when work has its own goal, tools, working style, approval boundary or schedule. For a design-build landscaper the first Bot worth building is the one that owns the proposal, because every later step reads from the signed version of it.

Once there are three or more, Grok Bot allows a group chat of between two and six Bots, so proposal, procurement and scheduling work can share one visible thread. How that group is organized for a landscaping company is Aevrion's design, not a product feature.

A Monday routine that prepares the week's order list shows the limits. If it asked to place an order while the owner was setting out a patio, the request would expire after about ten minutes (Cursor's help pages say thirty) and nothing would be bought; a request in a chat the owner has open waits for an answer. Routine schedules must also sit at least five minutes apart, each routine keeps its twenty most recent run records, and the documentation promises no second attempt and no warning when a run fails, so the owner opens the history before trusting a missing list.

Each item below has a person's name against it in the Bots' lasting rules, and the assistants prepare around it.

• THE DESIGN

  Layout, plant choices and every revision belong to the designer. A Bot rebuilds the proposal around the drawing; it never redraws it.

• THE PRICE

  Prices and tier contents come from the owner, through the price sheet, every time.

• ENGINEERED ELEMENTS

  Only a licensed engineer or the building department can say whether a wall or slope must be engineered.

• PERMITS AND PLANNING

  Applications, drawings and signatures are submitted by a person. An assistant flags possible triggers and tracks status.

• GRADING AND DRAINAGE

  Any change to where water goes, above all toward a neighbor, is decided by the owner with a civil engineer or the local stormwater authority where the job needs one.

• PURCHASES AND CHANGE ORDERS

  Orders and payments are approved by the owner, and a change to the signed scope is signed by the client.

• PLANT WARRANTY

  The terms, and every claim made under them, are the owner's decision.

Take the last few signed design-build jobs and record, for each, the number of revision rounds, the evenings spent rebuilding the proposal, and anything found after signing that should have been in the quote: a wall that needed engineering, a stormwater form, a locate delay. That record shows whether the first Bot belongs on proposals, on the trigger check or on client updates.

Then score one workflow, the proposal revision round, in the workflow automation readiness assessment. It costs nothing, asks for no sign-up, scores that single workflow against twelve fixed dimensions and shows its verdict at once, naming what blocks the workflow and suggesting where to go next. Expect manual re-entry to score poorly if each revision means retyping take-off lines into the proposal by hand, and integration availability to turn on whether the design software can export its line items at all. With that in hand, Aevrion Ops can design the Proposal Bot, the trigger list and the approval points alongside the owner, and connect design or supplier software only if the vendor's API or terms permit, and only after testing.

1. Design-build landscaping loses time in revision rounds and money in permit triggers hidden inside patio and wall scope.
2. A Proposal Bot can rebuild every tier from the designer's line items and the owner's price sheet, showing what each revision changed.
3. Possible permit triggers are compared with the owner's written list for each jurisdiction before a proposal goes out; the building department decides what applies.
4. 811 asks for a locate request before any digging, planting trees and shrubs included; the assistant drafts the details and a person submits them.
5. Orders, payments, engineering, drainage changes and plant warranty decisions stay with people, and scheduled Bot work stops at a prepared list.