A recruiter searches for a skill and gets an untidy mix of labels. One candidate has a broad engineering tag. Another has a shortened spelling. A third has an AI-generated label that nobody defined. The search looks complete, but the team cannot explain which people it missed. Before adding AI to Ashby tagging, agree what the tags mean and who can approve them. More labels do not fix an unclear vocabulary.
Separate Ashby's tagging features from custom automation
Ashby supports candidate tags. Its product guide describes creating tags in Admin and applying them on a candidate profile. Tags can filter candidate searches, job pipelines and reports. The same guide says automatic application is not currently available and that tags need to be added manually. That matters when an operator expects a native rule to read a resume and label the candidate.
The developer documentation separately describes candidate.addTag. It adds a tag to a candidate and requires candidatesWrite permission. An external integration can use that endpoint, but this is a different implementation path from a built-in automatic rule. Confirm the current product behavior and API access for your organization. The reviewed AI workflow below is an engineering design, not a claim that Ashby supplies these approval controls.
Build a small tag dictionary first
Start with the search questions recruiters actually ask. Write a definition for every proposed tag, the evidence that supports it and the cases that should remain untagged. A programming language mentioned in an old course is different from recent work building a production service. If both should qualify, say so. If they should not, make the distinction explicit.
| Dictionary entry | Decision to record | Review check |
|---|---|---|
| Tag title | One approved spelling | No duplicate abbreviations |
| Definition | What the label actually means | Two recruiters interpret it alike |
| Evidence rule | What source text supports application | Reviewer can locate the text |
| Exclusions | When not to apply the label | Ambiguous examples remain unresolved |
| Owner | Who approves changes | Corrections have a named destination |
Keep temporary workflow states out of a permanent skill vocabulary. A label meaning that somebody needs a follow-up should not look like a verified capability. Ashby's guide points to Projects for dedicated talent pools and warns that too many tags create profile clutter. Decide whether a proposed label belongs in the dictionary before creating it.
Create and apply tags through the documented interface
To create a tag in Admin, open Organization Settings, then Candidate Tags, and choose New. Add a title and create it. To create a tag directly on a profile, first enable inline tag creation in the Candidate Tags Settings tab. The profile flow then lets a user type a new title and create the tag while applying it.
For an existing tag, open the candidate profile, select Add tags, search and choose the label. Ashby says users who can edit candidate profiles can add tags. As an operating policy, assign dictionary changes to a small set of owners even if more users can apply approved labels. Review existing spellings before adding another version of the same concept.
Keep AI suggestions outside the approved tag set
Give the model the approved dictionary and only the candidate information needed for the task. Ask for a proposed tag, the specific supporting passage and an explanation of any uncertainty. An absent fact should stay absent. A job title alone should not become proof of every skill usually associated with that title.
Store proposals in a separate review queue in your implementation. Show the candidate reference, proposed label, evidence location and dictionary version together. Do not write a speculative tag to the profile just to make it visible to a reviewer. A recruiter who uses tag filters could otherwise treat an unreviewed suggestion as an established fact.
Use IDs and a narrow write boundary
The candidate.addTag request requires candidateId and tagId. Save the approved pair in the review record rather than resolving a display name again when the job runs. Names can look alike. A reviewer should be able to inspect the intended profile before approving the association.
Place a server-side check between approval and the API call. The check should verify that the candidate is still in scope, the tag remains allowed and the approval matches the current proposal. Keep credentials out of model text and browser output. Our guide to Ashby API permissions covers the access review separately. Permission to write candidates is not a substitute for your application's own allowed-action check.
Record the request outcome against the approval. If a connection fails after submission, treat the result as uncertain until checked. Do not describe a queued request as an applied tag. Define a bounded recovery process that lets an operator inspect the profile and resolve the uncertain entry before trying again.
Test the search experience, not only the API response
Choose candidate examples with clear evidence, weak evidence and no evidence. Include profiles where an old role conflicts with a current one. Have recruiters review suggestions before enabling any write path. Record false labels and missed labels separately, then revise the dictionary or evidence rule instead of merely changing the model prompt.
- Verify the approved tag appears on the intended candidate.
- Open Candidates, then Search, and add a Tags filter.
- Check that the returned people match the dictionary definition.
- Open a job pipeline and test the same tag filter there.
- Correct a label and confirm the affected searches reflect that correction.
The filter button may read Filter or Add Field to Match depending on the Advanced setting. Have an operator perform the check through the interface they use daily. A successful write alone cannot show that the resulting search is useful.
Common mistakes and operating ownership
Avoid creating a new tag for every phrase the model returns. Avoid silently turning missing evidence into a negative label. Do not use organizational tags as an automatic rejection instruction or as permission to contact a candidate. Keep outreach and hiring decisions under their own review rules.
Assign someone to review corrections, dictionary changes and unresolved writes. Revisit evidence when the underlying profile changes. Record what the AI proposed and what the recruiter accepted so disagreements can be traced. For broader workflow planning, the recruiting work map helps separate search preparation from decisions that still need an operator.
How Remqa helps with recruiting tagging workflows
Remqa builds AI agents for recruiting teams, including reviewed handoffs between candidate research and ATS updates. We can help define the tag dictionary, implement the review queue and connect approved actions to the write path. Start with one search problem and the candidate examples your team finds hardest. Explore AI recruiting agents or walk an engineer through your current tagging process.