In Q2 2026 we ran a 90-day pilot of an autonomous-ops layer on top of the Greenbrook stack — five agents, read access to every system, write access to a few, approval gates on the dangerous ones. This is what we learned. Including the parts that didn’t work.
Everything here describes a single retailer’s stack. Numbers are real but not benchmarks. Your results will diverge in the direction of however weird your catalog is.
Agents don’t replace operators. They replace the spreadsheet that operators have been keeping in their head.
The five agents, in plain language
Each agent owns a domain, reads from a defined set of inputs, and produces a defined kind of output. None of them write directly to a customer-facing surface without an approval gate.
1. Sales / forecast agent
Reads: Magento order stream, Lightspeed sell-through, promotional calendar, last 24 months of seasonality. Produces: a rolling 14-day demand forecast at SKU level, with confidence bands, plus anomaly flags when reality diverges from forecast by more than 2σ.
2. Inventory agent
Reads: forecast agent output, current stock at both channels, supplier lead times, on-order POs. Produces: reorder recommendations — “order 60 units of SKU-2188 from supplier A, expected arrival in 9 days, expected stockout if no action in 11 days.” Writes PO drafts into our internal PO system; a human signs them.
3. Ad-ops agent
Reads: Google Ads + Meta Ads spend and conversion data, Magento attribution, daily revenue by campaign. Produces: budget rebalancing proposals between campaigns based on rolling 7-day ROAS, with a cap on daily change magnitude. Auto-executes within the cap; proposes for human review beyond it.
4. SEO agent
Reads: Google Search Console, current page meta-descriptions, page revenue rank, internal site search queries. Produces: rewritten meta descriptions and title tags for underperforming pages, with the rationale (“page ranks #4 for ‘magnesium glycinate canada’, current title doesn’t mention Canada, proposed: …”). Writes staged-only; human approves.
5. Marketing agent
Reads: customer cohort behavior, last-purchase recency, promo history, content calendar. Produces: targeted email campaign drafts and segment definitions. Writes drafts into Klaviyo; never sends without approval.
What worked
The boring stuff did the heavy lifting
We expected the “clever” agents — ad-ops rebalancing, SEO rewrites — to drive most of the value. They drove some. The biggest wins came from the inventory agent doing the unglamorous thing of watching stock levels and lead times simultaneously and flagging the SKUs that would stock out before the next PO arrived. That used to be a Friday-afternoon spreadsheet check by the operator. Now it’s a continuous loop, and stockout-days dropped from a monthly average of 14 to under 2.
Forecast confidence bands earn trust
Every forecast outputs a 7-day, 14-day, and 30-day band with explicit confidence intervals. The operator’s reaction shifted from “the agent thinks 60 units” (skeptical) to “the agent thinks 60 ± 12 units at 80% confidence” (actionable). Showing the bands doesn’t change the math — it changes the relationship.
Ad-ops auto-execution within a cap
We let the ad agent move budget between Google campaigns autonomously, but only up to ±15% of yesterday’s daily spend on any single campaign, per day. Anything beyond that goes to human review. Inside the cap, the agent makes 5–10 micro-adjustments a day that an operator would never bother with. Cumulative ROAS lift over the pilot: +18% on the campaigns under agent control.
SEO drafts are excellent first drafts
Every SEO meta-description proposal landed in a shared review queue. We approved roughly 60% verbatim, edited 30% before approving, rejected 10%. That ratio is what we want — the agent is doing first-pass work, the operator is doing taste.
What we rolled back
Promotion writing
An early version of the marketing agent generated full promotional copy, including discount codes and CTA buttons, ready to send. We turned this off in week 3. The copy was technically fine but off-brand in subtle ways — too breathless, too generic-startup. The agent didn’t have enough of the retailer’s voice to write copy that sounded like them. We pulled it back to producing segment definitions and content briefs only; humans write the actual copy.
Autonomous PO submission
For a week in month two, the inventory agent had auto-submit authority on POs under $1,000 from approved suppliers. We pulled this after a reorder fired twice for the same SKU because of a race condition in our duplicate-detection (two forecasting runs, one minute apart, both crossing the threshold). Cost: ~$600 of overordered stock, no customer impact. Lesson: write paths need idempotency keys at the action layer, not just at the proposal layer. Re-shipped a week later with proper deduping; haven’t had a recurrence.
Cross-agent autonomous trades
We tried letting the ad-ops agent and the marketing agent negotiate — “if email cohort X is unresponsive, reduce ad spend on lookalike audience X”. Worked in theory. In practice, the feedback loop introduced enough noise that both agents started making smaller, less confident moves. We removed the link and let each agent optimize independently.
Multi-agent doesn’t mean multi-agent conversation. It means multiple agents acting on the same shared world, separately.
The shape that worked
After the rollbacks, the architecture that stuck has three properties:
- Agents propose, humans dispose — except inside narrow auto-execute caps for actions that are reversible within a day (ad-budget moves, SEO meta-description swaps).
- Every proposal carries its rationale — not just “reorder 60 units” but “reorder 60 units because forecast vs. current stock + lead time projects stockout in 11 days, supplier lead time is 9 days, this is the last safe day to fire.” The rationale is what makes the proposal reviewable.
- Agents don’t talk to each other — they all read the same world state, write to the same audit log, and converge through the shared state, not through direct messaging.
The infrastructure under the agents
Less interesting than the agents themselves, but it’s what makes them safe to run:
- Append-only action log. Every proposal, every approval, every auto-execution is recorded with timestamp, agent id, rationale, and outcome. Replayable for postmortems.
- Rate limits per agent. Each agent has an explicit budget — n proposals per hour, n auto-executions per day. Past that, everything queues for review.
- Kill switch per agent. A single flag per agent that suspends its proposals and auto-executions. We’ve hit it exactly once (during the PO duplication incident), and the pause-to-fix-to-resume loop took 90 minutes.
- Approval queue UI. One inbox. Every proposal in one place. The operator spends ~20 min/day in it.
What we don’t do
We don’t:
- Let an LLM call any write API directly. Every write goes through a typed action layer with an idempotency key.
- Optimize one metric in isolation. Every agent has at least one guardrail metric — reducing CAC without watching contribution margin is how you ship a disaster.
- Run agents on PHI-adjacent data. The pharmacy side of the stack stays out of agent scope entirely; agents operate on the retail commerce data only.
- Pretend any of this replaces an experienced operator. It replaces the spreadsheet they were keeping at the edges of their attention.
The boring discovery
The hardest part of the pilot wasn’t writing the agents. It was instrumenting the world so the agents had something coherent to read. Half of our effort went into:
- Reconciling order data between Magento and Lightspeed (timezone bugs, partial fulfillment double-counts, refund offsets).
- Backfilling 24 months of clean historical data for the forecaster (the warehouse had it; getting it cleanly aggregated took two weeks).
- Defining unambiguous “current stock” — surprisingly hard when items live in two POSes and a warehouse, all of which have their own latency.
- Adding stable IDs so the audit log could survive a SKU rename without orphaning history.
None of this is exciting. All of it is the actual work. The agents on top of it were a relatively small lift.
Most of building autonomous commerce ops is building a clean version of what your business already knows.
Where we’re taking it next
The pilot is now in extended operation. The next steps we’re working on, in order of priority:
- A pricing agent that watches competitor prices via a daily scrape and proposes price moves on commodity SKUs (proposals only, no auto-execute — pricing decisions touch margin too directly).
- A content agent that drafts PDP copy from supplier data sheets, scoped to new SKU launches.
- A refund-anomaly agent for catching patterns in returns that suggest a quality issue with a batch.
Each of these will ship the same way the first five did: read-only for the first week, propose-only for the second, auto-execute within a narrow cap from there.
Running a commerce stack that’s ready for an autonomous layer? We’re taking on one new pilot partner per quarter — hello@trace-ai.ca.