FIELD NOTES — FROM THE FOUNDER

What we're learning by using it.

Short notes from building Paladin and running real calls through it. Written by John Evans, CEO of Ashford & Briggs. Only what is live gets described here.

2026-09-11

The wrapper problem

A year ago most AI startups were a wrapper around ChatGPT.

This year they're a wrapper around Claude Code or Codex. Same idea, one level up. Raw model to agent harness.

That's fine. Some of those will be great businesses. But it's not what we're doing.

Paladin's core tech is the phone line. The call comes in, the audio streams through us, the recruiter gets guidance while the candidate is still talking. You can't wrap that around an agent harness. You have to build the telecom stack, and then you have to make it fast enough to matter on a live call.

Somebody told me this week that every hard problem you get through makes the moat a little wider. I think that's right. The phone is the hard problem. It's also the whole product.

2026-09-11

Junior to senior in weeks

Four senior recruiters have seen Paladin so far. One of them ran a national staffing firm.

His read, roughly: you could take someone fresh out of school, hand them this, and have them running calls like a senior recruiter in a couple of weeks. And your senior people double their output.

I've been careful not to put numbers on this that we haven't earned yet. But that second part is the one that gets the owners leaning in. Not replacing recruiters. Making the ones you have twice as useful.

Here's what the recruiter actually sees during a call. The candidate's file is digested before the phone rings. The questions are ready. The follow-ups come in while the answer is still landing.

2026-09-11

I used it on a real interview today

Ran an actual hiring conversation through Paladin this afternoon. Not a demo script, a role we're filling.

Before the call it wrote the job description and the question set from the candidate's profile. During the call it fed me follow-ups, some I wouldn't have thought to ask. After the call I had a summary, a fit score, and a list of next steps before I'd finished my coffee.

It also surfaced three UI bugs, which is what happens when you use your own product for something that matters. Those are on the board for tomorrow.

The candidate's reaction was the interesting part. They spent the second half of the call asking about the product instead of answering questions about themselves.

2026-09-11

What "real time" actually means on a phone call

Everyone says real time. Here's ours, specifically.

Worst case, 15 seconds from the candidate saying something to the recruiter seeing a prompt about it. Usually a lot less. That's the budget we design against, because a phone conversation moves on. A suggestion that shows up after the topic has changed isn't help, it's noise.

So the work isn't the model. The model is fine. The work is transcription that keeps up, context that's already loaded before the call starts, and a pipeline short enough that the advice lands while the question is still open.

The candidate's file gets digested before the phone rings. That's how you buy back the seconds.

2026-09-11

The bias question

Something came up today that I want to think out loud about.

If the recruiter is getting guidance from a system that read the candidate's file, how much of that file does the recruiter actually need to see?

We could go pretty far. Hide the name. Hide the city. Hide the school. Score the answers on the phone, not the resume. How far you go would be up to the firm and what they've promised their clients.

We haven't built that yet. But the phone-first design makes it possible in a way a resume-first tool never could, and I think it's worth writing up properly.

If you run a staffing firm and you've been asked about bias in your process, I'd like to hear what your clients are actually asking for. jevans@ashfordbriggs.com