Bullhorn + AI agents: what a write-back workflow actually looks like

What is the premise of the integration?

Bullhorn stays the system of record. The agents hold working state — canonical requirements, routes, shortlists, screening scorecards — but the durable, client-facing truth about a submission lives in the ATS where recruiters already work.

That is a deliberate architectural choice rather than a limitation. An agent layer that becomes a second system of record forces every agency into a migration decision, and migrations are where deployments die.

What do the agents read?

Four things, and one of them is more delicate than it looks. Job orders become canonical requirements after parsing. Candidates and their résumé attachments feed shortlisting and semantic scoring. Contacts and companies resolve the end client on a requirement. And work authorization feeds the hard filter.

The delicate one is work authorization, because it is almost never in a standard field. It lives in a custom field, or in two custom fields that disagree, or in the free text of a note. Field mapping at setup is therefore not a formality — it is the step that decides whether the gate downstream has anything reliable to compare against.

The rule for missing data is exclusion, not assumption. A candidate whose authorization cannot be read is not eligible until someone establishes otherwise, and the shortlist should show that as a clearable work item rather than dropping them silently.

What gets written back?

Less than people expect, deliberately. Writing more into an ATS is not a feature; each additional written object is another thing that can be wrong, another shape a recruiter has to recognise, and another cleanup job if the integration is removed.

• Submissions, against the originating job order, in the same shape a recruiter would create.
• Notes on the candidate summarising the screening outcome and the named gaps.
• Notes on the submission recording which vendor route it went out on.
• Nothing else. Canonical requirements, routes, and scoring stay on our side.

How do canonical requirements map back to job orders?

One canonical requirement usually corresponds to several Bullhorn job orders, because a vendor blast arrives as multiple records. The canonical object is ours; each job order stays itself in the ATS and is attached to the canonical as a route.

Write-back therefore targets the specific job order the submission actually went out against, not the canonical. That keeps the ATS record honest: the submission belongs to the vendor route that carried it, and the rate on it is that route’s rate.

This is the piece most likely to be got wrong by a naive integration. Collapsing twelve job orders into one in Bullhorn would be destructive and irreversible, and it is not what dedup means.

Why should write-back stay off at first?

Because the first week is an evaluation, not a deployment. Running read-only lets an agency compare what the agents produced against what the desk would have done, on the same requirements, without anything reaching a client-facing record.

It also surfaces field-mapping errors before they matter. A work-authorization field mapped to the wrong custom field produces visibly wrong shortlists in read-only mode and a compliance incident in write mode.

Turning write-back on should be a deliberate second decision with a named person making it, not a step in an onboarding checklist that everyone clicks through.

How do you avoid duplicate submissions?

Idempotency keys derived from the work item, checked before the write. Agents are designed to be retry-safe, and the failure mode a connector introduces is a write that succeeded on the ATS side and timed out on ours.

Without a key, the retry creates a second submission. In a staffing context that is not merely untidy — a duplicate submission against the same job order is exactly the pattern that causes right-to-represent collisions, which disqualify candidates.

The check has to be against the ATS record rather than only against our own state, because our state is what was lost in the failure.

What does connector latency change?

It means our view of Bullhorn is stale by the polling interval, and any design that assumes otherwise will misbehave. A job order closed in Bullhorn five minutes ago may still look open to us.

The mitigation is to re-check state immediately before any write rather than trusting the cached view. That is a cheap call and it converts a whole class of race conditions into a no-op.

It is also worth saying plainly to customers. A connector is not the same as living inside the record, and an agency evaluating this should hear that from us rather than discover it in week three.

What about the audit trail?

Two trails, both complete. Every submission and consent action is written to an immutable, hash-chained log on our side, which is the record that survives regardless of what happens in the ATS. Submissions are also written back to Bullhorn so the ATS record is complete for anyone working inside it.

Candidate PII stays out of logs and URLs on our side throughout. That is a constraint on how the record is written, not a reason to write less of it.

The test for whether the audit design is right is simple: if the integration were switched off tomorrow, could the agency answer "who was submitted where, when, and with whose consent" entirely from Bullhorn? The answer needs to be yes.

What happens if you turn it off?

Nothing breaks, and that is the design goal. Submissions written by the agents look like submissions written by a recruiter, notes read like recruiter notes, and no Bullhorn object depends on our system to be interpretable.

What is lost is the working state — canonical requirements, route comparisons, shortlists, scorecards. Those are ours and they do not survive, which is the honest trade for not making the agency migrate anything to get started.

Which failure modes should you plan for?

Four, and none of them are exotic. The first is a field-mapping error discovered after write-back is enabled, which produces submissions built on the wrong authorization data. The mitigation is the read-only week, and the reason it is not optional.

The second is connector downtime. Agents are idempotent and safe to retry, so a sync outage delays work rather than corrupting it — the pipeline resumes from where it stopped. What matters is that the delay is visible to a recruiter rather than silent, because a queue that has quietly stopped moving looks identical to a quiet morning.

The third is schema drift. An agency renames a custom field or repurposes one, and the mapping that was correct at setup is now reading the wrong data with no error anywhere. Periodic validation against a known-good sample catches this; nothing else does.

The fourth is permission scope. A connector authorised with more access than the workflow needs is a liability with no upside, and the scope that gets requested at setup is the scope that stays for years. Ask for reads on job orders, candidates, contacts, and companies, and writes on submissions and notes — and nothing else.