Worker Agents for Small Business: A Flower Shop Blueprint

When business owners ask me about AI, most of them picture a single assistant that does everything. The systems I build look different: several small agents with one job each, a coordinator that hands out the work, and a person who signs off before anything costs money or reaches a customer.

At Wildflower Software I use this same setup for a three-person shop that's tired of answering email at night and for enterprise teams that need audit trails and a system their security team will approve. Most of what separates those builds is configuration. The structure stays the same.

Below, I walk through it using a made-up flower shop, with working Python code you can clone and run.

The example: a neighborhood flower shop

I picked a flower shop because its problems show up in most small businesses, only faster. Stock goes bad in days, demand spikes around a handful of holidays, and nearly every custom order is a promise to a specific customer.

On a normal day the owner is juggling:

• Inquiries arriving by email, web form and DMs, many of them custom quotes for weddings and events
• Stem counts, vase life and what has to sell before it wilts
• The weekly wholesale order, sized around upcoming holidays
• Posts, reminders to repeat customers and seasonal promotions
• Daily sales, cost of goods and margins

None of these jobs is hard. Switching between all of them, all day, is what wears an owner down, and that's the part agents handle well.

The architecture

The owner talks to one coordinator. The coordinator delegates to four narrow workers. Anything a worker wants to send, spend or publish stops at an approval gate and comes back to the owner.

Read-only work, like checking stock or adding up sales, goes straight through. Anything that changes something outside the system waits for a person.

The code, in three pieces

The full project is under 600 lines of Python using the Anthropic SDK, tests included. Most of the design lives in three places.

1. A worker is a job description plus an allow-list

Each worker gets a short, specific job and only the tools that job needs. The books worker can read sales and inventory. It cannot order stems or email customers, no matter what it is asked.

@dataclass(frozen=True)
class Worker:
    name: str
    job: str
    tools: tuple[str, ...]

Worker(
    name="inventory",
    job=("You manage perishable stock. Flag stems with two days or less "
         "of vase life so they can be sold first, and draft the wholesale "
         "order based on open orders and current counts."),
    tools=("check_inventory", "list_orders", "place_wholesale_order"),
)

2. Every tool is marked safe or risky

Reading inventory runs immediately. Sending a quote, placing a wholesale order, publishing a post or emailing a customer is marked requires_approval.

Tool(
    "send_quote",
    "Send a price quote to a customer.",
    schema,
    send_quote,
    requires_approval=True,
)

3. The approval gate is enforced in code

Every tool call passes through the gate. Risky calls are queued instead of executed, and the model is told plainly that nothing has happened yet. Without that note, an agent will often tell you it sent the quote when the quote is still sitting in the queue. It's one of the most common problems in agent systems, and it's cheap to prevent.

def submit(self, worker, tool, args, requires_approval, run):
    if not requires_approval:
        result = run()
        self._audit({"event": "auto_run", "worker": worker, "tool": tool})
        return json.dumps(result)

    action = PendingAction(next(self._ids), worker, tool, args, args.get("reason", ""))
    self.pending[action.id] = action
    self._audit({"event": "queued", "id": action.id, "tool": tool})
    return json.dumps({
        "status": "queued_for_owner_approval",
        "approval_id": action.id,
        "note": "This action has NOT been carried out.",
    })

The coordinator sits on top. Its only tools are delegate_to_orders, delegate_to_inventory and so on, so even the agent the owner talks to cannot reach a shop system except through a worker and the gate.

Running python main.py produces the morning brief, then walks the owner through each queued action: approve or reject, with the worker's one-line reason beside it. Every decision lands in an audit log.

What I've learned from client projects

The example is small on purpose, but the choices in it come from real projects, from owner-run shops to operations teams at much larger companies.

• A retail client's first prototype relied on the prompt to say "always ask before ordering." It usually did, and usually isn't good enough when the action is a supplier invoice. Approval rules need to live in code.
• Teams that start with one assistant for everything tend to split it up within a few months. A narrow agent is the only kind you can test properly.
• Most of the trust problems I've been asked to fix came from an agent saying "done" when the action was still pending or had failed. Honest status messages matter more than which model you pick.
• At one service business, approvals sat untouched in a dashboard. Once we moved them into the team's chat, they got cleared within the hour. Send approvals to where people already look.
• Orders and customer promises bring in money, so build those agents first. Inventory and bookkeeping agents get more useful once they have a few months of real data.

From one shop to an enterprise

The same four ideas (narrow workers, limited tools, approvals enforced in code, and an audit log) work for one storefront or a company with many departments. A larger organization just needs each piece built more strictly.

Concern	Small business	Enterprise
Tools	A POS, email and a calendar through connectors	Internal APIs and systems of record, behind service accounts
Approvals	The owner, in chat or on their phone	Role-based rules, thresholds and escalation paths
Audit	A log file or spreadsheet	Retained, queryable audit storage tied to compliance review
Testing	A handful of scripted scenarios	Evaluation suites per worker, run on every change
Hosting	A scheduled task in the cloud	Your cloud, your network boundary, your security review
Support	Setup plus a monthly check-in	Named contact, documented runbooks and agreed response times

A small business ends up with something it can understand and afford to run. A larger organization gets the controls its security and compliance teams will ask about. In both cases, you can see what each agent is allowed to touch and who approved what it did.

Get the code, or get help

The complete project, including the diagram, offline tests and setup instructions, is on GitHub: wildflower-software/flower-shop-agents. Clone it, swap the demo shop for your own tools, and you have a working starting point.

If you'd rather have someone build it with you, that's the work I do at Wildflower Software.

For a small business, that usually means a focused setup around the two or three jobs eating up your week, running on tools you already use. Growing teams tend to need a worker per department and approvals routed to the right people. For enterprise clients, I build systems that can pass a security review, run inside your own environment, and have testing and audit logging from the start.

If you're trying to figure out where agents could help your business, get in touch at wildflowersoftware.com. We'll pick one workflow to start with and agree up front on how we'll know it's working.