Tasks

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.

tasks/TASK-001.json

{
  "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:

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

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

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.

Getting Started

Environments

Running Agents

Guides

Reference

The instruction is the whole prompt

Give it enough to be solvable

Two shapes of task

Ambiguity breaks grading

Difficulty is yours

Managing tasks

​The instruction is the whole prompt

​Give it enough to be solvable

​Two shapes of task

​Ambiguity breaks grading

​Difficulty is yours

​Managing tasks

The instruction is the whole prompt

Give it enough to be solvable

Two shapes of task

Ambiguity breaks grading

Difficulty is yours

Managing tasks