How an agency works with Claude Code on a client’s store

When an agency runs AI agents on your store, the tooling changes and the accountability does not. An agent writes most of the code, but the contract, the named human who signs every change and the boundary around production stay where they were. The thing to check before you sign: the guarantees should live in the code, the configuration and the access rights, not in the prompt.

The story everybody remembers is a deleted production database

The loudest thread about coding agents is not a success story. In July 2025 The Register described how an AI agent on the Replit platform deleted a production database during a code freeze the user had declared, and the company’s CEO apologised publicly. Three Hacker News threads about it carry 179, 143 and 113 points (Hacker News public API, checked on 17 August 2026).

Our reading of it, marked as opinion: the failure was not that a model wrote poor code. The failure was that the agent had a path to production data, and the only thing on that path was a sentence typed into a chat window. An instruction is not access control.

Worth noting: the platform in that story sells itself on vibe coding, which is a different activity from engineering with agents. The difference is not the model. It is what the model receives as input and what happens to its output.

What an agent is never allowed to do on your systems

The list of boundaries is short and deliberately boring. Boring boundaries are easier to enforce than rules that need interpretation:

• Production. The agent works on a branch and in a preview environment. The production URL, production credentials and the production database sit outside its reach.
• Database migrations. The agent prepares the migration together with the way back. A human runs it, after a backup.
• Secrets. API keys, payment credentials and access tokens live in a secret store, never in the repository and never in a prompt.
• Destructive operations. Deletes, overwrites and bulk updates with no way back need explicit human approval.
• Deploys and anything outgoing. Shipping to production, emailing your customers, pushing a feed to a marketplace, charging a card. If the outside world sees it, a human decides it.
• Customer data. The agent works on a reduced copy, not on the live orders table.

Why a prompt is not a guardrail

One principle sits under all six points. A prompt is a request, a permission is a fact. The sentence "do not touch production" holds exactly as long as the model chooses to honour it, which is until the first case nobody anticipated.

There is a second, less obvious side. An agent reads content nobody controls: a supplier file, a customer email, a page from the web. That content can contain an instruction, and agents do not separate data from commands as reliably as we would like. If your only defence is "we told it not to", you have no defence.

How a change actually reaches your production

The flow is ordinary, and that is the point: branch, automated gates, review, preview, then release. The agent speeds up the work inside that flow without removing a single step from it. We describe the gates and the adversarial review in detail in the piece on how we build with agents. This one is about what changes when the repository is not ours.

The agent can prepare anything. A person releases it, and that person signs for it.

The signature is literal. A change carries the name of an engineer, not the name of a tool. If something goes wrong after a release, the answer "the agent did it" does not exist. Accountability for the release sits with the vendor, and the contract should say so.

Detection is a separate job. The failures that hurt most are rarely loud, because AI automations fail quietly. That is why what matters after a release is monitoring, an alert and a report of what actually ran, rather than a confident summary in a chat window.

Approving changes when you do not read code

This is the problem practitioners raise most often and solve least often. A vendor puts a pull request in front of a store owner and calls it approval. A diff is an engineering artefact. For the person running sales it is unreadable, and it asks for consent to something that cannot be assessed.

What a client should get instead is a set of things that can be judged without knowing git:

• A preview link for every change: the store as it will look in production, running on test data.
• A note in plain language: what changes, where to click, what to check and what happens if we do nothing.
• Screenshots or a short recording for anything visible in the interface.
• Decisions framed as business questions, with a recommendation and a date, instead of code to evaluate.
• One weekly list: released, waiting for your decision, blocked on us.
• For risky changes, a feature flag, a staged rollout and a rollback in one step, so your approval stays reversible.

Whose code is it, and what stays after we part ways

This is a contract question rather than a technical one, which is why it is lost at the agreement stage and not in the code. Our position is plain: the platform is yours. Code, data and the database stay on your side, there is no revenue share and no ceiling set by somebody else’s roadmap, and when the collaboration ends you keep a working platform, not a terminated licence.

Whichever vendor you pick, six things are worth writing down before the first line of code:

• The repository in your organisation from day one, or transferred on a named date.
• The accounts for hosting, domain, payments, error tracking and analytics in your name. The vendor gets access, not ownership.
• Secrets: who holds them, and a clause that they are rotated the moment access ends.
• Documentation of the architecture, the data model, the decision log and the runbooks, in the repository rather than on somebody’s drive.
• Agent instruction files (CLAUDE.md or AGENTS.md) and the skills the project uses, because they are part of how the project gets maintained.
• Reusable parts: which building blocks the vendor carries between clients, under what licence, and what happens to them at the end. Ask us that one too.

The last point tends to go unsaid, so here it is plainly: every vendor that delivers quickly reuses something. That is not a flaw, it is the reason a fixed price holds at all, and we describe the billing model on the pricing page. It becomes a problem only when nobody wrote down which parts those are.

Project context as an artefact, not folklore

An agent that has to guess your domain will guess your architecture too, and that is the most expensive kind of mistake. So the things that normally live in people’s heads go into the repository: the data model, the vocabulary, the conventions, the decisions and, most useful of all, the options you rejected together with the reason.

Rejected options save the most time. Without them, every new engineer and every new agent proposes again the idea somebody deliberately killed, and the whole discussion runs a second time, now without the person who remembered why.

An honest limit: dead documentation does more harm than none, because an agent treats it as truth. So the document changes in the same pull request as the code, and the file is meant to be compact rather than complete.

The same artefact answers two questions at once: what an agent needs to work sensibly, and what your next vendor needs to take over. It is also the idea behind BEAM, the platform we build on: one place to run your whole eCommerce, with AI agents that know the context of your company rather than only its numbers (how we build it).

The procedures we hand to agents are public. We released our eCommerce skills for AI agents under an MIT licence, and shorter prompts for everyday work sit in the AI Library. You do not have to take our word for how we work, you can read it.

When this does not make sense

There are situations where all this machinery is a cost with no return. The four most common:

• A one-off small change. Setting up a safe loop costs more than swapping a banner. Someone should simply do it by hand.
• A team that does not want it. If nobody on your side will open a preview and answer questions, the decision queue grows and the speed disappears. It is symmetrical on the vendor side: agents forced on engineers who reject the process produce mess faster.
• A system with no tests and no reproducible environment. The agent has no feedback signal, so it accelerates debt instead of removing it. Gates first, agents second.
• Data you are not allowed to copy. If regulation or the architecture makes a safe working copy impossible, most of the advantage evaporates and the honest answer is a slower, manual path.

There is also a broader answer than the way of working. If your store is a simple catalogue that fits inside a subscription platform, the right decision may be to change nothing at all. We say that even though we build platforms you own, such as Medusa builds.

What to ask a vendor before you hand over the keys

Six questions that show within minutes whether the process exists or is a story:

• Which environments can your agents reach, and what technically enforces that?
• Where do secrets live and who can read them?
• Who runs migrations and deploys, by name?
• How will I approve a change without reading code?
• What is in the repository besides code?
• On the day we stop working together, what do I already have in hand?

The same rules apply after launch, in maintenance and growth: same branch, same gates, same human on the release. The difference between an agency that uses agents well and one that uses them dangerously is not the model, the subscription or the number of agents run in parallel. It is whether the boundaries exist outside the chat window. Ask for them in writing.