When your automation starts
giving wrong answers.

What "wrong" usually looks like in practice.

Wrong answers from an automation tend to fall into one of three shapes. They look different, but they often come from the same place.

• Confident and incorrect. The automation produces a clean, well-structured output that contains a mistake. A draft email that addresses the client by the wrong name. A summary that states a figure that isn't in the source document.
• Right format, wrong detail. The structure is correct but the specifics are off. A quote that uses last year's pricing. A client note filed against the wrong project.
• Drifted tone. The automation's outputs used to sound like you. Now they sound like a press release. Nothing broke. Something shifted.

Each of these points to a different cause. The shape of the error is the first clue.

The three most common causes.

In order of how often they actually occur:

• Your data changed and the automation doesn't know. You updated your pricing. You started a new service. You changed the way you name client files. The automation is working from the version of your business that existed when it was built. This is the cause in the majority of cases.
• The inputs changed shape. The emails coming in are formatted differently than they used to be. A client is sending PDFs instead of typed messages. A form was updated and the fields moved. The automation is reading from the same place but the content arriving there is no longer what it expects.
• The underlying AI model was updated. If your automation uses a hosted AI service, that service updates its model periodically. Most updates improve things. Occasionally one changes a behaviour your automation relied on. This is less common than the first two causes but worth knowing about.

How to work out which one you have.

You do not need to understand the code to diagnose this. You need to do one thing: find a specific wrong output and trace it back.

Pick the clearest example of a wrong answer. Ask yourself what the automation would have needed to know to get it right. Then ask where it would have looked for that information. In most cases, you will find one of three things: the information is there but outdated, the information is missing entirely, or the information arrived in a format the automation wasn't expecting.

A useful shortcut: if the automation was getting things right three months ago and started going wrong recently, ask what changed in your business in that window. New services. New pricing. New staff. A new tool you started using. Something changed. The automation didn't change with it.

If nothing obvious changed and the outputs degraded gradually, suspect an AI model update. Your builder can check the version history on the service in under ten minutes.

What to tell your builder — and what a good response looks like.

When you contact your builder, give them one specific wrong output rather than a general complaint. "It's been giving bad answers" is hard to fix. "Here is the input it received, here is what it produced, here is what it should have produced" is fixable in an afternoon.

A good response sounds like:

“I can see what happened. The automation is using your old service list. If you send me the updated version, I can have this fixed same day. It is a data update, not a code change.”

A response worth worrying about sounds like:

“AI can be unpredictable sometimes. I will look into it but these things are hard to fully control.”

The second answer treats a diagnosable problem as a mystery. A builder who understands what they built can tell you, within a short call, what went wrong. If they cannot, that is more information about the build than about the AI.

When to fix it yourself, when to call the builder, when to rebuild.

• Fix it yourself. If the cause is outdated information the automation draws on — a price list, a service menu, a client list — and your builder gave you access to update that file, update it. You do not need them for this. Most good builds are set up so you can do exactly this.
• Call the builder. If the inputs changed shape or an AI model update broke a behaviour, that is a short fix. One call, one afternoon. It is the kind of maintenance your retainer, if you have one, should cover.
• Consider a rebuild. If your business has changed substantially since the build — new services, different clients, a different way of working — and the outputs are wrong in multiple ways, patching is the wrong tool. A rebuild scoped to where you are now will cost less and work better than a series of patches on something designed for a business that no longer exists.