How to write an AI role brief that gets you the right people
6 minute read. Updated 2026-08-08.
A good AI brief describes a decision you can't make yet, not a list of tools. State the symptom, the data you actually have, and what changes once the role is filled. Put a budget band in the brief itself, anchored to published market rates, because leaving it out doesn't protect you. It just means you spend weeks interviewing people who were never going to take the job at the number you had in mind.
The brief that fails
Most AI role briefs read like a shopping list. Python, PyTorch, LangChain, vector databases, 5 years' experience. None of that tells a specialist what you need built. It tells them what to put on a CV to get shortlisted, which is a different thing entirely.
A technology list pulls in 2 kinds of applicant, and neither is who you want. One claims every tool on the list because the list is the test being marked. The other genuinely knows the tools named but has no idea whether your problem needs a data scientist, a data engineer, or someone who has never opened a notebook and works entirely in strategy decks.
Neither failure is the applicant's fault. A brief written as a tools list has told them exactly what to optimise for, and they have optimised for it.
Describe the symptom, not the stack
Write down what is broken. What decision is stuck. What you tried already, and where it stopped working. 'Our support team spends 4 hours a day reading tickets to find refund requests' is a brief. 'Need someone with LLM experience' is not.
Say what data actually exists, in what state, and who owns it. A specialist can work out which tools fit your problem once they understand the problem. They cannot work out your problem from a list of tools, however current.
This is also where you find out fast whether the role is real. If you struggle to describe the symptom in plain language, that's worth knowing before you hire, not after.
Say what changes once the role is filled
State the decision this hire makes possible. Ship the pilot or kill it. Build in-house or buy from a vendor. Keep a model running or replace it with a simple rule that does the same job for less. If the honest answer is 'we don't know yet', write that down.
That single sentence does more filtering than every technical requirement put together, because it tells a specialist what success looks like before they've spent a day on the work. It also tells them what kind of person they need to be: someone comfortable resolving ambiguity, not someone expecting a fully specified ticket.
State the budget
Many briefs leave the number out, on the theory that withholding it protects your position in a negotiation. It does the opposite. A brief with no budget reads as one that hasn't been thought through, and the specialists who would do good work at your real number don't bother replying to it.
Anchor your number to the published market. Advertised UK contract rates over the 6 months to August 2026 put the median for a Machine Learning Engineer at £575 a day, a Data Engineer at £500, a Data Scientist at £600, and Generative AI work at £550. Permanent salaries show the same spread: Machine Learning Engineer £76,000 median, Data Engineer £70,000. Start from the row closest to your problem, adjust for seniority and region, and publish a band rather than a single figure.
If your budget sits below the median for the role you actually need, say so, and say what you're trading off: fewer days, a more junior hire, a longer timeline. That's a fairer trade than hiding the number and hoping nobody notices until the interview is half over.
What a working brief looks like
A brief that does its job runs to a page. The problem, in a paragraph. The current state of the data and any tooling already in place. The decision the hire needs to make possible. The constraint: budget band, IR35 status, timeline. Nothing about frameworks unless the framework is itself a constraint, such as a model having to run inside an MLOps pipeline you already operate.
Anything longer than a page tends to drift back into a technology list, because it's easier to write down what you've heard of than to work out what you actually need.
The signal this creates at interview
A brief written this way becomes your first filter, before a single interview happens. Candidates who ask about the data and the decision it feeds are worth shortlisting. Candidates who ask which version of a framework you're running are answering a question you never needed answered.
What to do about it
- Describe the problem and the decision it depends on, not the technology stack.
- State a day rate or salary band in the brief itself, anchored to published market figures.
- If your budget sits below the market median for the role, say so, and say what's traded off.
- Include what data exists and who owns it, in plain language.
- Keep the brief to a page; length beyond that usually means the problem hasn't been thought through.
- Treat sharp questions about the data and the decision as the strongest signal in interview.
Questions people also ask
Should I list required tools and frameworks in the brief at all?
Mention them only where the tool itself is a constraint, for example if the model has to run inside an existing MLOps pipeline. Otherwise leave tools out entirely. A specialist works out which tools fit once they understand the problem, and naming a tool in the brief signals you've already decided the solution before understanding what's broken. That ordering rarely produces the system you actually need, and it filters for tool-namers rather than problem-solvers.
What if I genuinely don't know what budget to set?
Start from the published median for the closest role name in the market figures, for example a Machine Learning Engineer at £575 a day contract or £76,000 permanent, and adjust for seniority and region. An anchored starting figure beats no number at all, and it stops you wasting weeks on applications from people who were never going to accept whatever you had privately budgeted.
Won't stating the budget just mean everyone bids at the top of it?
Some will, and that's fine. A brief with no number attracts a far wider and messier spread of applications, most of which you'll reject anyway, which costs more of your time than negotiating down from a stated ceiling. A published band also tells good specialists you've thought the role through, which is itself a filter in your favour.
How long should a brief actually be?
A page. Cover the problem in a paragraph, the current state of the data and tooling, the decision the hire needs to make possible, the constraint such as budget band, IR35 status and timeline. Anything longer tends to drift back into a list of technologies, because it's easier to write down what you've heard of than to work out precisely what the role needs to achieve.
Where the figures come from
Every rate and salary quoted in this article is a median or percentile of figures advertised in UK job postings over the six months to 8 August 2026. They are not rates paid, and the gap widens at the top of a range.
- IT Jobs Watch, UK contract rates, 6 months to 8 August 2026, read 2026-08-08.
- IT Jobs Watch, UK permanent salaries, 6 months to 8 August 2026, read 2026-08-08.