> ## Documentation Index > Fetch the complete documentation index at: https://docs.burn0.dev/llms.txt > Use this file to discover all available pages before exploring further. # Tasks > Objectives, stated without a solution path A task is the job you hand an agent. One JSON file per task in `tasks/`, discovered automatically — adding a task is adding a file. ```json tasks/TASK-001.json theme={null} { "id": "TASK-001", "title": "Convert a qualified maritime lead", "instruction": "Ingrid Halvorsen at Fjord Maritime Group has been qualified and is ready to become a real opportunity. Fjord Maritime is not yet a customer of ours. Convert her, opening a deal worth $140,000 that we expect to close on 2026-06-30. Daniel Reyes (USR-002) owns the lead and is doing the work.", "difficulty": "easy", "verifierId": "VER-001", "entities": ["LEAD-004"] } ``` | Field | Required | Meaning | | ------------- | -------- | -------------------------------------------------------------------- | | `id` | yes | `TASK-0NN`. Used on the command line and by the verifier. | | `title` | yes | Short label for listings. | | `instruction` | yes | What the agent is told. This is the only text it receives. | | `verifierId` | yes | Which verifier grades it. | | `difficulty` | no | `easy`, `medium` or `hard`. Metadata for your own reporting. | | `entities` | no | Ids the task concerns. Useful for filtering; not shown to the agent. | ## The instruction is the whole prompt The agent receives `instruction` as a plain string and nothing else — no tool list, no hints, no schema. Everything it needs to identify what to act on must be in that text, phrased as a person would phrase it. **State the objective, never the path.** ``` Tomas Bergstrom has left the company and his account is deactivated, but his open deals are still sitting under his name. Move every one of his open opportunities to Priya Nair (USR-003), who is picking up his territory. Deals he already closed stay as they are. ``` That says what "done" means. It does not say to call `list_opportunities` first, or that there are exactly two deals, or which tool reassigns them. Finding that out is the work being measured. An instruction that names the tools tests whether a model can follow directions. An instruction that states an outcome tests whether it can do the job. Never put the answer in the instruction. An answer-producing task should describe what is wanted — "the probability-weighted value of everything currently open" — and leave the figure to be computed. A task carrying its own answer grades reading comprehension. ## Give it enough to be solvable Being vague is not the same as being hard. The instruction must contain everything a competent person would need: * **Names and ids.** `Daniel Reyes (USR-002)` — because the verifier will check the deal ended up with that user. * **Parameters that are decisions, not deductions.** The \$140,000 amount and the close date are inputs from the business; the agent cannot derive them. * **Boundaries.** "Deals he already closed stay as they are" is what makes a wrong-but-plausible action wrong. The test is whether a new employee could do it with access to the same tools. If they would have to guess, the task is broken, not hard. ## Two shapes of task **State-changing** — the agent must leave the world different. Graded against `finalState`. > Lumen Retail has signed for the point-of-sale refresh, but at \$118,000 rather than the figure we last quoted. Record the win at the contracted number. **Answer-producing** — the agent must report something, and correct behaviour may change nothing at all. Graded against its output. > Amara Osei needs a single number for the board: the probability-weighted value of everything currently open across the whole team. Both are first-class. The second matters because a convincing wrong answer is a common agent failure, and it is invisible if you only inspect state. ## Ambiguity breaks grading A verifier has to know the right answer. If the seed data allows two, the task cannot be graded and a correct agent can fail. CRM's `TASK-005` asks which rep has the most stalled deals. The data is arranged so exactly one rep has two and nobody else has more than one. The verifier even records this as an optional check: ```typescript theme={null} optional( "The seeded world has a single clear leader", unambiguous, `top = ${top?.[1] ?? 0}, runner-up = ${runnerUp?.[1] ?? 0}`, ), ``` If someone later edits the data into a tie, that check fails and says so, instead of the task quietly becoming ungradeable. ## Difficulty is yours `difficulty` is metadata — Silo does not read it. It is there so you can report on how an agent does across a range. The convention in the built-in templates: | | | | -------- | ------------------------------------------------------------------ | | `easy` | One or two tool calls, no branching | | `medium` | Multi-step, requires finding the affected records first | | `hard` | Requires interpreting a qualifier, or reasoning across collections | CRM's `TASK-006` is `hard` because it says *active* reps — an agent that skips that word lands on the deactivated rep, who has the worst attainment of all. ## Managing tasks ```bash theme={null} npx @burn0/silo task list --env demo ``` ``` TASK-001 easy VER-001 Convert a qualified maritime lead TASK-002 medium VER-002 Rehome a departed rep's open pipeline TASK-003 medium VER-003 Book the Lumen point-of-sale win TASK-004 easy VER-004 Report the weighted value of open pipeline TASK-005 medium VER-005 Identify the rep with the most stalled deals TASK-006 hard VER-006 Find the weakest active rep against quota ``` ```bash theme={null} npx @burn0/silo task add --env demo --id TASK-007 \ --title "Escalate the overdue Anchor invoice" \ --instruction "..." \ --verifier VER-007 \ --difficulty medium ``` `task show`, `task update` and `task remove` round out the set, and `--json` works on all of them. A task and its verifier are one-to-one: `env validate` reports an error if two verifiers claim the same task.