An AI agent almost never writes data from a single place. It quotes over WhatsApp, but it can also be corrected from a panel, called through an API from another system, and someone on the team needs a fast shortcut for urgent cases. Four doors into the same data. The question almost nobody asks in time is whether all four enforce exactly the same rule, or whether each one was built on its own, the day it was needed, without looking at the others.
This happened in our own project and time tracking system, and we're telling it because the failure isn't exotic at all: it can happen to any business that lets the same data be written from more than one place, with AI involved or not.
The problem: the rule existed, but only in one place
At AutoBoost we log the hours each collaborator spends on each client project, and those hours get deducted from a contracted hour bucket. There's a mandatory business rule: one entry per person, project, and day, never two. That rule was coded, and worked, in the main panel where most hours get logged.
The problem is that panel wasn't the only place an hour entry could be written. There were four different paths:
- The admin panel.
- The panel each collaborator uses.
- A direct API call, for integrations.
- A quick terminal entry, for when you need to log something without opening a browser.
The "one entry per day" rule only truly lived in the first one. The other three assumed it, reimplemented it their own way, or simply never checked it. Until an internal audit found two concrete gaps:
- Editing a project whose hour bucket was already closed silently unlinked the entry. The project dropdown only showed active buckets, so moving an old entry to a project with a closed bucket left the field empty, and the entry lost its link without anyone receiving an error.
- The default date came from the server clock, not the browser of whoever was logging the entry. Since the server lives in a different timezone, an hour logged near midnight could end up filed under the wrong day, depending on which path was used to log it.
Neither gap produced a visible error. The data got saved either way, just in the wrong place. And that's how three different clients' hour buckets ended up all still called "Bucket 1", because the fix that showed which client each one belonged to had never been finished across every screen that listed them. Nobody had noticed because, looked at one path at a time, everything seemed fine.
Why this isn't a code problem, it's a business problem
A business that bills by hours worked, by usage, or by a prepaid bucket doesn't catch this kind of failure with an alarm. It catches it when a client disputes a discrepancy, or when someone on the team tries to reconcile two reports and the numbers don't match. By then, the data has been wrong for weeks or months, and nobody knows since when.
The same thing happens to any AI agent that writes into more than one system or from more than one channel:
- An agent that quotes over WhatsApp and can also be corrected from an admin panel.
- An assistant that creates orders by voice and also accepts orders through an ecommerce integration.
- A process that books invoices automatically and also allows a manual upload when OCR fails.
In all three cases, if the validation rule (who can see which client, what price tier applies, which fields are required, which duplicates are forbidden) is only coded in the main channel, the other channels become a back door. And a back door doesn't announce itself when someone goes through it wrong: it just lets the bad data in, looking exactly as normal as the good data.
The decision rule: one rule, one place, four consumers
This is how we resolved it, and it's the rule we now apply to any system with more than one write path:
Validation doesn't live in each screen or each channel. It lives in a single place (one function, one service), and every entry path calls into it, instead of rewriting it on its own.
| Before (duplicated rule) | After (centralized rule) |
|---|---|
| Each channel codes its own version of the rule | A single checkpoint enforces the rule, every channel calls it |
| A new channel can forget to apply it | A new channel inherits it automatically, without rewriting it |
| The failure surfaces when a client disputes something | The failure surfaces at write time, before anything is saved |
| Fixing the rule means touching four places | Fixing the rule means touching one |
| Bad data saved gives no visible error | An attempt to save bad data is rejected on the spot |
Checklist: how to check if your own agent has this gap
Before you assume your AI agent (or any integration that writes client data) is protected, go through this:
- List every place the same data can be written from: panels, APIs, internal shortcuts, third party integrations, bulk imports.
- For every mandatory business rule (who can see what, which combinations are forbidden, which fields must be unique), check whether it's coded once or several times.
- Try to break the rule from the least used channel, not the main one. That's usually where it's missing.
- Check whether a failed save produces a visible error, or whether the data just gets saved wrong, silently.
- If you're adding a new channel (an integration, a shortcut, a public API), verify it calls the existing rule instead of reimplementing it.
Where this fits into a real AI integration
This is exactly what we check before letting an AI agent act on a client's real data: not just that the AI "understands" the rule, but that the system enforces it from every place data can come in, including the ones that don't get used every day. In the AI sales agent that quotes over WhatsApp inside the ERP of an industrial distributor carrying more than 50,000 products (full case), client, pricing, and stock validation doesn't live in the prompt or in the WhatsApp channel: it lives in the ERP, and every entry path runs through it.
It's part of the same integration work we do at AutoBoost before letting an agent touch production data: see more at /servicios.
If your business has more than one path through which the same data can be written (a panel, an API, an integration, an internal shortcut) and you're not sure whether all of them enforce the same rule, tell us about your case and we'll look at it with you.
