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.

Multi-turn agents

Keep job_id, candidate_id, and session_id in application state across turns. A model that reconstructs an identifier from memory will eventually act on the wrong record.

Identifiers are the one thing a language model must never generate. Every id in a request should be traceable to an API response your code stored.

Why invented ids are the core risk

Identifiers look like exactly the kind of token a model is good at producing. They are short, structured, and appear frequently in context. That is precisely the problem: a model will happily emit something that has the right shape and refers to nothing, or worse, to a different real record.

The failure modes are not symmetric. An invented job_id on a detail fetch gives you a clean 404, which is annoying but safe. An invented or stale candidate_job_id on a stage update writes to the wrong person's pipeline and nothing in the response tells you it was wrong. Same for a session_id on an apply approval.

The mitigation is architectural rather than prompt-based. Ids live in your application state and your tool layer resolves them. The model refers to items by position or by name, and your code translates.

What to persist per conversation

| Key | Set when | Used by |
| --- | --- | --- |
| `job_id` | A search result is shown or selected | Detail, keywords, documents, apply, tracking |
| `search_filters` | A search runs | Pagination, refinement, re-running without re-deriving |
| `next_cursor` | A search returns | The next page, if the user asks |
| `candidate_id`, `candidate_job_id` | A candidate is listed or opened | Stage updates, notes, interviews |
| `session_id` | Apply with AI starts | Polling, continue, approve, stop |
| `document ids or blobs` | A resume or cover letter is generated | Attaching to an apply |

Store these keyed by conversation, with the last search result set alongside them so "the second one" resolves deterministically.

Resolve by reference, not by recall

A pattern that works well: give the model a compact, numbered view of what is in state, and let it refer to entries by index.

{
  "results": [
    { "ref": 1, "title": "Senior Product Designer", "company": "Example Co" },
    { "ref": 2, "title": "Product Designer", "company": "Acme" }
  ]
}

The model then calls your tool with { "ref": 2 } and your code substitutes the real job_id before hitting the API. The model never sees an id it could mangle, and an out-of-range ref is an obvious validation error rather than a silent misfire.

If you do expose raw ids, validate them at the tool boundary: confirm the id appears in the current conversation's stored result set, and reject it otherwise with a message telling the model to search first.

Handling staleness

State goes stale in ways that matter.

A job closes mid-conversation. closed_at becomes non-null and apply starts failing. Re-check on the detail fetch before an apply rather than trusting a search result from ten turns ago. A candidate moves. Another recruiter changed the stage in the UI while your agent was talking. Read the profile before writing when the write depends on the current stage. A cursor ages. Do not stash a cursor for a later session. Re-run the search. An apply session ends. Poll until a terminal status, then clear session_id so a later turn cannot approve a finished run.

Treat stored ids as a cache of a remote system, because that is what they are.

Pitfalls

| Pitfall | What to do instead |
| --- | --- |
| Letting the model emit ids from memory | Resolve refs to ids in your tool layer |
| Re-searching to recover an id you already had | Read it from conversation state |
| Reusing a `job_id` across users | Ids are global, but the user context around them is not |
| Approving a submit with a stale `session_id` | Clear session state at terminal status |
| Staging a candidate without re-reading the profile | Confirm identity and current stage first |
| Re-unlocking a contact you already paid for | Cache the unlocked value |