You made the call. Your automation quietly reversed it.

Last week I was in a live working session, inside an organization's admin consoles, when we stumbled onto a bug nobody was hunting for.

Here's the setup. When someone leaves a company on bad terms, or an account looks compromised, IT disables that account immediately. Standard practice. Minutes matter.

Except this organization's HR platform syncs to the employee directory every hour. The sync has one job: make the directory match HR's records. So if HR hasn't processed the termination yet, the sync looks at that urgently disabled account, decides it's a mistake, and turns it back on.

Security acts. An hour later, the robot politely puts it back.

Nobody built that on purpose. Nothing ever errored. Every system involved was working exactly as designed. We only caught it because we were walking through the flow live, asking dumb questions like "wait, what happens if HR is a day behind?"

I'd love to tell you I only find this bug in other people's systems.

A few weeks ago, in one of my own businesses, I reviewed a contact in our outreach system and ruled them out. Spam, not a real prospect, done. Thirty minutes later a routine data refresh ran, re-imported the contact list, and resurrected that exact contact as a live lead.

If I hadn't caught it, my automation would have sent a genuine, friendly business message to a contact I had explicitly killed a half hour earlier. The system I built was too rigid. It didn't account for all the possibilities. My decision wasn't part of its model of the world, so it treated my decision as dirt to sweep up.

That's the bug. Let's name it properly.

The problem

Most automation in a small business is some flavor of sync: make system B match system A. CRM to email list. HR to directory. Supplier catalog to your store. Booking tool to calendar. The sync's entire worldview is "A is the truth, and B should match it."

The failure isn't the sync breaking. The failure is the sync working, on a day when a human made a decision downstream.

Because to a sync job, there is no such thing as a decision. There are only differences. You disabled an account. You deleted a shift. You unsubscribed a customer who complained. You overrode a price. The sync sees a difference between A and B, and it corrects the difference. It cannot tell drift (something broke, fix it) from judgment (someone chose, respect it).

Everyone is worried about AI going rogue right now, and fair enough. But the more common failure in a real business is boring old automation faithfully undoing something a human did on purpose. No malice. No error message. Your decision just quietly stops being true, and you find out from a customer.

That's exactly where the reputation damage lives. The customer who told you to stop texting and got texted again doesn't blame your sync job. They don't know what a sync job is. They blame the business. They blame you. Then they tell people. Most small operators are not thinking about edge cases like this, and edge cases are precisely where trust gets burned.

How to identify it

You have this bug if you can't answer one question about every integration you run: "If I manually change something downstream, does my change survive the next sync?"

Here's a ten-minute audit:

1. List every place two of your systems agree with each other automatically. Native integrations, Zapier and Make flows, nightly imports, the "refresh" button someone on your team presses every morning. Anything that copies state from one tool into another.
2. For each one, ask whose truth wins. If system A always wins, then every manual change you ever make in system B is living on borrowed time. That's not automatically wrong, but you'd better know it.
3. Look for the symptoms you've been shrugging off. Edits that don't stick. Settings that mysteriously revert. "I swear I deleted that." The unsubscribed contact who keeps coming back. Those aren't gremlins. That's the sync telling you who's actually in charge.

Then run one live test: make a harmless manual change in the downstream system, wait for the next sync cycle, and see if your change survived. That single test will teach you more about your stack than any vendor documentation.

How to fix it

First, adopt the rule: human rulings are permanent. When a human deliberately decides something (this contact is spam, this account stays off, this customer is never contacted again), automation never reverses it. Some tools have this buried in settings as "don't overwrite manual edits" or field-level sync controls, almost always unchecked by default. Go check the box. If your tool can't do it, that matters more than whatever feature made you buy it.

Second, make the decision at the actual source of truth when you can. The fix for the re-enabled account isn't a smarter sync. It's making the disable happen where the sync reads from, or giving the sync a hold it must honor. If you can only act downstream, downstream is where your decision goes to die every hour, on the hour.

Third, build in small, testable increments. The instinct when you start automating is to wire everything up at once and call it done. Resist it. Every new connection between systems is a new set of edge cases you haven't met yet. Add one sync at a time, and give each one the manual-override test before you trust it with real customers. It feels slow. It's also the reason my near-miss was a near-miss instead of an apology tour.

Fourth, when you catch a reversal, fix the class, not the record. Re-deleting the resurrected contact solves today. Adding a rule the automation checks before touching any human-ruled record solves forever. If it happened to one record, it will happen to another.

None of this requires an engineer. It's a list, a question, and a ten-minute test. The businesses that get burned by automation aren't the ones running the most of it. They're the ones who never asked what their systems do when a human disagrees with them.

Hit reply and tell me what's on your bench this week. I read every one.