Agent driven retail in a pet shop. A small team, a lot of agents, and the month everyone got comfortable and stopped getting better.
Gaston was ICA's pet retail concept for dogs and cats. Four stores plus e-commerce, six people. Agent driven retail. And built that way from the first day rather than retrofitted, aiming at ten people and a billion SEK of turnover.
It started fast, because nothing existed yet and everything we did was new. Then we hit the first level of maturity and slowed down, which nobody warns you about. What got the speed back was putting AI properly into the work: strong tools in everyone's hands, agents taking the repeat jobs, and the team building things themselves.
Gaston was ICA's pet retail concept for dogs and cats. Four stores plus e-commerce, six people. I ran it.
The idea was agent driven retail. A small team, a lot of agents, built that way from the first day instead of bolted on later. The goal was ten people, a hundred agents and a billion kronor. Not ten people working very hard. Ten people who decide, with agents doing the rest.
The ordinary retail rules still applied. Buy well, price well, keep the shelves full, be good to the customer. Plenty of people know that trade. What is worth writing down is what the organisation looks like if you build it now, with agents in it from the start.
That is easier and harder than it sounds. Easier, because there is no old process to protect and nobody defending a job description written before the technology existed. Harder, because the limit moves. It stops being the systems and becomes what six people around a table actually understand.
One question came before anything got built: who is this for.
| Who is it for | What that meant | What it bought us |
|---|---|---|
| One person | Build it, own it, no permission needed | Nobody waited for a meeting to try something |
| The team | A conversation with tech first | Two people stopped building the same thing twice |
| The business | Into the backlog, prioritised like any other work | Nothing reached production by accident |
Under that sat a simple split. People owned the standard of what good looks like, anything irreversible, and the last step before a customer sees it. Agents owned volume, first drafts, monitoring, and the second pass nobody enjoys.
Three rules held it together. Agents could read anything and write nothing without a person saying yes. Every shared agent had one owner, a person and not the team, because an agent nobody owns is a hobby. And every owner answered the same question each quarter: does this still earn its place. If not, we turned it off. No ceremony.
The leverage did not come from agents running at night. It came from people who do not write code being able to make the system do something new without waiting for someone who does.
Small on purpose, then. One table, and everyone at it building. That is principle 03, and it is the reason the thing moved at all.
The first months were quick. Nothing existed, so anything we built beat the nothing it replaced. Then the obvious things were done, and what was left meant people changing how they worked. That is a different job from building.
Around month four of the AI push, the curve flattened.
It did not look like a problem. Everyone used the tools every day and liked them. The team had got very good at the first layer: summaries, drafts, lookups, tidy answers to tidy questions. That layer is useful and it is also a comfortable ledge. You can stand on it for a long time.
Everyone had got good at the easy things, and the easy things had stopped being worth much.
Getting off it took pushing. I did some of that in meetings, in the slightly annoying way of asking what the harder version would be. The rest we worked out together, by taking a real piece of work and pulling it apart in the open. Where does this come from. What decision does it feed. Who is waiting for it. What happens when it is wrong. Half the time we found a process nobody had designed. It had just accumulated, and no agent was going to fix that on its own.
Thinking like a coder is the short way to say what changed. Nobody had to write code. They had to break a job into steps, say what goes in and what comes out, decide what done looks like, and plan for the times it fails. Once people did that they stopped asking for a button and started describing a process, and what they built got a lot better.
I wrote principle 04 down afterwards, because I had assumed the bridge would build itself and then watched several months prove that it does not. Principle 05 came from the same place. The people who moved fastest knew the trade cold and were willing to write down how they thought. The second part is rarer than it sounds.
I would keep the shape. Small team, everyone builds, one named owner per agent, nothing writes to a live system without a person saying yes. I would keep the quarterly question about whether a thing still earns its place, and I would keep turning things off.
Three things I would change.
I would push past the easy wins sooner. The comfortable ledge is pleasant and it costs months. Next time I would treat the first successes as a warning and ask for the harder version in week two.
I would finish fewer things properly instead of starting many. Half built is worse than not built. Half built still asks for attention and gives nothing back.
And I would put someone on whether it all still works, with the authority to switch things off. Not a developer necessarily. Someone whose actual job it is. Things rarely fail loudly. They go quiet, and quiet is easy to mistake for fine.