# 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.

```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

| Component | The question it answers | Owner |
| --- | --- | --- |
| Soul | How should it work consistently? | Soot definition |
| Mission | What job and boundaries? | Soot definition |
| Skill | Which SOP/knowledge to read? | Pack capability |
| Tool | Which operation can execute? | Capability + host binding |
| Provider/vault/policy | Models, secrets and limits? | Runtime host |
| Conversation/run/state | Objective, 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.

```sh
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](https://trysoot.com/docs/quick-start/index.md#02-check-the-actual-installation-path) for installer/version/source-access requirements. Missing provider: operator setup using [Models](https://github.com/2found/2agent/blob/main/docs/models.md). Missing Pack/service: prepare dependencies, review source/manifest and explicitly grant. Missing backend: follow [product integration](https://github.com/2found/2agent/blob/main/docs/product-integration.md), 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.