I Built an Autonomous Commerce Agent That Can't Touch the Money
In Short
Why a tyre shop
For a few years I ran digital and e-commerce for Michelin across 14 countries. Tyres. Hundreds of fitting centres, each one with its own stock, its own staff, its own reviews, and its own Google Business Profile quietly drifting out of date.
That job taught me where multi-location retail actually breaks. Not the website. The gap between what's true in the shop this morning and what the internet says about it. Stock moves. A product sells out. A review lands at 2 out of 10 on a Tuesday and nobody sees it for a week.
So when the Google Cloud hackathon gave me a reason to build an autonomous agent system, I built it for a tyre retailer. I called the company Cymbal. It has a storefront, a set of screens for store managers, and an agent, running on Google's Agent Development Kit, that watches for three things going wrong and does something about each one.
I built the agent layer on top of an open long-horizon agent harness. The hard work was wrapping deterministic controls around a model whose output can change from one run to the next.
Core guardrails
An AI agent doesn't touch money or contact customers without permission.
Treat agent logic like a new hire on day one. Give it a clear remit, strict boundaries, and a manager who signs off on anything customer-facing. You wouldn't hand a new employee the company card and the review inbox and tell them to use their judgment.
In Cymbal, the model reads messy inputs and drafts the words. Hard-coded logic enforces the limits, and a person approves anything that will go public.
The three loops
The agent sits in the middle. The deterministic checks sit between it and anything irreversible.
Reviews. Every customer who buys gets one thing: a plain, neutral link to leave a Google review. No incentive, no "was everything five stars?" gate. If the feedback comes back low, the agent writes up an incident. What happened, which depot, what the customer said. It posts that as an interactive card into the store manager's Google Chat. Nothing else happens until the manager picks it up. A deliberate review strategy looks a lot like this, minus the agent.
Abandoned carts. A checkout stalls for fifteen minutes. The agent can offer a discount to bring the customer back, but the size of that discount isn't the model's decision. A policy function works it out: five percent, capped at £35, once per customer every 30 days, expires in two hours. The offer goes out agent-to-agent, to whatever shopping assistant the customer is using.
Out of stock. A customer authorises a purchase in advance: four tyres, total under £500, within 14 days. When stock lands, a matcher checks the product, the store, the quantity and the price cap against exactly what was authorised. Only if all of it lines up does the payment go through.
The storefront: tyre and wheel fitment by vehicle, with real stock per depot.
Across all three loops, the model interprets the input, deterministic code enforces the limits, and a person approves the customer-facing action.
What that looks like in code
This is the part I'd want a sceptical judge to look at.
The cart discount isn't a prompt. It's a line of Python, min(total * 0.05, 35), with a check that the same customer hasn't had an offer in the last 30 days and a two-hour expiry stamped on it. If the model talked itself into a 40% discount somewhere in its reasoning, it wouldn't matter. The number that ships comes out of code that can't be argued with.
The review escalation is a threshold, not a judgment call: feedback at or below 6 out of 10 goes to a human. The model doesn't get a vote on whether something is bad enough to escalate.
The payment path is the strict one. Before anything settles, a verifier checks a real cryptographic signature, Ed25519 or RS256, and a SHA-256 hash of the exact checkout. So what's being paid for is exactly what the customer authorised, not a version the agent nudged along the way. The new authorisation has to stay inside the bounds of the original one, and the same authorisation can't be replayed twice.
Where the model earns its place: reading the question and giving fitment advice. It doesn't move the money.
The model's actual job in all this is to read the messy inputs, work out what's happening, and write the words: the incident write-up, the review reply draft, the fitment advice in the storefront assistant. Interpretation and prose, which it's good at. The irreversible decisions stay with the code.
The plumbing between agents, one talking to another, a checkout being described, a payment mandate being signed, runs on the emerging open standards for this: A2A, AP2, and MCP.
Store manager sign-off
A low review, written up and paused, waiting for a store manager to decide.
Feedback scored at 6 out of 10 or below stops the workflow because it touches a real customer and a real shop's reputation.
The agent writes up the incident and sends an interactive card to the store manager in Google Chat. The manager can investigate, assign, or dismiss it. Until they choose, the process stays frozen.
Autonomous tools should handle the fetching, drafting, and chasing. That leaves the manager with the decision that actually needs their judgment, and the system waits for it.
I've spent years telling clients the same thing about AI and their Google Business Profile: let it draft, let it summarise, let it find the thing you missed. Don't let it publish.
Demo scope and mock data
The protocol stream on the demo page. Useful to watch, and simulated, not live traffic.
- Live on Cloud Run: the deterministic policy engine, cryptographic signature and hash checks, the core agent runtime and its agent-to-agent endpoint, and the storefront. A test suite covers these parts of the build.
- Mocked for the demo: the event bus, checkout provider, protocol stream shown on the demo page, competitor data feeds, and image and audio generation. These use stand-in implementations to demonstrate the full workflow, but they are not wired to a live retailer.
Engineering takeaways
Session persistence. The agent dropped its state whenever a container restarted. Debugging the lost sessions ate half a day before I added a durable Firestore session store so the conversation could survive a restart.
Idempotency matters more when a human is in the loop. A workflow that pauses for a manager to tap a button might sit there for a day. When it resumes, it can't re-send the offer it already sent or run the settlement twice. One-time action tokens and that checkout hash do the deduplicating. Anything that can pause has to assume it might run twice.
Evaluation. Testing focused on execution sequences and boundary limits rather than prose quality. We checked whether the agent called the stock check, respected the £35 cap, and stopped at the approval gate.
Real-world takeaway
The same approach works in the day job. When we manage Google Business Profiles and reviews for clients, AI can draft, summarise, and flag what needs attention. A person still signs off before anything reaches the public, just without the cryptographic signatures.
The code and the running demo are here:
And if you'd like a human pair of eyes on your own Google Business Profile before you point any AI at it, you can book a strategy session.
Found this useful?
Share it with someone working on local visibility.
If this helped clarify how Google is changing local discovery, pass it on. You can also add us as a preferred source in Google so our updates are easier to find when we publish fresh work.
Google will open its source preferences tool. Tick the box next to CTB Digital Marketing to follow the site.