Skip to main content
A template is a complete environment copied verbatim into your project. Once copied it is yours — Silo does not track it, update it, or own it.

​
Blank

The contract wired up and nothing in it.
Use it when you are modelling your own domain. It is the reference architecture — every other template has exactly this shape with contents filled in. Start with Build an Environment From Scratch.

​
CRM

A staged B2B sales pipeline. The best template to read, because it is populated but small enough to hold in your head. Collections — accounts, contacts, leads, opportunities, activities, users, pipeline stages, an audit log. The domain rule that makes it interesting: a deactivated user cannot act or own records. That single constraint turns “rehome the departed rep’s pipeline” from a formality into a task an agent can get wrong. Tasks — three that change the world, three that produce an answer: The last two are a deliberate pair. One includes the deactivated rep; the other says active and excludes him. An agent that skims the qualifier answers the second with the first’s answer. CRM is also where the derived-value rule shows itself: an opportunity’s weighted value is a helper, not a stored field, because the agent moves opportunities between stages mid-rollout.

​
ERP

A mid-sized industrial distributor, and by far the largest environment: procure-to-pay, order-to-cash, inventory, and budgeting, connected as they would be in a real system. 185 tools across 18 tasks. Reach for it when you want to test an agent against genuine breadth — where choosing the right tool out of 185 is itself the difficulty. It is the counterexample to CRM on derived values: ERP derives money totals at load, because every tool that changes a quantity also recomputes them. Both approaches are correct; which one applies depends on whether the agent can change the inputs. See State.

​
Choosing

​
Creating your own template

There is no separate template format. A template is an environment directory — the built-in ones live in the package’s templates/ folder and are copied verbatim. To reuse a world across projects:
  1. Build it in one project under .silo/environments/<name>/.
  2. Copy the directory wherever you want it kept.
  3. Copy it into the next project’s .silo/environments/.
The only file that references the template is the manifest, which records where it came from:
silo.environment.json
templateVersion records the Silo version that scaffolded it. Nothing migrates an environment when Silo updates — a copied environment keeps working because it is plain TypeScript against a stable contract.
Adding a template to the --template flag itself requires a change to Silo’s registry, so custom templates are copied by hand today rather than registered. If sharing templates matters to you, that is worth opening an issue about.

​
Things worth stealing

Whatever you build, these patterns from the built-in templates are worth copying:
  • tools/contract.ts — pin defineTool to your State once, and keep schema builders and input readers beside it so each tool file imports one thing.
  • tools/helpers.ts — lookups and shared rules (requireX, assertOpen) written once rather than per tool.
  • Split verifier files — verifiers/VER-001.ts plus a barrel, not one large file.
  • A shared.ts for answer parsing — reading a number out of free text in one place rather than per verifier.
  • An audit log — an append-only array shows up in state-diff.json, which makes “who did what” visible after a rollout.