# The difference between a chatbot and an agent is a database write - URL: https://www.reevix.com/blog/agent-or-chatbot - Topic: Agents - Published: 2026-06-30T18:00:00.000Z - Author: Golam Mostafa - Reading time: 8 min read Every vendor now says agent. Most of them ship a search box with a personality. The line is simple and testable: when the conversation ends, did anything in your systems actually change? The word agent has been applied to so much software this year that it has stopped carrying information. Vendors use it for chat widgets, for retrieval over a help centre, for a prompt with a nice avatar. Buyers, reasonably, have started ignoring it. There is a clean test that survives the marketing. At the end of the conversation, look at your database. If a row changed — an order was cancelled, a return was opened, a plan was switched, a credit was applied — you were talking to an agent. If nothing changed, you were talking to a search box that types. > **Why the distinction is worth money:** A chatbot moves work around. It answers a question a person then has to act on, and the ticket often arrives anyway, now with more context and the same amount of human time attached. An agent removes the work. Only one of those shows up in a staffing plan. ## Retrieval is table stakes, not the product Most of what is sold as agentic is retrieval with better manners: index the docs, find the closest passage, restate it in the brand voice. That is genuinely useful and it is genuinely not new. It has also been thoroughly commoditised — the gap between the best and worst implementation of "answer from the help centre" is now measured in a few percentage points. What has not been commoditised is the second half: connecting the answer to the systems the answer is about. Reading the order. Starting the return. Moving the delivery date. That half is where the integration work lives, which is exactly why so few products do it and so many claim to. ## Three questions that settle it in a demo Sales demos are built to hide this distinction, so ask directly: - **Show me it doing something, not saying something.** Ask the demo to cancel an order. Watch whether an order actually cancels, or whether it explains the cancellation policy. - **Where does it stop, and who decided?** A real agent has written limits — value ceilings, frequency caps, actions it may never take. If the vendor answers this with "the prompt tells it not to", there are no limits. - **What does a wrong action look like afterwards?** Ask to see the trace of a run: the step, the tool, the arguments, the result. If the only record is a chat transcript, you cannot audit it and you cannot debug it. ## The uncomfortable part Agents are more valuable than chatbots for exactly the reason they are harder to deploy: they can do damage. A chatbot that hallucinates produces a bad sentence. An agent that hallucinates produces a refund. That is not an argument against agents. It is an argument for the boring infrastructure around them — permissions, approval gates, run traces, cost caps — which is unglamorous, is what separates a demo from production, and is the part almost nobody wants to build twice. > Ask what changed in the database. It is the only agent definition that cannot be answered by a better prompt. --- # Agentic commerce: what actually changes in a store - URL: https://www.reevix.com/blog/agentic-commerce-what-changes - Topic: Ecommerce - Published: 2026-05-31T18:00:00.000Z - Author: Golam Mostafa - Reading time: 9 min read Not the checkout. Not the theme. What changes is that two jobs nobody had time for — answering the shopper who is stuck, and working the catalog nobody opens — start happening every day. Agentic commerce is described, usually, as a future in which shopping agents buy things on a customer's behalf and stores must be machine-readable to survive. That future may arrive. It is not what is changing in stores this year. What is changing is duller and much closer: two jobs that every small store knows it should do, has never had the headcount to do, and can now hand to something that does them at 3am. ## Job one: the shopper standing in front of the shelf Every store loses sales at the same moment. A shopper is on the product page, nearly convinced, and has one question — will it fit, will it arrive by Friday, is the oak the same as the walnut. There is no one to ask. The FAQ does not cover it. They leave, intending to come back, and do not. An agent on that page closes the gap, but only if it is wired to the product record rather than the marketing copy. "54cm wide, and there are nine in oak" is a sale. "Our products are designed to fit a variety of spaces" is the same lost sale with more words. > **The integration is the product:** An agent with your catalog, stock, and order data answers like staff. The same model with only your marketing site answers like marketing. Identical technology; opposite outcomes. ## Job two: the catalog nobody opens The second job runs the other way — not toward the customer, toward the four thousand rows nobody has looked at since import. Listings with no description. Photos that are hurting conversion. Prices set eighteen months ago against costs that have moved. Stock that will run out during the campaign you are about to launch. This is where an agent earns its keep quietly. It reviews the catalog on a schedule, writes what is missing, flags what is weak, and proposes the price and stock moves with the maths attached. Nothing publishes itself: the output is a queue you approve in one pass over coffee. A person who had no time to audit four thousand products has plenty of time to approve three hundred proposals. ## What does not change Three things stay exactly as they were, and pretending otherwise is how these projects fail: - **Checkout.** Payments, tax, fraud, and refunds are solved problems with regulators attached. An agent has no business inside them. - **Brand voice.** An agent inherits whatever tone your product data has. If your catalog is careless, the agent will be fluently careless at scale. - **Accountability.** Whatever the agent does, the merchant did. Which is the entire argument for approval queues and action limits, and against letting an agent price your catalog unsupervised. ## Where to start Start with the job that has a number attached. If your support queue is dominated by "where is my order", the shopper-facing agent pays for itself in weeks. If half your catalog has no description, the merchandising agent does. Starting with both is how a six-week project becomes a six-month one. > Agentic commerce is not the store getting smarter. It is two unglamorous jobs finally getting done, every day, whether or not anyone had time. --- # Give an agent tools, not keys - URL: https://www.reevix.com/blog/giving-agents-tools-not-keys - Topic: Agents - Published: 2026-05-31T18:00:00.000Z - Author: Golam Mostafa - Reading time: 10 min read The failure mode of a production agent is never a bad sentence. It is a real action taken confidently and wrongly. Four patterns that keep an agent useful without making it dangerous. The first version of every agent project is the same: connect the model to the systems, watch it work, feel the vertigo. It can read the orders. It can also, technically, refund all of them. Nothing about that vertigo is irrational. The model is not malicious, but it is confidently wrong on some percentage of inputs, and confidence plus write access is how a Tuesday afternoon becomes an incident report. The fix is not a better prompt. Prompts are requests, not permissions. > **The rule worth writing on a wall:** Anything you would not let a new hire do unsupervised on day one, the agent does not do unsupervised on day one either. Nobody argues with that framing, and it settles most design debates in about a minute. ## One: split reads from writes, and mean it The most valuable ten minutes in an agent project is the meeting where someone writes every tool on a whiteboard and draws a line down the middle. Reads on the left, writes on the right. Reads are cheap. Let the agent look at anything it needs — orders, stock, docs, customer history — because a wrong read produces a wrong sentence, and wrong sentences are recoverable. Writes are where the risk lives, and the right-hand column is almost always shorter than anyone expected. Most agents need three or four write tools, not thirty. ## Two: put the limits in code, not in the prompt A prompt saying "never refund more than fifty dollars" is a suggestion the model will usually follow. A function that checks the amount before calling the payment provider is a rule. The distinction matters because the two fail differently. A prompt fails silently on the unusual input you never tested. A code check fails loudly, in a log, with a value you can read. - **Value ceilings.** Under the threshold proceeds, over it goes to a person. The model does not get a vote on the threshold. - **Frequency caps.** One goodwill credit per customer per quarter, enforced by a counter — not by hoping the model remembers a conversation from March. - **Irreversibility rules.** Anything that cannot be undone — deleting an account, shipping a replacement, moving money out — is a recommendation the agent hands to a person, never an action it takes. ## Three: approval as a queue, not an interruption Teams resist human-in-the-loop because they picture a dialog box interrupting someone all day. That is the wrong shape. The shape that works is a queue. The agent does everything it is allowed to do, batches what it is not, and someone clears the batch once or twice a day. Fourteen invoices chased automatically, two held for a decision, reviewed in ninety seconds each morning. The human is a checkpoint, not a bottleneck — and the queue itself becomes the best possible list of what to automate next. ## Four: a trace, or it did not happen When an agent does something wrong, the first question is always "why did it do that?" — and the answer has to be available without reproducing the run. That means recording each step: what the agent was asked, what it decided, which tool it called, with what arguments, what came back. A chat transcript is not this. A transcript shows what was said; a trace shows what was done, and only the second one lets you fix anything. It is also, incidentally, what makes an agent explainable to people who did not build it — which is the conversation that decides whether it stays switched on. > An agent with narrow tools and a real audit trail is boring in exactly the way production systems should be boring. --- # What an AI agent actually costs to run - URL: https://www.reevix.com/blog/what-an-ai-agent-costs-to-run - Topic: SaaS - Published: 2026-05-31T18:00:00.000Z - Author: Golam Mostafa - Reading time: 10 min read A chat message costs a fraction of a cent. An agent run costs twenty to a hundred times that, and the heaviest customer costs fifty times the median. Flat pricing over that is a bet, not a model. Teams price AI features using the intuition they built on chat: a message is a request and a response, the cost is a fraction of a cent, nobody sends enough of them to matter. Agents break that intuition immediately. One agent run is not one model call. It is a planning call, a tool call, a call to interpret the tool result, often a retry, and a final call to write the answer — each one carrying the accumulated context of the ones before it. A run that reads twelve orders and drafts twelve emails can be forty model calls with a growing context window attached to every one. > **The arithmetic that surprises people:** A chat reply might cost a fifth of a cent. The equivalent agent run — same model, same customer — routinely costs ten to forty cents. Not a different order of magnitude in aggregate. Two. ## Where the money actually goes Three drivers dominate, and only one of them is the model you picked. - **Steps per run.** Cost scales with how many times the loop goes around. An agent that retries three times on ambiguous input costs three times more on exactly the inputs your worst customers send. - **Context carried.** Each step re-sends what came before. A long tool result early in a run is paid for again at every subsequent step, which is why trimming tool output is usually a bigger saving than switching models. - **Failed runs.** The run that ends in an escalation cost full price and produced no automation. Deflection rates hide these; margin reports do not. ## Meter before you price You cannot price what you cannot count, and the counting has to be per run, not per month. Record, for every run: the workspace, the agent, the number of steps, input and output tokens, and the provider cost at the rate in force that day. Store rows, not a running total, so you can answer questions you have not thought of yet. Build it before the feature ships. Teams that add metering afterwards discover their pricing problem with a year of customers already on the wrong plan, which turns a config change into a migration. ## Credits, not tokens Selling tokens directly is honest and unsellable — nobody budgets in tokens, and a customer thinking about token counts is a customer thinking about leaving. Define a credit as one unit of value the customer recognises: a conversation handled, a document processed, a catalog pass. Price actions in credits and keep the credit-to-cost ratio as an internal setting. That indirection is what lets you absorb provider price changes without renegotiating with every customer, and what lets you charge more for an expensive action than a cheap one without explaining why. ## Degrade, do not stop Every plan needs a ceiling, and the ceiling is a product decision. An agent that hard-stops mid-queue on a deadline day costs the account. Warn at eighty percent, warn again at a hundred, then degrade: queue the run, drop to the cheaper model, or offer a one-click top-up right there. Overage should be possible and obvious. The customer who exceeds their limit twice a month is your best upgrade conversation, and you only get to have it if the system let them. ## The report that matters Not revenue. Revenue minus provider cost, per workspace, sorted ascending. The bottom of that list tells you which customers are unprofitable, whether that is a pricing problem or a retry-loop bug, and whether your cheapest plan should exist. > Every agent business builds this report eventually. The ones that build it before launch get to choose their prices. The ones that build it after get to explain them. --- # Build or buy the agent stack? The honest version - URL: https://www.reevix.com/blog/build-or-buy-your-agent-stack - Topic: Build log - Published: 2026-04-30T18:00:00.000Z - Author: Golam Mostafa - Reading time: 9 min read The agent loop is a weekend. Everything around it — traces, approvals, retries, cost caps, accounts, billing — is a quarter. Here is the line I actually draw, having sold both sides of it. I sell agent products, so weigh what follows accordingly. I also build custom ones for clients, which means I regularly talk people out of buying. Both are the same judgement call, and it is narrower than either side of the argument suggests. Start with the part everyone underestimates in the same direction. Writing an agent loop — model, tools, iterate until done — is genuinely a weekend. Every framework does it, most of them well, and the difference between them will not decide anything. The quarter goes somewhere else. ## What the quarter is actually spent on Add up the work between a loop that runs on your laptop and something a business depends on: run traces you can open when a customer complains, an approval queue for actions that need a person, retries with backoff that do not silently double-charge, per-tenant cost caps that stop a runaway loop, scheduling, a tool registry with permissions, accounts, workspaces, billing, and usage metering that survives an accountant's questions. None of that is your product. All of it is required, and its ceiling is "correct" — nobody has ever won a market because their retry logic was more elegant. > **The real cost of building it:** Not the twelve weeks. The twelve weeks plus every future bug in code that a few thousand other teams are not also hitting and reporting. ## What buying actually costs The honest column. A product is a set of decisions someone else made: this ORM, this trace schema, this way of modelling a tool. Some will be wrong for you, and you find out in month four, not week one. - **Migration friction.** Customise heavily and upstream updates stop merging cleanly. Plan for the fork. - **Abandonment risk.** A product whose author disappears becomes your codebase, at full size, with no context. - **Shape mismatch.** Most agent products assume a workspace with members and a queue of runs. If your agents are embedded in a device fleet or a trading loop, half the schema is a tax. ## The line I draw Buy when your differentiation sits above the plumbing — a support agent with unusual domain knowledge, a merchandising agent with your pricing logic, a vertical workflow nobody else understands. The plumbing underneath is identical across all of those, and it is not the product. Build when the agent's operating environment is the product. If runs are measured in milliseconds, or the tools are physical, or a regulator will ask to see the control loop, a generic workbench fights you in every file. Start empty and steal the patterns. ## Three questions that settle it in ten minutes - **Can I read the source before committing?** If not, or if it is obfuscated, you are renting whatever the checkout page said. - **Does the trace model fit my failure questions?** Open the schema first, not the landing page. Five minutes there beats an hour of feature bullets. - **What happens on update day?** Fork it, change ten files, pull upstream. If that hurts in a demo repo, it is unbearable in production. > Buy the parts you would have built identically. Build the part you would have built differently. Almost every argument about frameworks is people disagreeing about which is which. --- # A two-person support team stopped drowning in “where is my order” - URL: https://www.reevix.com/case-studies/store-agent-cleared-the-queue - Topic: Agents (case study) - Published: 2026-06-30T18:00:00.000Z - Author: Golam Mostafa - Reading time: 7 min read A homeware brand was answering 3,000 tickets a month with two people, and two thirds of them were the same question. Six days after Concierge Agents went in, the agent was closing 82% of conversations against real order data. The brand had grown faster than its support desk. Two people were answering roughly three thousand tickets a month, working evenings during a promotion, and losing the thread on the ones that actually needed a human — a damaged delivery, a wholesale enquiry, a complaint escalating in public. The frustrating part was the shape of the queue. Two thirds of it was a single question with a known answer sitting in the order table: where is my order. > **Snapshot:** Homeware DTC brand · ~3,000 tickets/month · two-person support team · Concierge Agents, self-hosted · 6 days from kickoff to the agent owning tier one. ## What they had already tried A help-centre chatbot, installed the previous year and quietly switched off. It had been trained on the FAQ, so when someone asked where their order was, it explained the shipping policy. Customers learned to type "agent" immediately to skip it, and the deflection number on the dashboard was counting that as a win. The lesson they took from it was the right one: the problem had never been the model. The problem was that nothing was connected to the order table. ## What we did Day one was the read side. Concierge was pointed at their catalog, their docs, and — the part the old bot never had — their live orders and shipments. That change alone turned "our standard delivery is 3-5 working days" into "it left the warehouse Tuesday, tracking says it is out for delivery today." Days two and three were the write side, and that is where the limits got written. Address changes before dispatch: allowed. Reship a lost parcel under £40: allowed. Refunds: allowed under £25, held for approval above it. Anything involving a damaged item, a wholesale account, or a customer who has already complained twice: straight to a person, with the conversation attached. Days four and five ran it in shadow mode. The agent drafted what it would have done, a human approved or corrected each one, and the corrections became the rules for the next day. Day six it went live on the widget. ## The results - 82% of conversations closed by the agent without a human, measured over the first 30 days - Median first reply fell from 4 hours to 6 seconds - The two-person team handled the remaining 18% inside working hours, and stopped working evenings - Satisfaction on agent-handled conversations tracked slightly above the human queue, mostly on speed - Nine refunds hit the approval ceiling in the first month. All nine were reviewed. Two were declined. > The old bot made customers wait to reach us. This one means most of them never needed to. — Head of Customer Care ## The pattern Two decisions did the work here, and neither was about the model. Connect the agent to the systems the questions are about, then write the limits in code before you turn it on. Shadow mode for two days is what turns those limits from a guess into something the team already trusts by launch. --- # Four thousand products, listed over one weekend - URL: https://www.reevix.com/case-studies/agentic-storefront-in-one-weekend - Topic: Ecommerce (case study) - Published: 2026-05-31T18:00:00.000Z - Author: Golam Mostafa - Reading time: 6 min read A homeware wholesaler had sold through resellers for fifteen years and had no customer-facing copy for anything. They needed a direct store before the autumn season. The catalog went live in a weekend; organic traffic passed reseller referrals in week six. The brief arrived in July with a deadline in September. A wholesaler with 4,120 SKUs wanted to sell direct for the first time. They had supplier spec sheets, warehouse photographs, and not one line of customer-facing copy — because for fifteen years, writing it had been someone else's job. > **Snapshot:** Homeware wholesaler · 4,120 SKUs · Nova Commerce + Merchant Copilot · catalog live in one weekend, store trading in eleven days. ## The situation Two quotes were already on the table. An agency had priced a bespoke storefront at fourteen weeks. A copywriting studio had quoted eleven weeks for the descriptions alone, running in parallel — which still put the launch three weeks past the season they were chasing. The storefront was never the blocker. Storefronts are a solved problem. The blocker was four thousand empty description fields and no realistic way to fill them by hand. ## The weekend The store itself took a day. Nova Commerce went onto their own cloud account on the Friday, with the catalog imported from the spreadsheet their warehouse system already exported. Saturday was the catalog pass, and the input decided everything. Rather than generating from product titles — which produces four thousand interchangeable paragraphs — Merchant Copilot read the supplier specification sheets: dimensions, materials, care instructions, box contents. Every listing was written from the facts of that specific product, with the metadata pass running behind it as a checklist. Sunday and Monday were review. Sorted by expected revenue, the top two hundred products were read line by line by their own product manager and edited where the tone was off. The remaining 3,900 were approved in batches from the queue. Nothing shipped unread by category, and nothing waited on a perfect read of every item. ## What happened after launch The shop agent went on in week two, connected to stock and the order table. It turned out to matter most on exactly the products the team had worried about — large furniture, where every shopper has a measurement question and nobody wants to email about it. ## The results - Catalog live in one weekend, against an eleven-week copywriting quote - Store trading eleven days after the first call, three weeks ahead of the season - Every product page carried its own specifications, not a shared template - Organic search traffic passed reseller referral traffic in week six - Pre-purchase questions on large furniture answered in the cart, not by email > The part we thought was impossible turned out to be the part that took two days. — Head of Ecommerce ## The pattern When a launch is late for a seasonal reason, the platform is almost never what is late. Put up a storefront you own on day one, then spend the saved weeks on the catalog — the only part nobody else can do for you, and the part an agent can finally help with. --- # A two-person team charged customers on launch day - URL: https://www.reevix.com/case-studies/saas-launch-with-billing-day-one - Topic: SaaS (case study) - Published: 2026-04-30T18:00:00.000Z - Author: Golam Mostafa - Reading time: 7 min read A pair of founders had a working transcription agent and no way to bill for it. Four months of runway were earmarked for auth, workspaces, and Stripe. On Orbit SaaS they launched in nineteen days — with metering that showed them, in week two, which plan was losing money. Two founders, one working product, eleven months of runway. Their meeting agent did the hard part well: it joined the call, transcribed it, and produced summaries their design partners genuinely used. What it could not do was take money. The plan on the whiteboard was four months of plumbing — accounts, teams, subscriptions, an admin panel, and a way to stop a customer from transcribing ten thousand hours on a $29 plan. Four months is a third of the runway, and none of it is the product. > **Snapshot:** Two-person team · meeting-agent SaaS · Orbit SaaS, deployed to Vercel · 19 days from first commit to first paid invoice. ## The problem They had built the interesting half and stalled at the boring half, which is where most small AI products stall. Not because auth is hard — because auth, plus workspaces, plus invites, plus proration, plus failed-card recovery, plus usage caps, is six weeks of unrewarding work each, and there were two of them. The specific fear was the last item. Agent cost scales with audio hours and with how many times the summariser goes around, and both vary wildly per customer. A flat plan without a meter behind it is an open tab, and they knew it. ## What we did Orbit went in as the foundation rather than a rewrite. Their agent stayed exactly where it was; Orbit supplied everything around it — sign-in, workspaces, plans, and the credit meter that counts an agent run against a plan allowance. Week one was branding and wiring: their domain, their palette, their service connected behind the credit meter. Week two was plan design, which turned out to be the real conversation. With per-workspace cost visible in the admin panel, the pricing discussion stopped being a guess. Week three they turned billing on for eleven design partners who had been using it free, and nine of them converted. ## The results - Nineteen days from first commit to first paid invoice, against a four-month estimate - Nine of eleven design partners converted at launch - The $19 starter plan was found to be unprofitable in week two, from real run costs, and repriced before it had scale - Zero engineering time spent on sign-in, invites, proration, or dunning > We had priced the starter plan on a feeling. The meter told us it lost money on the median customer, not the heavy one. — Co-founder ## The pattern Small teams rarely lose to competitors on features. They lose four months to plumbing and run out of road. Buy the plumbing, keep the runway, and — critically — turn the meter on before you set prices rather than after, while changing them still costs nothing.