1300 71 61 41
an AI agent is a very fast, very confident junior who believes everything your CRM tells it. If two records disagree about the same company, it will pick one and act. Five checks tell you whether you are ready, and four of them are specific to Australian data in a way no overseas guide will mention.
This is the article we wish existed before the "we should do something with AI" conversation, because the honest first answer is usually "not yet, and here is the two weeks that fixes it".
What data does an AI agent actually need?
Less than people expect, and different from what people expect.
An agent does not need a beautiful CRM. It needs an unambiguous one. Specifically, it needs to answer three questions without guessing:
- Which record is the real one?
- What is currently true about it?
- What am I allowed to do with it?
Everything below is a way of testing those three. Notice that "is the data complete" is not on the list. Completeness is nice. Unambiguity is load-bearing.
The five checks
1. Is there one record per real thing?
Duplicate rate, and specifically duplicate rate on the identifier that actually matters.
In Australia that is the ABN or ACN, not the company name. "Smith Building Co", "Smith Building Co.", "Smith Building Company Pty Ltd" and "SMITH BUILDING" are one business and four records, and only the ABN knows that.
Most portals we open have been deduplicated on name at some point and never on ABN. If you do one thing from this list, do this one. HubSpot's duplicate management and data quality command centre will get you started.
Why it matters for an agent specifically: a human looking at four similar records notices, hesitates, and asks someone. An agent asked "what is happening with Smith Building" reads one of them, answers confidently, and is wrong in a way that sounds completely right.
How to check it: export companies with ABN, count non-unique ABNs, and separately count records with no ABN at all. That second number is usually the bigger problem.
2. Are the fields the agent will read actually filled in?
Not overall completeness, which is a vanity metric that makes you feel bad about 400 properties nobody uses. Completeness on the specific properties this job depends on.
Pick the ten fields your agent will read. Measure fill rate on those ten only.
If any is below about 70%, the agent will spend most of its time reasoning from absence, and reasoning from absence is precisely where models invent things. A model given an empty "last contact reason" field does not say "I don't know". It infers.
How to check it: a list view with each of the ten fields as a column, sorted by empty. It takes ten minutes and it is usually sobering.
3. Do the Australian fields survive contact with a machine?
This is the check that does not exist in any overseas guide, and it is where a lot of quiet damage happens.
| What goes wrong | What it breaks |
|---|---|
|
Mobile numbers in two formats. The same phone arrives as |
Matching treats them as different people. An agent normalising to a North American format mangles both |
| Postcodes that lost a leading zero. Anything through a spreadsheet turns 0800 into 800 | NT and some NSW records fall out of any region grouping |
| State and territory as free text. QLD, Qld, Queensland, and the occasional typo | Three or four values meaning one thing. Every report by state is quietly wrong |
| Addresses in one field. Unit, street, suburb, state, postcode in a single line | An agent asked to work by region cannot, and will guess from the suburb name |
| ABN stored with spaces, or in a text field with notes in it | Deduplication on ABN silently fails, which undoes check one |
None of this is exotic. All of it is invisible until something automated starts reading it, and all of it is fixable with a normalisation pass before you build anything.
4. Do the associations hold up?
Contacts attached to the right companies, deals attached to the right contacts, tickets attached to anything at all.
People skip this check because it is tedious, and it is the one that produces the most embarrassing agent failures. A broken association does not look like missing data. It looks like confident, fluent, wrong context. The agent will tell you about the wrong client's project in complete sentences, and the person reading it will believe it, because why wouldn't they.
How to check it: pull twenty records at random from the object your agent will work with and verify every association by hand. Twenty is enough. If two are wrong, stop and fix the data before you build.
5. Can you prove consent?
The check that turns a data quality issue into a legal one, and it is specifically Australian.
Under the Spam Act 2003, if you send a commercial electronic message you need consent, and the burden of proving it is on you. Australian rules distinguish express consent from inferred consent, and inferred consent depends on a real, provable, ongoing relationship rather than a list you acquired. You also cannot outsource the obligation to a third party or a purchased list, and your unsubscribe cannot require someone to log in or hand over more information.
So the check is not "do we have an opt-in field". It is: for any contact this agent could email, can we show what consent we hold, when it was given, and on what basis.
If that lives in someone's memory rather than in a field with a date on it, an agent with send permission is a genuine exposure rather than a theoretical one.
Worth noting the direction of travel too. From 10 December 2026, transparency obligations for automated decision making land in the Australian Privacy Principles, which means the decisions your automations make about people become something you describe publicly. Clean consent and decision data is the same body of work.
Want a check run on your set-up?
How clean is clean enough?
Cleaner than you think for the fields in play, and much dirtier than you fear for everything else.
You are not doing a data project. You are clearing a path for one job. That distinction is the difference between shipping in three weeks and starting a remediation programme that is still going at Christmas.
Our working thresholds, which are judgement rather than science:
| Check | Good enough to proceed | Stop and fix first |
|---|---|---|
| Duplicate rate on ABN or ACN | Under 2% | Over 5% |
| Records with no ABN at all | Under 10% of active accounts | Over 30% |
| Fill rate on the ten fields in play | Over 90% | Under 70% |
| Australian formats normalised | Phone and state done | Neither done |
| Association integrity | Spot check of 20 passes clean | Any orphaned deals, or 2 or more wrong in 20 |
| Provable consent for anything the agent can email | In a field, with a date and a basis | Anywhere else |
What breaks first when the data is messy?
In our experience, in this order.
1. Trust, immediately. The agent gets one client's name wrong in front of the person who owns that relationship, and that person never uses it again. Nothing technical broke. The project is over.
2. Then the numbers. Anything grouping by state, industry or company gives a different answer to the report the team already believes. Now you are debating the data instead of doing the work, in a meeting, with a screen shared.
3. Then the cost. An agent reasoning around bad data does more work per run: more retrieval, more tokens, more retries. You pay for the mess in usage, monthly, forever.
4. Then, rarely but expensively, the outside world. Something gets sent to someone who should not have received it, and now you are reading the Notifiable Data Breaches guidance on a Friday afternoon.
Point one is the whole reason to do this before anything else. We have watched an otherwise good build die because it was demonstrated on a portal nobody had cleaned, and the failure everyone remembered was "the AI got it wrong", which was the one part that worked exactly as designed.
How long does the cleanup take?
The honest shape, for a mid-market portal with a few years of history:
- Duplicate and format work: days, not weeks. Most of it is mechanical and a lot of it can be scripted.
- Association work: longer, because it needs somebody who knows the business to make judgement calls. This is the bottleneck and it is a people bottleneck, not a tooling one.
- Consent work: either quick or a project, depending entirely on whether anyone recorded consent at the time. There is no middle case.
What we would not do is a full data remediation before touching AI. Scope the cleanup to the one job you are trying to ship. The rest can wait, and shipping something is what buys you the goodwill to fix the rest.
Do this on Monday
- Pick one job you want an agent to do. One. Write it in a sentence.
- List the ten fields it would read.
- Run the five checks on those ten fields only.
- Fix what fails, ship the job, then pick the next one.
Half a day for steps one to three. That half day is the highest-return work available to you in this whole area, because it either saves you a failed project or gives you a green light with evidence behind it.
Frequently asked
Can AI clean the data for us?
Partly, and carefully. Formatting and normalisation, yes, that is a good use for it. Deciding which of four duplicate records is the real one, no, because the cost of a wrong merge is high and irreversible. Use automation for the mechanical passes and a human for the judgement calls.
Do we need to fix everything before starting?
No, and trying is the most common way this stalls. Fix what the first job touches.
Is HubSpot's data quality tooling enough?
For duplicates and basic formatting it is a real help and it is included. It will not tell you your associations are wrong, and it does not know what an ABN is, so the Australian checks stay manual.
What if our data lives in three systems?
Then the ambiguity question gets harder and more important, because now two systems can disagree. Decide which system is authoritative for each object before you build, and write it down.
Who should own this?
Whoever owns the CRM, which should be a named person rather than a committee. We wrote about that in who should own your CRM.
How often should we re-run the checks?
Quarterly, and after any migration or integration change. Data quality is not a project you finish.
Where to go from here
If you want the narrower version we published for a single object, the ticket-scoring one is how to score your HubSpot support tickets for AI readiness. If your CRM problems predate the AI conversation entirely, the diagnosis is 6 CRM problems that only show up months after onboarding. And if you are about to give an agent write access, read how to deploy HubSpot AI agents without breaking your data first.
Not sure which mess actually matters?
talk to us about the cleanup.
Last thought, and it is the useful one. Every business we have run these checks on already knew their data was messy. What they did not know was which mess mattered. Those are different problems, and only one of them is worth a project.
.svg){kind=logo}
