Examples

Two small environments ship inside the package, in examples/. They exist to show the two shapes of task as plainly as possible — each is small enough to read in a couple of minutes. They are not templates. Copy one into .silo/environments/ to run it:

cp -R node_modules/@burn0/silo/examples/customer .silo/environments/customer
npx @burn0/silo run --env customer --task TASK-001 --agent ./customer.agent.ts

Customer — a state-changing task

The smallest useful environment: one collection, one tool, one task.

state.ts

export type CustomerStatus = "active" | "blocked";

export type Customer = {
  id: string;
  name: string;
  status: CustomerStatus;
  statusReason: string | null;
};

export type State = {
  customers: Record<string, Customer>;
};

export const isBlocked = (customer: Customer): boolean => customer.status === "blocked";

The task asks the agent to block a customer. The verifier checks the world afterwards:

verifiers/VER-001.ts

check(
  "CUS-001 is blocked",
  customer?.status === "blocked",
  `status = ${customer?.status ?? "missing"}`,
),
optional(
  "A block reason was recorded",
  typeof customer?.statusReason === "string" && customer.statusReason.trim().length > 0,
  `statusReason = ${customer?.statusReason ?? "null"}`,
),
optional(
  "No customer was added or removed",
  Object.keys(final.customers).length === Object.keys(initial.customers).length,
  `${Object.keys(final.customers).length} customers`,
),

Worth noticing: the required check is the outcome, and the optional ones catch sloppy success — a block with no reason, or collateral damage to other records. That split is what lets a reward distinguish “right but careless” from “wrong”.

Profit — an answer-producing task

The mirror image. The agent is asked a question, and correct behaviour changes nothing at all.

tasks/TASK-001.json

{
  "id": "TASK-001",
  "title": "Report the total profit",
  "instruction": "What is the total profit across all recorded profit lines? Reply with the total amount as your final answer.",
  "difficulty": "easy",
  "verifierId": "VER-001"
}

verifiers/VER-001.ts

/** The agent's closing figure: the last number it wrote. */
function finalAnswer(output: string): number | null {
  const numbers = output.replace(/[$,]/g, "").match(/-?\d+(?:\.\d+)?/g);
  const last = numbers?.at(-1);

  return last === undefined ? null : Number(last);
}

check(
  "The reported total is correct",
  answered === totalProfit(initial),
  `answered ${answered ?? "nothing"}, expected ${expected}`,
),
optional(
  "Answering left the world unchanged",
  JSON.stringify(final) === JSON.stringify(initial),
  "state is untouched",
),

Two things to copy from this one: The expected total is derived. totalProfit(initial) is a domain helper in state.ts, not a constant. Edit the seed data and the verifier follows. “Answering left the world unchanged” is an optional check. For a question, touching state is not automatically wrong — but it is worth knowing about.

ERP, CRM and Blank

The three templates are also readable examples, at a much larger scale. CRM in particular is worth reading end to end: it is populated, it covers both task shapes, and it is small enough to hold in your head.

npx @burn0/silo init reading-copy --template crm

What to read, in what order

examples/customer — the whole contract in one collection and one tool.
examples/profit — the same contract with an answer-producing verifier.
CRM state.ts — domain helpers, and the derived-value distinction.
CRM verifiers/ — six verifiers, none hardcoding an answer.
ERP tools/ — what a large tool surface looks like when it stays organised.

Getting Started

Environments

Running Agents

Guides

Reference

Customer — a state-changing task

Profit — an answer-producing task

ERP, CRM and Blank

What to read, in what order

​Customer — a state-changing task

​Profit — an answer-producing task

​ERP, CRM and Blank

​What to read, in what order

Customer — a state-changing task

Profit — an answer-producing task

ERP, CRM and Blank

What to read, in what order