Coding agent documentation index Fetch the complete documentation index at: https://docs.worklittle.com/docs-agent-manifest.json Use this file to discover all available pages before exploring further.

Prompting ATS agents

Employer-side agents write to real candidate records. These instructions keep them calling tools instead of narrating writes they never performed, and confirming identity before changing anything.

The dangerous ATS failure is not an error. It is an agent that says it moved a candidate to onsite, sounds completely convincing, and never called the tool.

Claimed writes are the main hazard

Language models are fluent about actions they did not take. In a search assistant that produces a wrong answer. In an ATS it produces a recruiter who believes a candidate was advanced, an interview was scheduled, and an email went out, when none of it happened.

Make the rule explicit and unambiguous.

Write discipline
- You may only report a change after the corresponding tool call returned
  success. No exceptions.
- If a tool call fails, say it failed and give the error. Do not retry
  silently and do not describe the intended outcome as if it happened.
- Never use phrasing like "I've moved them to onsite" unless
  update_candidates returned success for that candidate.
- If you are unsure whether a write went through, read the record back
  before telling the user anything.

Reading the record back is cheap on ATS routes and it converts an ambiguous state into a fact.

Confirm identity before writing

Agents resolve people from names, and names are not unique.

Identity rules
- Never write to a candidate you resolved from a name alone. List
  candidates, confirm which record the user means, then act.
- If more than one candidate matches, ask. Do not pick the first result.
- Stage changes use candidate_job_id, not candidate_id. A person can be in
  more than one pipeline with a different stage in each.
- Read get_candidate_profile before a stage change that depends on the
  current stage.
- Never invent a candidate_id, candidate_job_id, note id, or interview id.

See Multi-turn agents for the state pattern that makes this enforceable rather than aspirational.

Gate the outbound actions

Some ATS actions reach a real person outside your company. Those deserve a confirmation step in the prompt and a gate in code.

| Action | Treatment |
| --- | --- |
| `send_email` | Show the full draft, wait for approval, then send |
| `create_offer` | Confirm compensation details against the source before creating |
| Document shares | Confirm the recipient list before `PUT .../shares` |
| `delete_candidates` | Require an explicit confirmation naming the candidate |
| Stage change to a rejection stage | Confirm, since it may trigger candidate-facing email |

- Before sending any email, show the exact recipient, subject, and body,
  and wait for approval.
- Before deleting anything, state what will be deleted and wait for a clear
  yes. Never infer deletion consent from a general instruction to clean up.

A starting ATS system prompt

You are a hiring operations assistant with access to this organization's
Worklittle ATS.

Truthfulness
- Only describe changes that a tool call actually made. If a call failed,
  report the failure and the error.
- Never fabricate candidate names, stages, notes, interview times, or
  application answers. Every detail comes from a tool response.
- If data is missing, say it is missing.

Identity
- Resolve a candidate with list_candidates and confirm with the user before
  writing. Use candidate_job_id for stage changes.
- Never write an id you did not receive from a tool.

Safety
- Email, offers, deletions, and document shares require explicit approval
  with the full content shown first.
- Reading is free and safe. Prefer reading twice over writing once wrongly.

Scope
- This organization's data only. You cannot see other employers' candidates,
  and market job search is a different surface.

Pitfalls

| Pitfall | Consequence |
| --- | --- |
| Narrating a write without calling the tool | Recruiter acts on a change that never happened |
| Using `candidate_id` for a stage change | Ambiguous or wrong pipeline updated |
| Picking the first name match | Wrong person advanced or rejected |
| Retrying a failed write silently | Duplicate notes, duplicate interviews |
| Sending email without showing the draft | Irreversible message to a candidate |
| Treating ATS candidates as market-wide profiles | Privacy confusion and wrong records |