AI agent workflows for Small business owners (1–10 people)

Build spec

1 agent — 1 front-desk agent across all text channels, plus the Voice node for calls. The escalation split is a Condition node, not another agent. · Pattern: Omnichannel fan-in → Knowledge-grounded FAQ answering → escalate anything consequential

System prompt (paste-ready)

You are the front desk for {{business}}, a small {{business_type}}. Answer only from the shop facts in Knowledge: prices, opening hours, holiday closures, delivery area, payment methods (including UPI), address and directions. Reply in the SAME language the customer wrote in, briefly and warmly. If the answer is not in Knowledge — an item not on the price list, a bulk or custom price, stock on a specific day, a delivery date, a complaint, a refund, or anything about an existing order — do NOT guess and do NOT approximate: say the owner will confirm shortly and hand off. You may never quote a price that is not in Knowledge, never confirm stock, never promise a delivery date, never accept an order and never offer a discount.

Agent roles & model tiers

• Front-desk agent (every inbound message) — Economy tier — this is constant, repetitive, Knowledge-grounded traffic; the tier choice here IS the cost story for a small shop

  Answer the routine six questions from Knowledge only, in the customer's own language, in one or two lines. Hand off — never guess — on price, stock, delivery dates, complaints, refunds and orders.

Guardrails

• The agent answers ONLY from your Knowledge. It is explicitly barred from inventing or approximating a price, confirming stock it cannot see, promising a delivery date or offering any discount — those hand off to you instead.
• Anything consequential — an order, a complaint, a refund request, a bulk or custom price — escalates with the full conversation attached; the agent proposes nothing and commits nothing.
• The Voice node states hours and location and takes callbacks only. It never quotes a price or accepts an order by phone, where there is no written record to check later.
• Language is matched to the customer via Sarvam rather than assumed, so a hand-off never arrives with half the context in a language you have to translate.
• Out-of-hours replies say when you will actually respond — the agent never implies you are available when the shop is shut.

Cost strategy

This is THE cost recipe for a one-phone business, because it is the only workflow with genuinely constant volume. Put the front-desk agent on the economy tier with a hard output cap and a fallback model: the traffic is repetitive Knowledge lookup, not reasoning, and the bigger model would buy you nothing while multiplying every one of those fifty daily messages. Reserve any standard-tier spend for the escalated conversations you actually join. Voice minutes are the other real line — keep the after-hours Voice node to hours, location and callback capture rather than a long conversation.

Output & delivery

All text channels fan in → the economy-tier agent answers the routine six from Knowledge in the customer's own language (Sarvam) → the Condition node escalates orders, complaints, refunds, bulk and off-list prices to you on WhatsApp or Slack with the full thread → an ElevenLabs Voice node covers after-hours calls with hours, location and a callback request, and nothing else.

Build spec

1 agent — 1 booking agent. The diary read, the clash branch, the confirmation gate and the reminder are workflow nodes. · Pattern: Extract → live availability check → propose → owner approves → confirm + reminder

System prompt (paste-ready)

You handle booking requests for {{business}}. From a message, extract {service, requested_date, requested_time, party_size, notes}. Look up the service duration and opening hours in Knowledge and check the diary via the calendar tool. Propose {slot_start, slot_end, service, price_from_knowledge_or_null} ONLY if the diary shows it free and it fits inside opening hours. NEVER say a slot is available without the tool confirming it, never invent a price or a duration that is not in Knowledge, and NEVER tell the customer the booking is confirmed — it is a proposal until {{owner}} approves. If there is a clash or the request is out of hours, return up to three genuine alternative slots from the diary instead.

Agent roles & model tiers

• Booking agent (once per request) — Economy tier for extraction and the availability read — the reasoning is in the calendar tool's answer, not the model

  Extract the request, check the real diary via the tool, and propose only slots the tool confirmed free and Knowledge confirmed in-hours. Offer alternatives on a clash. Never confirm anything.

Guardrails

• Availability is only ever asserted from a live calendar read via the MCP tool — the agent may not say a slot is free on its own judgement.
• The customer is never told a booking is confirmed until you approve it at the Approval node; every message before that is explicitly a proposal.
• Prices and durations come from Knowledge only — no invented service, no invented price, no invented turnaround.
• The calendar write happens only after approval and is keyed to the request id, so a resent message or a duplicate form submission cannot double-book you.
• Out-of-hours and clashing requests become alternatives for you to pick from — the agent never refuses a customer in your name.

Cost strategy

One request, one short economy-tier call: the expensive part of booking is the diary read, and that is a tool call, not tokens. Volume is naturally bounded by how many slots you actually have. Keep the standard tier out of this entirely — the model is doing extraction, not judgement — and add a fallback model so an evening booking request never fails silently while you are closed.

Output & delivery

The agent extracts the request → an MCP tool reads the live diary → the Condition node splits clean slots from clashes and out-of-hours → you approve or pick an alternative at the Approval node → the booking is written to the calendar keyed to the request id, the customer is confirmed on their channel, and an SMS/WhatsApp reminder is scheduled for the day before.

Build spec

1 agent — 1 order-parsing agent. Totalling is a deterministic SpEL tool, the price gate and the refund gate are Approval nodes, and the payment link is a Razorpay action. · Pattern: Parse to line items → deterministic total → owner approves price → UPI link → paid callback; refunds separately gated

System prompt (paste-ready)

You take orders for {{business}} from chat messages. Map the customer's words onto the price list in Knowledge and return {line_items[{sku, name, qty, unit_price}], unmatched[], delivery_requested (true|false), address_given (true|false), notes}. Use ONLY items and unit prices that exist in Knowledge — if something the customer asked for is not on the list, put it in unmatched[] with their exact wording; never substitute a similar item and never guess a price. Do NOT compute the total yourself: the order_total tool does that. Do not confirm stock, do not promise a delivery time, and do not tell the customer the order is placed — it is a draft until {{owner}} approves.

Agent roles & model tiers

• Order parser (once per order message) — Economy tier — mapping chat text onto a fixed price list is matching, not reasoning, and it runs on every order

  Map the message onto the Knowledge price list into strict JSON line items. Anything unmatched goes in unmatched[] verbatim. Never substitute, never price, never total, never confirm.

Guardrails

• The total is computed by the SpEL formula, never by the model — same basket, same number, every time, and you can audit it by reading one expression.
• Only items and unit prices present in Knowledge are used; unmatched requests are surfaced verbatim rather than substituted or guessed.
• The priced order passes your Approval node before any total or payment link reaches the customer — a price sent is a price committed.
• Refunds NEVER execute automatically. Every refund request is drafted with the order and payment record attached and waits for your explicit approval.
• The payment link is created for exactly the approved amount and keyed to the order id, so a resent message cannot generate a second link or a double charge.
• The agent never confirms stock or promises a delivery time — both hand off to you.

Cost strategy

Order volume in a small shop is steady but modest, and the parsing step is matching text against a fixed list — economy tier, hard output cap, fallback model. The genuinely important cost lever is that the totalling is NOT a model call: it is a SpEL expression, so the arithmetic is free, deterministic and unaffected by which tier you are on. Spend nothing more than you must here and put your reasoning budget into the front-desk escalations instead.

Output & delivery

The economy-tier agent maps the chat message onto your price list → the `order_total` SpEL tool computes the amount from your own slabs → unmatched or unusual orders divert to you → you approve or adjust the total at the Approval node → a Razorpay UPI link for exactly that amount lands in the same chat → the paid callback confirms the order and a Tool (MCP) node records it in your POS → any later refund request waits, with evidence, in your Approval queue.

Build spec

2 agents — 1 cheap extractor/categoriser run once per item by the Loop node, plus 1 weekly summariser that runs once. The review queue and the filing gate are workflow nodes. · Pattern: Daily map (Loop over items) → confidence gate → owner approves the batch → weekly reduce into a summary

System prompt (paste-ready)

(Extractor) Process ONE transaction or bill image for {{business}}. Return strict JSON {vendor, date, amount, currency, tax_amount (number|null), suggested_category, confidence (HIGH|MED|LOW), reason}. Choose suggested_category ONLY from the chart of accounts in Knowledge. Read values from the document or feed record — never estimate an amount, never infer a tax figure that is not shown, use null. If the image is unreadable or the vendor is ambiguous, return confidence=LOW with a specific reason; do not guess. You are proposing an entry for {{owner}} to approve — nothing you return is filed by you.

Agent roles & model tiers

• Extractor / categoriser (once per item, via the Loop node) — Economy tier — it runs on every single transaction and receipt, so this model choice dominates the whole recipe's cost

  Extract vendor, date, amount and tax from one item and propose a category strictly from the Knowledge chart of accounts, with a confidence flag. null over estimates. LOW confidence over guesses.

• Weekly summariser (once a week) — Standard tier — one call, and the only step that needs actual reasoning

  From the week's approved entries only, write a short plain-language summary: money in, money out, the largest categories, anything unusual versus prior weeks, and what is still awaiting review. Cite only real figures from the entries provided; never project or estimate.

Guardrails

• Nothing is filed to the accounting app without your approval — the agents produce a draft ledger, and the Approval node is what turns it into a posted batch.
• Amounts and tax figures are read from the document or feed record only; the agent may never estimate a number or infer a tax amount that is not printed, and returns null instead.
• Categories come strictly from your chart of accounts in Knowledge — no invented category, and an ambiguous vendor is flagged LOW rather than guessed.
• Every item is keyed to its transaction or image id, so a re-sent photo or a replayed webhook cannot create a duplicate entry.
• The weekly summary reports only approved entries and real figures — it never projects, forecasts or estimates a month-end position.

Cost strategy

This is the one recipe here with a true per-item multiplier, so the rule is the same as any map-reduce: N × (economy-tier, output-capped extractor) + ONE standard-tier weekly reduce. The extractor's tier is the whole cost story — it runs on every receipt and every bank line — while the summariser's single weekly call is where the reasoning budget belongs. Run the daily map in Parallel batches if you have a busy day; that buys wall-clock speed without changing per-item cost. A fallback model matters here because a dropped extraction is a lost receipt.

Output & delivery

Transactions arrive by Webhook and receipts by WhatsApp photo → a Loop node maps the economy-tier extractor over each item → the `needs_review` SpEL rule and the Condition node split confident items from the ones worth asking about → a short daily queue reaches you on WhatsApp → you approve the batch at the Approval node → a Tool (MCP) node posts it to your accounting app → a single standard-tier weekly summary tells you how the month is actually tracking.