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.

Overview

Architecture for putting a model in front of Worklittle: where the tool boundary belongs, which state the agent owns, and how to keep a chatty loop from becoming expensive or wrong.

The hard part of an agent on this API is not tool calling. It is deciding what the model is allowed to decide.

The shape that works

Start with Agent Quickstart if you still need skills, a key, or to decide Jobs vs Business from the user's goal. Most durable Worklittle agents look the same underneath.

1. A narrow tool surface. Expose the four or five tools the task actually needs, not the full catalog. A job search copilot needs search_jobs, get_job_details, get_job_keywords, and a document tool. Handing it employee management is how you get a surprise. 2. Deterministic guards around metered actions. Applying, unlocking a contact, and sending email cost money or are irreversible. Put those behind an explicit confirmation or a server-side policy check rather than trusting a prompt. 3. IDs held in application state, never re-derived. The model should quote a job_id it received, not reconstruct one. See Multi-turn agents. 4. Grounding rules that are enforced, not requested. If a field is absent from the API response, the answer is "not listed", not a plausible guess. See Grounding. 5. A budget. Searching on every turn burns monthly free quota and can trigger AI spend. See Retries and spend.

Where to draw the tool boundary

| Action | Model decides | Your code decides |
| --- | --- | --- |
| Which filters to search with | Yes | Cap the `limit` |
| Which results to show a user | Yes | Nothing to enforce |
| Whether to fetch details | Yes | Cap how many per turn |
| Whether to generate a resume | Yes | Nothing to enforce |
| Whether to submit an application | No, propose only | Confirm, then submit |
| Whether to move a candidate stage | Yes, with a tool call | Verify the write succeeded |
| Whether to send email | No, propose only | Confirm, then send |

The rule of thumb: a model may freely choose reads that are cheap and reversible. Anything that spends money, contacts a human, or changes another party's record should be proposed by the model and committed by your code.

Reads, writes, and irreversibility

Worklittle actions fall into three tiers, and your agent should treat them differently.

Cheap reads. GET /jobs/stats, list_applied_jobs, list_candidates, board GETs. Let the model call these freely. Retry them on failure.

Metered reads. Document generation and first-time AI job-description enrichment after the free daily allowance. Let the model call these, but budget them per turn and cache aggressively within a conversation. Retrying is safe but not free.

Side-effecting writes. Apply, Apply with AI start, send_email, candidate updates, document shares. These change the world. Retrying blindly can double-submit an application. Gate them, log them, and make retries idempotent at your layer.

A useful test: if the same call twice in a row would embarrass you in front of a candidate, it belongs in the third tier.

What lives in each section

| Page | Answers |
| --- | --- |
| [REST vs MCP](/use-cases/rest-vs-mcp) | Which transport to use for which surface |
| [Tool chains](/use-cases/tool-chains) | The exact call sequences that work |
| [Structured extraction](/use-cases/structured-extraction) | Keywords and detail fields versus raw description text |
| [Pagination and limits](/use-cases/pagination-and-limits) | Cursors, the 50 cap, and why big limits backfire |
| [Multi-turn agents](/use-cases/multi-turn-agents) | Holding ids across turns without inventing them |

Related docs

Worklittle MCP for the tool catalog and install. Libraries for the SDK and CLI. Prompting for the instruction language. Reliability for the pre-launch pass.