Watch a recruiter use AI during a live search and you see the same movement over and over: open a chat, paste the job description, add a paragraph of context from memory, ask the question, get the answer, close the tab. Two hours later, for a different task on the same role, they do all of it again.
That repetition is not a discipline problem. Nothing in the workflow holds the role, so the recruiter holds it and re-enters it by hand, slightly differently each time. By week three of a search the version being pasted has drifted from what the client actually said in the last call.
A job description is not role context
Answer-first: a job description is a public document written to attract applicants. Role context is the recruiter's working understanding of what the client will actually hire, including the parts nobody wrote down.
The job description says "5+ years' experience with modern JavaScript frameworks". The role context says the last two hires failed because they had never worked without a platform team, the hiring manager cares far more about that than framework names, and the salary band has quietly moved twice.
| Job description | Role context | |
|---|---|---|
| Written for | Candidates and job boards | The recruiter running the search |
| Requirements | A flat list, often aspirational | Separated into must-haves and preferences |
| Reasoning | Rarely explains why | Records why each requirement exists |
| Unknowns | Hidden | Recorded as open questions |
| Lifespan | Fixed at publication | Updated as the search teaches you things |
What should a recruitment brief actually contain?
Five things, and the fifth is the one most briefs skip.
A recruiter-ready role
- Outcomes: what this person has to have delivered by month six for the hire to count as successful.
- Must-haves: the requirements a candidate cannot be progressed without, each with a reason.
- Preferences: genuinely nice to have, explicitly ranked below the must-haves.
- Client context: team shape, manager style, process, competing offers, how decisions get made.
- Open questions: what you do not know yet and need to ask, held visibly rather than forgotten.
Splitting must-haves from preferences sounds obvious and almost never survives contact with a client wish list. It is also the split that changes AI output most: a model given fourteen equally weighted requirements will treat a missing nice-to-have as seriously as a missing license.
Roles change during a search
Week one the client wants a specialist. Week three, after two rejections, they want someone broader. If the role only exists as a document from week one plus your memory of the last call, every AI task after that point is working from stale context, and so is anyone covering for you.
The role should be shared context, not something you paste into every prompt.
How to do this without new software
Keep one living role document per search. Five headings, matching the checklist above. Update it immediately after every client conversation, in the client's language, not a tidied version. When you start any AI task for that role, paste the relevant sections rather than the job description.
This works. It also decays, because maintaining a parallel document by hand competes with actual recruiting, and the two drift apart within a fortnight. That decay is the real reason recruiters go back to re-pasting.
How Creo Access implements this
Creo Access is built around the Role rather than around chats. Two capabilities do the work described above.
Creo Role Memory is the structured, recruiter-approved context for a search: outcomes, must-haves, preferences, client context and open questions, held on the Role itself. Everything downstream reads from it. When the search teaches you something, you update the Role, not seven separate chat threads.
How Role Memory builds up over a search
Select an entry to see what it changed and where it came from.
A Role holds the recruiter’s working understanding of the search, not just the advertised description. Every line keeps the source it came from.
Read this figure as text
- Source: Original brief from the client. Email from Halden Grove, 3 March, We need a senior backend engineer. Go-based, ideally payments. Two stage process, moving quickly.
- Approved: Intake decision by the recruiter. Outcome, Ship the new settlement service to production inside two quarters.
- Applied: Update from a client conversation. Client call, 11 March, 06:20, Honestly the payments background matters less than the ledger work. We can teach payments.
- Open question: Learned from candidate evidence. Pattern, Neither candidate could describe who owned the ledger after release.
- In use: Current Role Memory. Outcome, Ship the settlement service to production inside two quarters.
Creo Align is how the Role gets built in the first place. You give it what the client actually sent, however messy: an email, a call transcript, a two-line brief, a bloated job spec. It returns an editable Role Blueprint with proposed outcomes, requirements split into must-haves and preferences, and the questions it could not answer from the material. You correct it, and your corrections are what get saved.
From brief to shared role context
- Job descriptionWhat the client published
- Intake conversationWhat they actually said
- Recruiter notesWhat you learned in week two
The practical effect is unglamorous and worth a lot: you stop opening each AI task by explaining the role, and you stop discovering three weeks in that half your work was based on the version of the brief from day one.
Try it on a live search
Build the Role once and stop re-explaining it
Turn your next messy brief into a structured Role, then run the search from it. Start free for 14 days. Then choose monthly or annual billing. Cancel anytime.
Start 14-day free trial