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.

Tool chains

The call sequences that actually work, in order, for job discovery, document tailoring, apply, and ATS pipeline updates. Copy these before inventing your own.

Most agent failures on this API are ordering failures. The model has the right tools and calls them in the wrong sequence with the wrong inputs.

Chain 1: search to tailored document

The canonical candidate-side flow.

search_jobs(query, filters, limit ≤ 20)
  > pick 1 to 3 results with the user or a ranking step
  > get_job_details(job_id)          # full requirements, salary hints
  > get_job_keywords(job_id)         # distilled skills, no prose
  > create_resume({ job_id, resume_text, job_context: keywords })
  > create_cover_letter({ job_id, ... })

Why this order matters:

Details come after ranking, so you pay for enrichment only on shortlisted roles. Keywords come after details because the user may reject the role once they read it. Keywords, not the full description, feed document generation. Passing the whole posting measurably degrades output. job_id is threaded through every step so the document is tied to a real posting.

Chain 2: search to submitted application

search_jobs(...)
  > inspect can_apply on the chosen row
  ├─ Worklittle-hosted job
  │    get_job_details(job_id)        # read application_fields
  │    create_resume(...)             # optional, for resume_file
  │    confirm with the user
  │    submit_job_application({ job_id, name, email, answers, resume_file })
  └─ eligible external job
       apply_for_job({ job_id })
       get_apply_status(session_id)  # poll until completed

The confirmation step is not optional in practice. Both branches spend money and both put a candidate's name in front of an employer. Reference: Apply with AI.

Chain 3: ATS pipeline update

The employer-side equivalent, where the risk is writing to the wrong record rather than spending money.

list_candidates({ posted_job_id, stage_key, limit })
  > get_candidate_profile(candidate_id)      # confirm identity before writing
  > update_candidates({ candidate_job_id, stage_key: "phone_screen" })
  > create_candidate_notes({ candidate_id, body })
  > create_candidate_interview({ candidate_id, ... })   # if scheduling

Two details that bite:

Stage lives on the candidate-job pair, so candidate_job_id is required, not candidate_id. A person in two pipelines has two stages. Read the profile before writing when the agent resolved the person from a name. Two candidates named Alex is not a rare event.

Reference: ATS automation.

Chain 4: market question

get_market_overview()                 # free, no parameters
  > answer counts, remote share, top hiring companies directly
  > only if the user then asks to see roles: search_jobs(...)

For compensation:

GET /jobs/salary-average?title=...&country=US
  > report average alongside jobs_in_average

Never satisfy an aggregate question by paginating search. It is slower, it burns quota, and the count you produce is capped by how many pages you were willing to pull.

Chain 5: careers site request cycle

GET /business/jobs/company/:company/board?include=facets     # list page, ETag cached
  > GET /business/jobs/company/:company/jobs/:slug           # detail, gives application_fields + features
  > POST .../parse-resume                          # only if features.resume_autofill
  > POST .../jobs/:slug/apply
  > webhook job.published | job.updated | job.closed > revalidate cached pages

No API key anywhere in that chain. Reference: Embedded job board.

Anti-patterns

| Anti-pattern | Why it hurts |
| --- | --- |
| Detail fetch on every search result | Multiplies cost with no user benefit |
| Full description into a resume prompt | Dilutes signal and lowers output quality |
| Apply before reading `application_fields` | Required custom questions fail validation |
| Stage update keyed by `candidate_id` alone | Ambiguous when a person is in two pipelines |
| Re-searching to recover a `job_id` from earlier | Keep it in state. See [Multi-turn agents](/use-cases/multi-turn-agents) |
| Paginating to count | Use `GET /jobs/stats` |