Soot DocsThe practical guideMarkdown ↗

02 / Initialization

The INITIALIZATION session

Design a Soot you can explain and test. The goal is not a larger toolbox; it is a clear responsibility with a verifiable execution path.

01 · Agree a work contract

Write the outcome, authoritative sources, minimum read scopes, output format, acceptance and ask/stop criteria before choosing a Pack. “Help with marketing” is too broad; “three drafts from an approved brand-guide revision, no publication” can be checked.

Agent prompt
Before creating an agent, propose a mission for exactly one outcome.
List required sources and minimum read scopes.
State prohibited effects, acceptance criteria and stop conditions.
Reuse existing configuration if it already fits; do not duplicate blindly.
Do not expand grants or provision infrastructure before operator review.

02 · Choose the right workspace

General: soot spawn my-soot, then cd my-soot. Its preset already has permissions; inspect and narrow them. Blank: replace general spawn with --empty. File-only: add --no-start. Product: soot spawn --product my-product creates support with empty grants and scripted AI, without starting. Nest: soot nest is the operator workspace, not an agent or cloud service.

Source and durable state have separate roles. Only one runtime process opens a store. Never clone a running runtime against the same state to “try quickly,” or delete history/checkpoints/receipts to force model migration.

03 · Assign ownership correctly

ComponentThe question it answersOwner
SoulHow should it work consistently?Soot definition
MissionWhat job and boundaries?Soot definition
SkillWhich SOP/knowledge to read?Pack capability
ToolWhich operation can execute?Capability + host binding
Provider/vault/policyModels, secrets and limits?Runtime host
Conversation/run/stateObjective, execution and receipts?Durable runtime store

Packs do not own identity, schedules, routes or credentials. interface.tool_area is presentation for already-granted tools. Installation does not select capabilities or start ingress/backends. Host shell runs with host OS access; a workspace is not a sandbox.

04 · Validate → save → activate → verify

These are lifecycle concepts, not four creation-wizard buttons. Create through Soots → Tạo Soot → Vai trò → Chọn Pack → Xem lại: enter the name/mission, select minimum capabilities and review the scopes. Finish with Tạo Soot (or Lưu Soot when editing); the host checks the configuration before saving. Inspect the host-reported ID rather than inferring it from the display name.

Terminal · review before running
soot version --json
soot check --show --secrets

Check does not call a model. Separately, the Soot's Nâng cao (advanced) view exposes host-supported editable fields and actions: Kiểm tra validates without saving; Lưu bản nháp saves the draft. Validate the same candidate you intend to save. Both paths share the host's saved/active acknowledgement; Save alone does not prove active. Inspect those revisions and use Áp dụng when offered and permitted by the current host/build; explicit application checks saved and expected active revisions. Some hosts apply managed changes after active runs finish. Await the host's acknowledged active revision before a read-only Chạy thử (Test) under Thử cấu hình đang chạy. Test stays guarded during pending activation or saved/active mismatch; pending/restart-required/rejected is not an active acknowledgement. Test uses a fresh conversation pinned to that revision.

Conflict: retain draft → read current source/revision → review differences → explicitly rebase → deliberately submit. Uncertain save: fence writes and GET the original transaction receipt, never automatically replay POST. Admitted runs keep their accepted revision.

05 · Your initialization evidence

  1. Verified version, workspace and intended runtime identity.
  2. One mission and a Data Pool source URI/ID/current revision, or actual file/Skill filepath plus reviewed Git commit/hash/version.
  3. Minimum effective scopes, provider availability and operation credential bindings.
  4. Saved matches active; Test pins that revision.
  5. One real permitted model run, correct citations and a denied-scope check.

See quick-start prerequisites for installer/version/source-access requirements. Missing provider: operator setup using Models. Missing Pack/service: prepare dependencies, review source/manifest and explicitly grant. Missing backend: follow product integration, keep trusted product/backend runtime keys out of public product frontend code. Nest operator browser keys stay in page memory only; native Nest uses its private store. Each missing prerequisite is a concrete blocker, not permission to invent completion.

Content reviewed: 2026-10-09