Plant Nursery AI: Inventory Facts and Delivery Windows Before Launch

An AI agent can tell a plant nursery customer what is in stock only when it can see which plants are sellable today, which are already promised to another order, and when the next delivery can actually leave the yard. Most nurseries keep those facts in several places at once: a point-of-sale count, a propagation sheet, a grower's notes and a driver's text message. The work before any agent speaks for the business is deciding what each number means, who keeps it accurate, and which delivery promise the agent is allowed to repeat.

Key takeaways

• Split "in stock" into sellable, reserved, growing and not for sale, and give each state one owner.
• Write delivery windows as conditions with an order cutoff, a route group and a rule for weather or truck changes.
• Let the agent answer from a verified stock record and state plainly when that record is out of date.
• Keep holds, substitutions and delivery promises behind staff approval until the rules have been tested against real questions.
• Judge the agent by wrong stock answers and missed delivery windows, not by how many chats it handled.

Why "in stock" is not one number

A customer who asks whether a group of three-gallon lavender plants is available is asking a narrow question, but the honest answer depends on several different stocks. Plants on the sales floor may already be spoken for by a landscaper's pending order. Material in a shade house may be ready in a few weeks but not today. Some plants are on the bench but have not yet reached the size shown on the label.

If the agent reads a single total, it will overpromise. The first design decision is to separate at least four states: sellable now, reserved against a confirmed order, growing with a known ready date, and not for sale (damaged, diseased, or held for display or research). Each state needs a plain definition written by the person who runs the yard, because a sales lead and a grower often use the same word for different things.

Location matters too. A nursery with a main yard and a satellite site has two stock pictures, and an agent that blends them will tell a customer that plants are available a long drive away from where they are actually kept.

How do you build the inventory fact sheet before the agent touches it?

The fact sheet is the document the agent reads when a customer asks a stock or delivery question. It should be short enough that staff can check it in a few minutes and specific enough that two people would give the same answer from it. Build it in this order:

• Step 1: List every product family the agent may quote, with the unit the customer buys (flat, quart, three-gallon, bare root) and the size named on the label.
• Step 2: Assign one owner per state. The sales lead owns sellable and reserved quantities, the grower owns growing stock and ready dates, and the manager owns anything removed from sale.
• Step 3: Set a refresh rule. A count taken at opening is not a reliable count at four in the afternoon after a wholesale pickup, so the record needs a timestamp and a maximum age.
• Step 4: Write the reservation rule: how long a hold lasts, who can extend it, and what happens when a deposit is missing.
• Step 5: Record substitutions. If a customer accepts a similar cultivar, the agent needs to know what counts as equivalent and who approves the swap.
• Step 6: Attach a freshness marker to every answer, so the agent can say "as of this morning's count" instead of sounding certain about a number it cannot confirm.

The agent should read from this fact sheet at the moment of each question rather than relying on what it learned in an earlier conversation. Keeping the source of each answer visible is what makes a wrong answer traceable later.

Delivery windows are promises, not calendar dates

A delivery window like "Tuesday morning" depends on more than a day of the week. It depends on the order cutoff, the time the load is built, the route group that covers the customer's area, the number of stops ahead of them, and what the driver can do when frost, wet ground or a closed road changes the plan. In a spring rush, the same window can be honest on Monday and impossible on Tuesday.

For the agent to repeat a window, the dispatcher has to publish it in a form the agent can read: the zones served, the cutoff for each route, the window each zone receives, and the rule for rescheduling. If any of those pieces are missing, the agent should say what it knows and offer a handoff, not fill the gap with a guess. Perishable deliveries with fixed windows carry the same failure mode in other trades, and the logic is worth comparing with the approach described in Superintelligent Agents for Florists: Delivery Windows and Event Orders.

A delivery window the dispatcher has not published is a hope, and the agent should label it that way.

What can the agent say, and what must it hand to staff?

A decision guide keeps the agent's behavior predictable. Write it as a short table of rules in plain language, then test each rule with real questions before going live.

• The agent may state a sellable count taken from a verified record that falls inside the agreed refresh window.
• The agent may state a published delivery window for the customer's zone, with the cutoff that applies to the order.
• The agent may state a count from earlier in the day, but only with the time of that count and a clear note that it may have changed.
• The agent may describe growing stock and its listed ready date, but must say the grower has not confirmed it for a specific week if that is the case.
• The agent must hand to staff any hold, deposit exception, substitution, bulk order above the threshold the sales lead sets, delivery outside published zones, and any complaint about a dead or damaged plant.
• The agent must not state an availability or delivery date for any product family that is missing from the fact sheet.

Customers sometimes paste instructions into a chat, asking the agent to ignore its rules or to confirm a hold. The agent's rules about holds and exceptions should live in the configuration that staff control, not in anything a customer types. The OWASP guidance on prompt injection is a useful reference for this boundary.

Illustrative scenario: a spring weekend with one delivery truck

Illustrative: a nursery runs one delivery truck on Saturdays. On Thursday, the grower reports that a block of bedding flats is ready but not yet hardened off, so its ready date is the following Monday. On Friday evening, a contractor asks through the website chat whether a large order of bedding flats can be delivered to a job site on Saturday.

Without the setup described above, the agent sees a sellable count in an older export and a Saturday route with open space, and it says yes. With the setup, the agent sees that the flats are listed as growing with a Monday ready date, that the Saturday route closes at a published cutoff that has already passed, and that bulk orders go to the sales lead. It tells the contractor that the request needs a person to confirm, shares the cutoff and the next available route, and creates a handoff with the order details, the site address and the requested date. Nothing is promised, and the team reviews the request on Saturday morning with the grower's update in front of them.

How Be Human's managed approach handles this

Be Human starts with one useful role, in this case an inventory and delivery assistant, and defines what it needs before anything goes live: the memory it reads (the verified fact sheet and the published delivery windows), the tools it may call (read access to stock records and the route calendar), the approval boundaries (holds, exceptions and bulk orders go to staff) and an observable success criterion, such as stock answers that match the next physical count. Managed operations then keep that setup working over time. This includes monitoring of answer freshness, recurring evaluations against real customer questions, maintenance when the point-of-sale or dispatch tool changes, and periodic permission review so the agent keeps only the access it needs. The service is remote and available in English and Portuguese.

Checking the answers before customers rely on them

Before launch, collect a set of real questions from the past few weeks of calls, emails and chats. For each one, write the answer a staff member would give from a verified count, and mark whether the agent should answer or hand off. Run the agent against that set, compare the results, and fix the fact sheet or the rules where the answers differ. Repeat the test after every change to the stock process, because a rule that was correct in one season can be wrong in the next.

Keep a log that records, for each answer, the stock record and timestamp it used. When a customer receives a wrong answer, that log shows whether the problem was a stale count, a missing rule or a question the agent should never have answered alone. The NIST AI Risk Management Framework gives a useful vocabulary for mapping these risks to owners and controls. Track two measures above all: how often the agent's stock answer differs from the next physical count, and how often a promised delivery window was missed. Those numbers say more about readiness than the volume of conversations.

The free Be Human AI diagnostic can show you which of these inventory questions is the first one worth handing to an agent.

Frequently asked questions

Can an AI agent tell customers what plants are in stock? Yes, but only from a stock record the nursery trusts and can date. The agent should read sellable, reserved and growing quantities as separate facts, and it should say when a count is older than the agreed refresh window. Anything it cannot confirm should be handed to a person.

Should the agent quote delivery dates to customers? It should repeat only the delivery windows that the dispatcher has published for the customer's zone, along with the order cutoff that applies. If a window has not been published, or the route is full, the agent should offer a handoff rather than promise a day. Weather and road conditions in the spring are a reason to keep the wording honest, not a reason to avoid the question.

What happens if the stock count is wrong? A wrong count is a process problem before it is an agent problem, so the first step is to find out which state was misread, whether sellable, reserved or growing. The log of which record and timestamp each answer used shows where the error entered. Then the fact sheet, the refresh rule or the owner for that state gets corrected, and the test set is rerun before the agent answers that question again.

Do we need a new inventory system before we can use an agent? Not necessarily. Many nurseries start with the systems they already use, provided the fact sheet defines each state, names an owner and sets a refresh rule. A new system can make the count cleaner later, but the first useful step is deciding what the numbers mean and who is responsible for them.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.