How I Run a One-Person PrestaShop Module Business with a Fleet of AI Agents

A few months ago I discovered my AI agents had left 154 git repositories dirty — and the fix wasn't a better prompt, it was an org chart.

Not 154 files. 154 repositories. Dozens of module codebases, each with uncommitted changes stacked on top of each other — some half-finished experiments, some work that was actually good and just never got shipped. Different agents, running at different times, had each done a bit and moved on. Nobody committed. Nobody cleaned up. The work wasn't lost, exactly. It was worse than lost. It was tangled, and I couldn't tell whose hands had touched what.

The instinct, when an AI agent does something dumb, is to go fix the prompt. Add a line. "Always commit your work when you're done." "Never leave repositories dirty." I tried that. It doesn't hold — and once you understand why, the whole way you work with these things changes.

This is a write-up of how I actually run the shop: one person, a catalog of well over a hundred PrestaShop extensions published in six languages, plus a handful of real online stores I operate myself on those same modules. A lot of the repetitive building and support work runs through a fleet of AI agents — always under my review; the architecture, the release calls, and the final sign-off stay with me. What follows is the part nobody puts in the sales page — the specific mistakes those agents made, and the machinery I built so they can't make them twice.

The agent is a brilliant employee with total amnesia

Here is the mental model that actually works. Your AI agent is a genuinely excellent contractor — fast, well-read, tireless — who has zero memory of ever having worked for you before. Every session, a brilliant stranger walks in the door. They've never seen your codebase. They don't know your conventions. They don't know that the thing they're about to do broke production last month, because they weren't there. Nobody was there, as far as their memory is concerned.

You cannot fix that person with a cleverer set of instructions on their way in the door. A prompt is a conversation. It evaporates when the session ends. What you need is the thing every real organization builds so it doesn't depend on any one person's memory: durable, written, enforced institutional knowledge. Onboarding docs. Runbooks. A pre-commit checklist stapled to the wall. Guardrails that make the wrong move physically hard to do.

I don't write better prompts. I write better memory. Amnesia is only expensive if you make the agent re-learn everything every time it walks in.

So the craft isn't prompt engineering. The craft is building the org around the amnesiac. And the single most useful realization I had is this: every guardrail in my setup is a scar. It maps to one specific, dated moment where an agent did something wrong, I felt the pain, and I turned that pain into a rule the environment enforces forever. My configuration isn't a wish list. It's a medical history.

Here are the scars.

Scar #1: The agent that wiped the vendor folder and took the shop down

Some of my modules depend on shared internal libraries — code I reuse across the whole catalog. For deployment reasons, those libraries live inside each module's vendor/ folder but are copied in by a sync script, not managed by the normal package manager. That's an unusual setup, and an amnesiac agent has no way to know it.

So one evening last autumn an agent needed to add a dependency, and it did the textbook-correct thing: it ran composer install. The package manager looked at the manifest, saw a pile of files in vendor/ that it didn't put there, and helpfully deleted them. Classes vanished. The live store started throwing 500s the moment a customer hit a page that autoloaded one of the missing traits.

The agent wasn't wrong by its own logic. It was wrong because it didn't have my memory. You cannot prompt your way out of this reliably — "be careful with composer" is exactly the kind of soft instruction an agent forgets under pressure. So the fix isn't a sentence. It's a wall:

# pre-tool hook: refuse the dangerous command outright
if command matches "composer install" or "composer update":
    BLOCK
    tell the agent: "This wipes synced packages. Use
    'composer dump-autoload', then re-run the sync script."

Now the mistake is unavailable. A fresh agent with no memory of the outage still can't reproduce it, because the environment says no before the damage happens. That's the difference between a prompt and a scar: the prompt hopes; the scar enforces. I have a small library of these hooks now, and every one of them is an afternoon I'm not getting back.

Scar #2: The 154 dirty repositories

Back to the cold open. The tangle happened because I'd solved a different problem — running many agents in parallel — without building the coordination layer that parallelism actually needs.

Running one agent is a conversation. Running a fleet is logistics, and logistics is a set of problems no prompt solves:

• They throttle and hang. Fire five heavy jobs at once and they pile up, stall, and time out. The fix was infrastructure: a runner that queues and load-balances jobs across parallel workers and puts a watchdog on every run, so heavy concurrent use doesn't pile up or freeze. Agents don't manage their own capacity. The org does.
• They collide. Two agents editing the same module at the same moment corrupt each other's work. The fix is a per-module file lock — an agent takes the module, works, releases it. With one twist I learned the hard way: a lock whose owning process is dead is not active work, it's litter. So the lock checks whether its owner still exists and clears stale locks automatically. A coordination system that deadlocks on ghosts is worse than no system at all.
• They commit each other's laundry. This was the real root of the 154. An agent finishing its own task would run the equivalent of "commit everything" — and sweep up three other agents' unfinished work in the same commit. So the commit path got a gate: an agent may only stage its own files, never a blanket "add everything." It literally cannot commit work it didn't do.

None of those three is clever. They're the boring machinery of a functioning workplace: clock in, don't touch the desk someone's mid-project on, don't sign for a package that isn't yours. I had to build each one because a specific agent, on a specific day, did the opposite.

Coordination has to enable completion, not freeze it. The locks exist to stop two agents editing one file at once — not to turn "finished work" into "frozen work." Committing is a checkpoint, not a cage.

That last line matters more than it looks. The first version of my locking was too strict, and agents started sitting on their hands waiting for locks that no longer belonged to anyone. A safety system that stops the work from getting done isn't safety — it's just a different failure. The rule now is that coordination must make finishing easier than not finishing, or it gets redesigned.

Scar #3: Never let an agent learn on the customer's store

This is the one rule I didn't wait to earn the hard way. Early on, an agent "just checked something" against a live shop — and the ten seconds before I confirmed nothing had actually changed were long enough to make the principle non-negotiable: agents build and test on a throwaway copy first, and only touch anything customer-facing after a change is proven.

A fresh agent has no instinct for which environment it's standing in. To it, a shell is a shell. So the environment makes the distinction for it: risky operations are routed to disposable clones by default, production is treated as a separate, guarded place, and the destructive-by-habit commands people run on a dev box (wiping a cache directory, resetting state) are blocked or rerouted on anything that faces a real customer. The agent doesn't have to remember the difference between "my sandbox" and "someone's shop." The org remembers it for them.

This is the single guardrail I'd want a customer to know about, because it's the one that protects them. The reason a module update rarely arrives with a surprise attached is that customer-facing changes go through a full dress rehearsal — on a disposable shop, where a mistake costs nothing — before release.

Scar #4: Make it fail loudly, not politely

Left alone, a helpful agent will paper over a problem. Something it expected wasn't there, so it quietly substitutes a default, wraps the call in a "just in case" fallback, and moves on. The task looks like it succeeded. On a customer's store, a silent workaround is worse than a visible error — because the visible error gets fixed today, and the quiet one ships and waits.

So the standing instruction is the opposite of the reflex: when something is wrong, crash loudly. Don't invent a fallback to hide a missing piece. Don't add defensive padding that turns a bug into a subtle wrong answer. Surface it, stop, and let a human decide. Combined with the dev-first rule, this means the ugly failures happen in the rehearsal room, where ugly is exactly what you want, and the aim is that customers see the take that worked, not the takes that didn't.

The part that makes all of it cheap: memory, done on purpose

The scars keep agents from breaking things. But the habit that makes the whole operation economical is the one that turns amnesia from a tax into a rounding error.

The naive way to use an agent on a recurring task is to re-explain it every time. Re-attach the example files. Re-describe the steps. Re-derive which paths matter and which gotchas bite. You pay full price, in tokens and in wall-clock, for knowledge you already discovered last week. That's the amnesiac re-learning the building's fire-exit routes every single morning.

So I made a rule for the agents themselves: at the end of a task, write the note. Not a diary entry — an operational memo. Where the relevant files live. The exact sequence that worked. The one non-obvious thing that will trip up the next run. These notes live in an organized tree, and — this is the part people miss — there's a one-line index of every note that loads at the very start of every session. The amnesiac walks in, reads the table of contents, and instantly knows what the business already knows and where to look it up.

# a representative note — boring on purpose, and that's the point
task: regenerate the catalog cover images
where: assets/covers/  (source templates in build/covers/)
steps: 1) run the build script  2) QA with the check script
gotcha: never touch a confirmed-good render; only regen the broken one
last run: 2026-05 — clean; the QA script caught one bad render

This is the entire thesis in one habit. A clever prompt makes this run better. A written note makes every future run cheaper, whichever agent picks it up. Institutional memory compounds; prompts don't. The first time I do anything here is expensive. The tenth time is almost nothing, and it's cheap precisely because the first nine wrote down what they learned.

What a task actually looks like going through this

Put it together and a routine job runs like a small, well-drilled team, not a chatbot session:

1. An agent reads the index, pulls the note for this kind of task, and starts most of the way to done instead of from zero.
2. It takes the lock on the module it's about to touch, so nothing else can collide with it.
3. It works on a throwaway copy. If something's wrong, it fails loudly there — not on a live store.
4. When it tries to finish, the guardrails hold: it can't run the command that once wiped a vendor folder, and it can only commit its own files, not the half-finished work sitting in the next repo over.
5. It writes back what it learned, so the note is a little sharper for the next agent — maybe a different one entirely.

Notice how little of that is "prompting." The prompt is one line: do the task. Everything that makes it safe, fast, and repeatable lives in the environment, not in the message. That's the whole trick.

The good-vs-bad ledger, and why every "good" is just "has memory"

People ask me for tips on using AI efficiently, expecting prompt tricks. The real list is duller and far more useful, and every item on it is the same idea wearing different clothes — give the amnesiac a memory and a prepared workshop:

• Bad: paste code into a free chatbot and copy the answer back by hand. Good: run agents where the work lives — on the machine, with real access to the files and tools — so nothing has to be described that could simply be read.
• Bad: a messy disk where every task starts with the agent hunting for where things are. Good: an organized material tree, so "find the thing" is a lookup, not an expedition.
• Bad: the agent greps the whole disk and reads twenty files to find one function. Good: prepare the workshop — fast search, and connectors that let it query the database, the browser, and the running containers directly instead of guessing.
• Bad: re-derive the same multi-step task from scratch every time. Good: the reusable note, and the index that surfaces it.
• Bad: one all-purpose agent for everything. Good: route the work — the model that's better at careful backend reasoning gets the backend; the one with better judgment on interface and words gets those. Same as staffing a team to strengths.

A stranger with amnesia in a well-run building — labeled shelves, a clear handbook, sharp tools laid out, and guardrails on the dangerous machinery — is astonishingly productive. The same stranger dropped into a cluttered room with a vague verbal briefing is a liability. Same worker. The difference is entirely the org.

Where AI helps, and where human review still wins

After all of this, I have a fairly sharp sense of the border.

AI wins on the mechanical, the parallel, and the well-scoped. Sweeping a change across dozens of modules. Drafting the first version of anything. Extracting and transforming structured data. Running a prepared workflow again from a note. Investigating a gnarly bug with more patience than I have at 6pm. When the task has a knowable right answer and a path to it, a well-equipped agent is faster than me and doesn't get bored on repetition three.

Human review wins on judgment, taste, and consequence. Anything a customer pays for. Anything with legal or financial weight — which is exactly why the invoice corrections above get a human signature, not an automated send. The architecture decisions where the "right" answer depends on where I want the business to be in a year, not on what the code says today. And the last-mile taste of writing and design, where "technically correct" and "actually good" are different things, and only one of them keeps a customer.

The line isn't fixed, either. Every scar in this piece is a place I once trusted an agent with something it wasn't ready for, got bitten, and moved the line. That's the actual skill — not deciding once where AI stops, but paying attention to where it fails and adjusting the boundary faster than the failures can pile up.

Why any of this should matter if you buy from me

Here's the honest version, because the framing of a piece like this can slide somewhere I don't want it. The agents don't make my modules for me, and I'd never tell you they did. They build scaffolding, run the tooling I can't be bothered to run by hand, draft first passes, and catch each other's mistakes — all inside a set of guardrails I earned one outage at a time. The judgment, the architecture, and the sign-off stay mine.

What the discipline buys you, as someone on the other end of a module or a support ticket, is boring in the best way. The same rule that keeps 154 repositories from tangling is the rule that keeps a release from shipping half-finished. The same wall that stops an agent from wiping a vendor folder is why a bad update is far less likely to leave my workshop. The same dev-first habit that protects my own test shops protects yours. Careful process upstream is what quiet reliability feels like downstream.

If there's one thing to take away, it's this: stop tuning the prompt, and build the memory. The agent will forget everything the moment the session closes — so put everything worth remembering somewhere it can't forget, and make the mistakes you never want to see again impossible, not merely discouraged. Do that, and a fleet of brilliant amnesiacs stops being a liability and starts looking a lot like a team.