What an AI agent needs from your ATS and CRM

Five properties, and “has AI built in” is not one of them. An agent can work inside your ATS if it exposes, for reading and writing, the objects you handle every day, if it reliably signals what changes, if it can express permissions per person, if it gives you your history back, and if it grants access to the fields you added yourself. The rest is preference.

That ranking surprises buyers, because the question asked in the demo room is almost always “does your ATS have AI”. It is the least predictive criterion on the list. What determines what an agent can do for you is not what the software does itself, it is what it lets a third party do.

Does your ATS have an API, and what does it put in it?

The right question is not whether an API exists, since one almost always does, but whether it exposes the objects your work actually rests on.

An ATS can publish a perfectly decent API for candidates and job adverts while exposing nothing of client requirements, profile submissions, pipeline stages or interview notes. That is precisely where the work happens, and it is often what is missing, because those objects are the most vendor-specific and the most expensive to document.

Two things get forgotten at this stage without fail. Writing first: many APIs are generous on reading and very poor on writing, which condemns the agent to proposing without ever acting, that is, to being an assistant again. Custom fields second: in an agency using the same software for six years, the useful information is almost always in fields somebody added, and an API that does not expose them gives access to the shell without the contents.

Check it in ten minutes rather than in a meeting. Ask for the public documentation, look for the three objects that carry your business, and see whether they appear for writing. Documentation that is not public is an answer in itself.

Are the events reliable, and what happens when they drop?

They are not, and that is a property of the world rather than a flaw in one particular vendor.

Webhooks, the notifications a system sends when something changes, are fast and they lose messages. The order of magnitude accepted by people who build these integrations is 0.5 to 2% of events lost per month for an integration that merely listens. A serious integration therefore backs the notification with a periodic re-read and a reconciliation, which costs work and interests nobody in a demonstration.

The consequence for an agent is worse than for an ordinary synchronisation. A missed record does not produce an error, it produces a confident and incomplete answer: the candidate who replied yesterday does not appear, the agent concludes they did not reply, and nothing in the conversation signals that something is missing. This is the integration version of a rule we apply everywhere: an absence of result has to be an event, otherwise it is indistinguishable from ordinary silence.

What to ask a vendor therefore fits in two questions: which events are emitted, and is there a way to re-read everything that changed since a given date. The second matters more than the first.

Can permissions be expressed per person?

This is the point that disqualifies the most software, and the one nobody looks at until there has been an incident.

An agent must act with the rights of the person talking to it, never with its own, because an identity of its own creates a path around every permission you have set. We have written why an agent has no identity of its own and why the test is a single question: do two colleagues with different rights receive the same answer?

For that answer to be no, the ATS has to be able to answer “what is this specific person allowed to see”, in real time and through the API. Many systems only have profiles: recruiter, manager, administrator. A profile describes a category, not a person, and it says nothing about the restrictions by client, by team or by assignment confidentiality that do exist inside the software. The integration is then left choosing between a technical account that sees everything, which is the workaround, and reimplementing the visibility rules on its own side, which is a second source of truth and therefore a scheduled divergence.

We took that constraint seriously enough to make it a property of the product rather than a recommendation: Balt acts with the rights of the person talking to it and has no account of its own. The consequence is unpleasant and we keep it. When an ATS cannot answer per person, we reduce what Balt may do there instead of connecting a broad account that would work immediately.

Does it give you your history back?

The question sounds off-topic and it decides the value of everything above.

A useful agent knows your company, and that knowledge comes from what you have written over six years: interview notes, the reasons behind a rejection, exchanges with a client. If the export stops at candidate records in a spreadsheet, you are not exporting your memory, you are exporting a directory. We have written about cleaning the data an agent touches at the moment it touches it, and the same applies to what the software agrees to hand back.

The phrasing that gets a real answer is this one: if we left tomorrow, what exactly would we get back, in what format, and how long would it take. It is unpleasant to ask during a sales cycle, and that is exactly why it is informative.

Should you go through a unified API?

Often yes, provided you know what you are buying, because it is a trade rather than a technical simplification.

Unified API providers expose several dozen ATS systems behind a single interface contract, and the gain is real: integrations that took quarters take days. That is decisive when you have to read your clients’ systems rather than your own, which is the ordinary case for an agency working on delegation.

In exchange, you add a third party holding credentials on your systems and on your clients’, and deciding what you see of each ATS. That is exactly the definition we apply elsewhere: an intermediary of this kind is a supplier, not a connector, and it gets chosen with the questions you ask a subcontractor. The common denominator is also a constraint: a unified API exposes what every ATS can do, so rarely your custom fields.

For a single ATS, the one you use, a direct integration avoids the intermediary and keeps access to the specific objects. For ten client systems, the intermediary almost always earns its place.

And if your ATS ticks almost nothing?

That is not a reason to change tools, and it is the least spectacular conclusion in this article.

A well-kept system your teams genuinely write into beats a modern one nobody enters anything in. The grid above tells you what an agent will be able to do for you, in what order, and what will have to be worked around; it does not trigger a migration. Start with the tasks that only need reading, which are the first ones to delegate anyway, and keep writing for when the access exists.

If the choice genuinely is on the table, because you are switching software or installing your first one, it deserves comparison work this blog does not do. We publish Cobalt, the ATS and CRM for the same trade, and its blog keeps an up-to-date comparison of recruitment software for agencies and IT services firms that I would rather send you to read than redo less well here. The difference in role between the two products is set out in what Cobalt does and what Balt does.