What the source did
- Second-generation family business in Spain that services and repairs car-wash equipment for two big manufacturers and its own customers: a handful of field technicians, one office, and an owner who says nobody there is a programmer.
- Replaced the commercial package they used for years with their own ERP, in production: service calls, work reports from technicians' phones, quotes, purchase orders, supplier invoices, bank reconciliation, payroll inputs and Spain's new electronic invoicing. Issued invoices are signed and chained, and the database refuses changes to them.
- Agents built on Claude Code and an MCP server read the mailbox, create service calls from manufacturer emails, draft replies, reconcile what the manufacturer approved against their work reports, prepare supplier orders, and prepare (never send) emails.
- Anything with consequences shows up on his phone in Telegram with two buttons, and every decision is logged with who, when and the result. He says he reviews about twenty decisions a day in a few minutes.
- A second model from a different company reviews what the first one did and flags disagreements.
- About 1,500 written procedures the agents must read before they may write anything, enforced by the tooling: no procedure read, no write. Every mistake became a rule with a date and a reason.
- Local models on their own hardware handle the cheap, repetitive parts (classifying documents, embeddings, a first code review). Judgement stays with Claude.
- Production and testing run in separate copies with separate databases, and money logic (numbering per series, VAT, rounding to the cent) is tested against the real SQL on hundreds of random documents.
- Backups four times a day, encrypted, to three places, restored to a clean machine every few weeks to prove they work.
- A technicians' "expert" answers from the manufacturers' manuals plus the firm's own fault history, and each answer can be marked right or wrong.
- Heads-up: the company isn't named, his DEV account was created the day he posted, and he notes the post was written with help from the same assistant, then reviewed and edited by him.
“Now nothing with money moves without a human click.”— Jorge Garzón (@satgarzon), DEV Community
Summary written by Agent Cookbook from the original post. See the original for the full context. How we source recipes
Our notes
- What it takes
- Claude Code, an MCP server as the agents' only door into your system, written procedures the agents must read before any write, a phone approval channel (his: Telegram), and a separate test copy of the database. He says it took two years and that the owner has to be able to tell when the model is wrong.
- Where it breaks
- Agents acting first and reporting later (a day lost to work reports approved with wrong prices), long sessions that re-read the whole conversation, local models given jobs beyond their lane, and money logic without automatic tests for cancellations, retries and the signed invoice chain.
- Human checkpoint
- Anything that creates a document, changes a price or sends something waits for a two-button tap on his phone, and every decision is logged. Agents never send email.
- Tools involved
- Claude Code, An MCP server for your own system, Telegram (approval buttons), A second model from another vendor (reviewer), Local models (optional, for sorting documents)
✓ Verified Source link checked and still live. Notes by Thomas, editor. How we verify
Copy the prompt
Ours Our version, built only from the rules Jorge described in his post and comments. Not his wording; he published no template. Fill in the [BRACKETS].
You work inside our business system through its MCP server. You prepare; a person decides.
BEFORE YOU WRITE ANYTHING
- Read the written procedure for this task, the module's docs and the latest "what changed and why" note. If no procedure covers it, stop and ask me.
- If it isn't written in a procedure or a file, it doesn't exist. Don't rely on what was said earlier in chat.
JOBS
1. New manufacturer emails: create the service call and draft the reply.
2. Reconcile what the manufacturer approved against our technicians' work reports. List every mismatch with the document behind it.
3. Prepare supplier orders from approved work.
4. Prepare emails. Never send them.
APPROVALS
- Anything with consequences (creating a document, changing a price, sending something, anything touching money or customers) goes to my phone for an approve / reject tap. Log who, when and the result.
- Never edit an issued invoice. Corrections are new documents that reference the original.
- When you don't know whether a write landed, ask. Don't retry blind.
HOW WE WORK
- One session per topic. End each one with a short hand-over note for the next session.
- Build and test on the test copy. Never change production directly.
- When something goes wrong, propose a new procedure: the rule, the date and the reason.
Approval rule
🛡
Anything with consequences (creating a document, changing a price, sending something) waits for a two-button approval on Telegram, and every decision is logged. Agents prepare emails but never send them. Sending, buying, posting, and deleting always need a human.
Set it up
- List the jobs you want agents to prepare. His: service calls from manufacturer emails, draft replies, checking approvals against work reports, and supplier orders.
- Give the agents one door into your system, an MCP server, so every read and write goes through code you control.
- Write the procedures down and make reading them mandatory before any write. He enforces it in the tooling, not just the prompt.
- Route anything with consequences to a two-button approval on your phone (his is Telegram) and log every decision.
- Add a second model from another vendor to review the first one's work and flag disagreements.
- Keep a separate test copy with its own database. Build there, then release.
- Write tests for the money logic (numbering, VAT, rounding to the cent) and run them before every change.
- Back up several times a day and actually restore to a clean machine every few weeks.
Common failures
⚠
- Letting agents act first and report afterwards. He lost a day to a batch of work reports approved with the wrong prices.
- Long sessions that re-read the whole conversation on every step. One session per topic with a short hand-over note cut the cost to a fraction.
- Expecting the AI to "remember" something said in chat.
- Pushing local models beyond small, well-specified jobs. In his comments, a 27B local model scored 21 of 52 on 7 real backlog tasks, against Claude's 46.
- Building straight on production: one syntax error took the system down for a minute while technicians were on the road.
- Money tests that don't run automatically before every change, or skip cancellations, retries and the signed chain. He was still adding those.
Variations
- From the comments: invariant tests on random documents. Two real connections issuing at once, credit notes that sum to exactly zero per VAT rate, one tampered byte that must fail the chain check, and an idempotency key so a retried request makes one document. He ran them the next day: two found real bugs, and both fixes shipped that night.
- Watchers instead of trust (his follow-up): small read-only scripts check the database, jobs, backups and tax submissions every few minutes, and anything red for three days becomes a fix proposal.
- A commenter's idea: keep a few deliberately wrong documents (say, work reports with a known wrong price) and run your reconcile step on them after every change. If one comes back approved, the change stops there.
Get the 10 best agent setups. Free.
Plus new recipes every week. One email, no spam.
Unsubscribe anytime. Privacy