“We were about to send a heap of unreliable email to the wrong people. It would have been embarrassing. We were stuck, and I thought, we’ve got to move on now.”<\/p><\/blockquote>\n
John Thatcher, Managing Director, Thatcher Associates<\/em><\/p>\n His word for the cause was rotten data.<\/p>\n That decision is worth sitting with, because almost nobody makes it. Most firms in that position send the campaign anyway, absorb the bounces, and tell themselves the list needs a tidy-up at some point. Thatcher Associates had spent 26 years and more than 3,500 placements building relationships across construction, property, engineering, healthcare, further education and finance, first in the UK, then the Caribbean, now the US. Most of that knowledge was still in the business. Very little of it was still usable.<\/p>\n This post covers what rotten data actually is, why CRM data hygiene projects do not fix it, and what had to be true before the firm could run 20 AI agents without multiplying the problem.<\/p>\n The failure at Thatcher Associates had a shape, and it is the same shape everywhere.<\/p>\n Records aged. Searches stopped returning what people expected. Routine work needed constant copying and pasting between places. And then the part that does the real damage: as fewer people trusted the database, fewer people updated it, which made it less trustworthy, which meant fewer people updated it.<\/p>\n That loop is the whole problem. It is self-reinforcing, it runs quietly, and it has no alarm. A database does not announce the day it stopped being worth opening. It just gets consulted less, until someone needs it for something that matters and discovers what it has become. The system meant to support the business had become the thing the business worked around.<\/p>\n The cost is not abstract. Around 71% of placements come from candidates already in the database before the job opened (Source: The Economics of Recruiting<\/a>)<\/em>. A firm that cannot trust its own records is not suffering an admin inconvenience. It has lost access to where most of its revenue comes from, and it is paying sourcing costs to rebuy people it already knows.<\/p>\n Every firm with a decayed recruitment database<\/a> has at some point planned a cleanup. Most have planned it more than once.<\/p>\n It fails for a reason that has nothing to do with discipline. A cleanup is a one-off effort aimed at a continuous process. Data decays every day, through people changing jobs<\/a>, companies restructuring and conversations happening that nobody logs. A project that ends cannot beat a process that does not. It also competes directly with billable work, and loses every time, because nobody has ever been congratulated for a Tuesday spent updating records.<\/p>\n So the only version that works is the one where updating stops being a task at all. Not better habits. No habit. The record has to be maintained by the act of doing the work, which means the system has to capture what happens rather than wait for someone to report it.<\/p>\n That is the change John was actually buying. He went looking for a platform that was web-native, reliable and easy to integrate, and that could support recruitment, business development and marketing without adding administrative work. That last clause is the whole specification.<\/p>\n “I think ease of use was a big part of why we chose Recruiterflow because when you open Recruiterflow, it works the way a recruiter thinks.”<\/p><\/blockquote>\n John Thatcher, Managing Director, Thatcher Associates<\/em><\/p>\n Emails and correspondence began recording themselves against candidate and client profiles. Sequences and recipes took over outreach. And the number that tells you the loop had reversed: logged business development activity rose 489%.<\/p>\n Read that as behaviour rather than as a metric. Activity did not go up 489%. The firm was always doing the work. What changed is that the work started leaving a trace, because leaving a trace stopped costing anyone anything. A database people trust is one they feed, and a database people feed is one they trust.<\/p>\n A clean database is not the goal. A database that answers questions is the goal, and those are different standards.<\/p>\n “We were working on a search in the Caribbean, and we were trying to remember a guy who had applied for a job about 18 months ago. We couldn’t remember his name, but we remembered that he worked in the US, and that he’d moved to one of the Caribbean nations, and we thought he also worked for a bank, but we couldn’t remember which one.”<\/p><\/blockquote>\n John Thatcher, Managing Director, Thatcher Associates<\/em><\/p>\n No keyword search survives that brief. There is no name, the employer is a guess, and the only firm detail is a career shape across two countries. In a Boolean system this is not a hard search, it is an impossible one, and the honest answer is that the candidate is gone.<\/p>\n AIRA Search found him.<\/p>\n “A lot of so-called AI search apps just convert your prompt into a Boolean string, whereas AIRA Search on Recruiterflow actually reasons with the database and the history.”<\/p><\/blockquote>\n John Thatcher, Managing Director, Thatcher Associates<\/em><\/p>\n That distinction is the one worth taking from this. Converting a sentence into filters is a nicer way to type a query, and it still cannot find a man you remember only by his trajectory. True natural language search reasons across what the firm already knows, including the things that were never typed into a field, which is why the quality of the underlying record decides the quality of the answer. Which is also why this section comes before the next one.<\/p>\n Thatcher Associates has since built a wider agentic system on Recruiterflow’s API, with external data sources and Claude as a reasoning layer. Recruiterflow stays the spine, holding the firm’s data, relationship history, jobs, conversations and workflows. Information from the wider system flows back through it, gets checked against what the firm already knows, and becomes an action.<\/p>\n Around 20 agents now run continuously. They identify hiring signals, research companies, verify information and propose actions for a consultant to review. New job orders rose 165%.<\/p>\n Here is the part most AI conversations skip. Those same 20 agents, pointed at the 2024 database, would have been a disaster. They would have researched the wrong companies, verified stale facts and proposed confident actions built on records nobody trusted. The campaign John stopped by hand would have gone out 20 times over, faster, with no human in the moment to catch it.<\/p>\n Agents do not clean up your data. They inherit it, and act on whatever state it is in at machine speed, with more conviction than any individual would have had. Data quality stops being a hygiene issue the moment something is acting on it autonomously, and becomes the thing that decides whether automation compounds or multiplies your errors.<\/p>\n So the sequence is not optional, and it is not a matter of taste:<\/p>\n Note the third point in the Thatcher setup: the agents propose actions for consultants to review. Judgement did not move. The work in front of the judgement did.<\/p>\n “It must automate anything that comes between a recruiter’s judgement and the placement.”<\/p><\/blockquote>\n John Thatcher, Managing Director, Thatcher Associates<\/em><\/p>\n With less time lost to admin, client submissions rose 38% and offers rose 60%.<\/p>\n Most firms reading this will not stand up a custom agentic system on an API, and they do not need to in order to use the lesson. The sequence holds at any scale, and the agents that ship inside a platform<\/a> are governed by the same rule as the ones you build yourself. If your team does not trust the database, no amount of AI on top of it is going to help, and buying some anyway is how firms end up with the problem covered in AI washing<\/a>: capability that performs on demo records and degrades on yours.<\/p>\n Three questions worth answering honestly before you buy anything else.<\/p>\n When did someone last make a decision from the database without checking elsewhere first?<\/strong> If the answer involves a spreadsheet, a personal folder or somebody’s memory, the loop is already running.<\/p>\n What percentage of what you know about a client is in a field, versus in an inbox?<\/strong> The gap is the part no agent and no search can reach.<\/p>\n If you turned on something autonomous tomorrow, what would it get wrong?<\/strong> You will know the answer immediately. That answer is your actual roadmap, and it is not an AI roadmap.<\/p>\n None of this requires a platform decision on day one. It requires accepting that the fix is structural rather than behavioural, because a system that needs people to remember to feed it has already told you how it ends.<\/p>\n The complete account, including how the agentic layer is wired and what the team measures, is worth reading in John’s own words.<\/p>\n Read the Thatcher Associates story<\/a>, or book a demo<\/a> and bring the records nobody has touched since 2022, because that is the only honest test of whether any of this works on your data.<\/p>\n Data decay is the ongoing loss of accuracy as people change jobs, companies restructure and conversations go unlogged. It is continuous rather than occasional, which is why periodic cleanups fall behind almost immediately and why the fix has to be a system that updates itself.<\/p>\n Usually because trust collapsed before the data did. Once a few searches return nothing useful, people check elsewhere first, which means they also stop contributing, which accelerates the decay. The loop is self-reinforcing and it rarely gets diagnosed, because nothing visibly breaks.<\/p>\n Not on their own. Agents act on the data they are given, so they inherit its errors and act on them faster and more confidently than a person would. Capture has to be automatic before autonomy is useful, otherwise automation multiplies the mistakes instead of removing them.<\/p>\n Ask it something only a reliable database could answer, such as finding a candidate you remember by career shape rather than by name. If that question fails, the database is storing records rather than knowledge, and no amount of search sophistication will recover what was never captured.<\/p>\n Data quality, but not as a separate project. The practical order is to make records maintain themselves through normal work, verify the database can answer a hard question, then add agents that propose actions for review before anything runs unsupervised.<\/p>\n","protected":false},"excerpt":{"rendered":"<\/span>Rotten data is a trust problem, not a tidiness problem<\/span><\/h2>\n
<\/span>Why the CRM data hygiene project never works<\/span><\/h2>\n
<\/span>The test of a database is what you can ask it<\/span><\/h2>\n
<\/span>Only now do the agents make sense<\/span><\/h2>\n
![\"How](\"https:\/\/recruiterflow.com\/blog\/wp-content\/uploads\/2026\/10\/5A-1024x342.png\")
<\/a><\/p>\n\n
<\/span>What this looks like if you are not building 20 agents<\/span><\/h2>\n
<\/span>Read the full story<\/span><\/h2>\n
<\/span>FAQs<\/span><\/h2>\n
What is data decay in a recruitment database?<\/h3>\n
Why do recruitment teams stop using their own database?<\/h3>\n
Can AI agents fix bad data in a recruitment CRM?<\/h3>\n
How do you know if your candidate database is still reliable?<\/h3>\n
What should come first, data quality or AI?<\/h3>\n