Read time: 6 Minutes

A collaboration with Geoff Momin from Interlay.

"AI is only as good as its foundation — and our data is sh*t!” Don’t

If you've sat in any roadmap meeting this year or scrolled LinkedIn for HRIS strategy, you've heard some version of this. Slay the “bad data” boogeyman first, then you can talk about AI adoption.

You nod knowingly, because you’ve lived in the HRIS trenches and have experienced the ugly truth firsthand.

It’s a fair point.

Except that this data cleanup is never coming.

Back in 2017, HBR found only 3% of companies' data met basic quality standards.

So, if clean data is the prerequisite, 97% of companies get permanently disqualified.

(And plenty of you are stuck right there. In last issue’s poll, “Honestly, not much. We’re trying to stabilize what we’ve got” came out on top at 55%!)

“Bad data" has snuck in as the most respectable reason to not start.

So what to do instead?

Bite it off bit by bit!

Ignite some energy by picking one messy process. Then, solve it with AI playing a part in the design. This forces you to decide how the data should've been maintained all along, and then the solution (if designed well) keeps it that way.

In this issue, we walk you through a use case of an agent Interlay built that does just this, without cleaning up a single historical record.

You’ll walk away knowing how to spot the same opportunity in your own tenant 🤓

Your recruiter just landed a dream candidate 🎉

Buuuut the candidate wants a bit more base and some help with relocation, so the recruiter makes it work and sends the offer from Greenhouse (a pretty common ATS choice).

The candidate signs, the recruiter marks them as a hire, and the “Hire Employee” process kicks off in Workday.

This creates a collision.

Hire Employee fails a critical validation 🚨 because the offer (and the resulting hire compensation) doesn't fall within the job req's range, which was set months ago!

Now someone has to cancel the hire and fix the job req, someone else has to approve the fix, and the candidate's start date is contingent on manually marking the candidate as “hired” in Greenhouse, again.

(If you read our last issue, this is textbook Step 1 friction: repeated manual fixes, people chasing approvals, the same step breaking every time.)

The original job req was probably accurate when it was approved. But the negotiation between the candidate and recruiter created new decisions to record. Those decisions stayed in Greenhouse, invisible to Workday, until Hire Employee tripped over them.

This is a common issue for orgs using a dedicated ATS that also want to give their recruiters room to secure strong candidates. Interlay built an agent to solve it.

The fix is a matter of sequence.

Right now, the offer moves through Greenhouse's own approval process, goes out to the candidate, and Workday hears about it only when the hire payload arrives to initiate the Hire Employee process. Nothing along the way updates the job requisition.

So Interlay put an agent at the start of that sequence to ensure system alignment, a smooth experience, and accurate records. Here’s how it works:

📝 Note: If you have Workday Extend, you can mirror the approval above as a custom business process in your tenant, which ensures the decision becomes a first-class, reportable event in Workday as well as in Greenhouse.

The decisions that used to live in an email thread, or only in Greenhouse, or nowhere, now get made before the Hire business process begins and get written into the object the business process depends on (job req), in the system of record (Workday) 🙌

The only manual step left is the one that should be manual: Comp's decision. And they get the info they need delivered right where they already work, in Teams!

Some of these checks are simple math, like whether base pay falls within the range.

Others take judgment. A signing bonus that looks “too high” for a job req planned for a candidate with around 8 years of experience might make perfect sense for a candidate with 15 years.

For making these judgment calls, Interlay used a fine-tuned version of gpt-oss, an open-weight reasoning model. It gets prompted with the data from both systems and teams: requisition, the offer, candidate details, and the compensation policy.

Then, it’s asked to return findings with the evidence behind each one. It reasons through the policy the way an analyst would, surfaces the awkward cases (like the varying years of experience above), and produces an explanation a compensation admin can read in 10 seconds.

[For interested engineers, Interlay’s started experimenting with replacing gpt-oss with TypeSafe's System One (the model is called jev). Its Noul primitive answers a yes/no question with a probability, and you can ask a whole checklist in one request: is the base within range, is the signing bonus within policy for this grade, is the relocation amount consistent with the location. It's a faster, cost efficient (less than $0.01 per validation!) implementation for this problem, and the probability gives a clean way to decide which offers need a closer look.]

This timing of the solution is deliberate, and it comes down to a Workday limitation.

Workday's web services can correct a completed Hire Employee event through Correct_Hire_Employee. But there's no API for correcting a business process while it's in flight, for Hire Employee or anything else! Thus, the most natural place for an agent to catch a problem (mid-process) is the one place it can't act.

The other API options require two records: a cancel or rescind and a re-initiated new event record. But then the context gets split into two places 👎 Alternatively, when you move the agent review to just before the business process begins, you generate a single clean record without any split or loss of context.

More importantly, at this point in the process, the agent never makes a hiring decision.

It acts only after the decision to hire has been made. The recruiter chose the candidate and drafted the offer; only then does the agent see all the cross-system information compared to the terms and the policy. The candidate details it reads (like 15 years of experience against a requisition planned for 8) serve to explain the deviation to the Compensation reviewer, who decides whether the company will stand behind those terms. The only thing the agent can do is send back an offer to the recruiter for revision based on the Compensation team’s response to the information it provided.

Automated tools that actually help decide who gets hired carry obligations of their own, and New York's Local Law 144 and the EU AI Act both single them out for good reason — AI Agents can’t be held accountable for biased or wrong decisions.

Keeping this agent on the far side of that decision is intentional.

Look at what this workflow overcame without anyone cleaning up any historical data!

The workflow saves each recruiter several thousand clicks a week. Recruiters still negotiate freely for the talent the org needs, and Comp still controls the exceptions.

And from the very first offer it processed, it established a new data practice: every deviation gets reviewed, every approval gets properly recorded, and every job req updates to match the offer that fills it.

That's the kind of data hygiene orgs spend years longing for, and it showed up as a side effect of solving one sticky problem ✨

Your version of this is already sitting in your tenant. Look for these signs:

Check two or more of these? Start there. Your data's never going to be perfect. And your first win with AI can clean it up anyway!

Did this issue help you out? Make you laugh? Did we miss any mission critical or helpful details?

Email us at [email protected] or leave a comment below — we'd love to know your thoughts 😊