Where Should an AI Agent Go on an EC Site with 1–2 Orders a Week? The Numbers Said: Nowhere, Yet

What happened

I got a request along these lines: "Our dev server is sitting idle — let's put an AI agent on it and automate some work." The target was a small e-commerce site, and the first candidate everyone thought of was automating order fulfillment (shipping updates).

Before building anything, I decided to look at the numbers. I aggregated the last 180 days of orders:

SELECT COUNT(*) AS orders, SUM(payment_method = 'credit') / COUNT(*) AS credit_ratio FROM dtb_order WHERE order_date >= CURRENT_DATE - INTERVAL 180 DAY AND order_status NOT IN ('cancelled'); 

The result: 39 orders in 180 days — one or two a week. About 70% were card payments, and the payment itself is handled automatically by the payment processor. The only manual work is the shipping update, which adds up to roughly 10 minutes per week.

The job we wanted to automate turned out to be ten minutes a week. That's where I stopped and reconsidered.

Why "automate fulfillment" was the wrong first project

Several problems surfaced once I looked closely.

1. Most of the automation doesn't need an LLM. "When an order comes in, update the shipping status and send a notification" is a deterministic task with fixed inputs and outputs. That's cron + SQL + email — there's no reason to put an agent in the middle. Agents earn their keep where judgment, writing, or exceptions are involved: reading logs and summarizing what's normal vs. concerning, spotting and explaining discrepancies in aggregates, drafting replies to customer inquiries, writing product descriptions and translations.

2. Starting your first agent project with production DB writes maximizes the cost of failure. Changing shipping status means mutating production data. Picking a task where a mistake directly affects customers as your first agent project is backwards. Start with read-only daily reports, earn trust, then consider writes.

3. A 512MB server can't run a local model anyway. The whole premise was "the server is idle, let's use it" — but with 512MB of RAM, local LLMs are off the table. API-based agents use almost no memory on the host, so the server's spec is irrelevant. In other words, "the server is idle" was never a reason to introduce an agent in the first place.

4. The dev server shares the production database. If an agent is going to touch that DB at all, it needs its own read-only account:

CREATE USER 'agent_ro'@'localhost' IDENTIFIED BY '********'; GRANT SELECT ON shop_db.* TO 'agent_ro'@'localhost'; 

If you reuse the application's credentials, "it was only supposed to read" stops being a guarantee.

What I actually did: a five-candidate table, ranked

Instead of picking by gut feeling, I put the candidates in a table with two columns — "why an agent?" and "risk":

Laid out like this, the original favorite — fulfillment — lands at the bottom. The agent-shaped work is the top four, and the natural order is: read-only first, then human-reviewed text generation, then (only once trusted) writes.

The final decision was to put the whole thing on hold. Saving ten minutes a week doesn't justify the cost of building, operating, and monitoring an agent. Making the table, ranking the candidates, and recording "not now" — that's a legitimate outcome too.

Takeaways

• The first question for agent adoption isn't "what should we automate?" but "how many minutes a week is that job, and what breaks if it goes wrong?"
• Deterministic work is cron + SQL. Agents pay off where judgment, writing, or exceptions are involved
• First project: read-only. Production writes come last
• "The server is idle" is not a reason to adopt an agent (API-based agents barely use the host)

The work you want to automate and the work worth automating are different things. Thirty-nine orders in 180 days made that clear.