How to write a hiring brief an AI agent can act on

What is a hiring brief?

A hiring brief is a short, plain-language description of who you want to hire and how you will recognize them, written before anyone starts searching.

It is different from a job description, which describes the job to candidates, and a job post, which advertises it. The brief is for the people and tools doing the search. It usually comes out of an intake meeting between the recruiter and the hiring manager, and it should be specific enough that two recruiters reading it would bring back similar shortlists.

An AI agent raises the stakes. A colleague can ask what you meant by "strong". An agent turns your words into criteria and ranks people against them, so every vague word becomes a vague criterion, or no criterion at all.

What should a brief include?

Seven things: the role and level, a few must-haves, some nice-to-haves, the evidence you would accept for each, the location and work pattern, the pay range, and the deal-breakers.

Write the pay range down even if the agent can't use it. You will need it in the first message and the first call, and some places require it in job postings. In California, for example, employers with 15 or more employees must include the pay scale in any job posting.

How do you separate must-haves from nice-to-haves?

A must-have is something you would turn down an otherwise excellent candidate for lacking. Everything else is a nice-to-have.

The test is simple. Picture the best person you could hire for this role, then take the requirement away. Would you still hire them? If yes, it is a nice-to-have. Aim for two to four must-haves. Each extra one shrinks the pool, and requirements that sound essential in a meeting, such as a specific framework or industry, often turn out to be preferences.

Must-haves should also be checkable. "Excellent communicator" can't be checked from a profile. "Has written design documents that other teams used" can be checked in a screen.

What evidence would you accept for each requirement?

For every requirement, write down what you would see in a profile or hear in a screen that proves it, because most requirements can be shown in more than one way.

"Five years of Python" might mean five years of job titles that mention Python, or open-source work, or a long career in which Python was one tool among several. Decide in advance what counts. For example:

• Owned a production service: a role where they ran a service, were on call for it, or led its incident reviews.
• Go: production Go in a recent role, or public Go projects that other people use.
• Worked closely with sales: built tools for a sales team, or sold before moving into engineering.

Two kinds of evidence are worth separating. What a profile can show helps with sourcing. What only a conversation can show belongs in the screen. Structured interviewing starts from the same place, by basing questions on an analysis of what the job requires (Campion, Palmer & Campion, 1997).

Avoid proxies. School names, famous employers and years in a role stand in for skills without measuring them, and they narrow the pool in ways that have little to do with the work.

What does a weak brief look like next to a strong one?

A weak brief describes a kind of person. A strong brief describes the work and how you will recognize someone who can do it.

We need a rockstar senior engineer who can hit the ground running. Ideally ex-big tech, top school, culture fit. Competitive pay. Remote-ish.

Senior backend engineer for our payments team. Berlin, with two office days a week, or remote within Europe. Must have: 6+ years building backend services; production Go or Rust; has been on call for a service they helped build. Nice to have: Kafka or another event streaming system; payments or marketplace background. Evidence we'd accept: a role where they owned a service in production; public Go or Rust work counts. Level: senior individual contributor, no direct reports. Pay: €95,000 to €115,000 base. Deal-breaker: can't join the on-call rotation.

When we ran both briefs through Emoti's built-in rules, the weak one produced a single criterion: "Open to remote". "Rockstar", "hit the ground running" and "culture fit" can't be checked, "senior engineer" doesn't say what kind of engineer, and "competitive pay" says nothing at all. The strong brief produced seven criteria:

Two things in that list need a person's attention. Go and Rust came in as nice-to-haves even though the brief calls them must-haves, because skills start as nice-to-haves by default. And "Go or Rust" became two separate criteria, because Emoti can't yet express "either one". Marking both as must-haves would require both. The fix is to leave them as nice-to-haves and read the evidence, or to pick the one that matters more.

How does Emoti read a brief into criteria?

Emoti turns the brief into a short list of criteria, marks each as a must-have or a nice-to-have, and shows them as chips you can change before you trust the ranking.

Criteria cover the role, location, years of experience, skills, industry and a few signals, such as having led a team. The role, a stated location and the minimum years start as must-haves; skills and industry start as nice-to-haves; and a brief that allows remote work makes location a nice-to-have. When a language model is configured, it reads the brief. Otherwise Emoti's built-in rules do, and the page says which one did.

Every candidate then gets a fit strip: one mark per criterion, showing met, partly met, missing or not enough information, with the line of profile evidence behind each mark. Missing a must-have doesn't hide anyone. It caps their score at 54 out of 100, which keeps them out of the strong and good bands, and the strip shows which must-have they miss. A coverage panel shows how many people in the pool meet each criterion and warns when a must-have is so rare that it is shrinking the search.

Some parts of a brief aren't read by the matcher in version 1.0: the pay range, the deal-breakers and your evidence notes. They are for the people reviewing the shortlist and for the questions in the first screen. The full method, including its limits, is in Evidence-first candidate matching.

Which mistakes make a brief hard to act on?

Most weak briefs fail in one of a few ways:

• Too many must-haves. A list of eight must-haves is often three must-haves and five preferences.
• Adjectives without a test. "Strong", "excellent" and "senior-minded" each need a sentence about what you would actually see.
• Proxies for skill. Schools, famous employers and years of experience stand in for the thing you want.
• Hidden deal-breakers. A relocation or travel requirement that appears at the offer stage wastes everyone's time.
• Two roles in one. "Backend engineer who can also lead design" is usually two searches.
• A pasted job description. It is written to attract applicants, not to rank them, and it mixes requirements with marketing.
• Words that describe a kind of person. Phrases such as "young and hungry" or "digital native" describe who someone is, not what they can do. Leave them out.