The selected backend resolves from the on-host .agentm-config.json (config reference). The resolution chain: an explicit storage.backend value wins; otherwise an existing vault_path resolves to the built-in vault; otherwise a fresh install (no vault_path) resolves to device-local. If storage.backend names a backend whose plugin is not installed, the engine refuses the memory operation with a clear "install the <name> backend plugin" error — it never silently falls back. Use the doctor preview to see the selected backend and its plugin-installed state before that refusal could bite.

1. Inspect what selection resolves today (no config change), via the read-only doctor storage preview:

   python3 scripts/backend_selection.py --doctor
   # or, in a host that ships the doctor skill:
   /doctor

   It prints a single status line — storage [OK] …, storage [WARN] …, or storage [FAIL] … — naming the selected backend, where the selection came from (explicit storage.backend, an existing vault_path, or the fresh-install default), and whether that backend's plugin is registered. The preview is read-only: it resolves the selection without constructing a backend (construction would mkdir the device-local root), so running it never mutates anything. See what [OK]/[WARN]/[FAIL] mean below. Exit code is 1 only on [FAIL]; [OK] and [WARN] exit 0.

2. Set an explicit backend (optional — leave unset to use the fresh/vault default):

   python3 scripts/agentm_config.py --storage-backend <name>
   # e.g.
   python3 scripts/agentm_config.py --storage-backend device-local

   <name> is a registered protocol name (device-local, vault, or a plugin-provided name). The setter validates the value is non-empty only — it does not check the backend is installed, so you can configure a backend whose plugin lands later. It is idempotent (a silent no-op when the value is unchanged) and round-trips through --get storage.backend / --unset storage.backend. Leave it unset to let the resolver pick: a fresh install (no vault_path) resolves device-local; an existing vault_path resolves vault.

3. Re-run the doctor storage check to confirm the named backend's plugin is registered before relying on it:

   python3 scripts/backend_selection.py --doctor

   A clean result names the backend you just set and reports it registered:

   storage [OK] selected backend 'device-local' (configured (storage.backend)) — registered; root ~/.agentm/memory writable
   

   If instead you set a storage.backend whose plugin is not installed, the preview returns [FAIL] with the install-the-plugin message — the same one the engine would raise at the first memory operation:

   storage [FAIL] storage backend 'foo' is configured (storage.backend) but no installed plugin registers it. Install the plugin that provides the 'foo' backend, or set storage.backend to an installed backend (currently registered: device-local, vault).
   

   The fix is in the message: install the named plugin, or set storage.backend back to a registered name with the setter from step 2.

Use --requires to confirm the selected backend satisfies a named capability before any memory operation could refuse. This is the operator-facing surface of the required= parameter on select_backend (V5-7):

python3 scripts/backend_selection.py --requires concurrent_writers,encryption

Pass a comma-separated list of capability names from the Capabilities dataclass (concurrent_writers, conflict_files, encryption, sync). The flag validates names first — an unknown name prints an error to stderr and exits 1 without touching any backend:

error: unknown capability name(s): encryp. Valid names: concurrent_writers, conflict_files, encryption, sync

On valid names it calls select_backend(required=...) and prints exactly one line:

PASS: backend 'vault' satisfies required capabilities: concurrent_writers, encryption

or

FAIL: backend 'device-local' does not satisfy required capabilities: concurrent_writers, encryption

Exit code is 0 on PASS, 1 on FAIL (including an unregistered backend or missing vault path, which also print FAIL). Use this in install scripts or CI environment checks to gate on a specific backend capability before starting a long operation. No backend is constructed if name validation fails; construction happens only when the name check passes.

The preview emits exactly one status row. The same --doctor exit code drives whether the doctor skill reports a hard failure:

# 1. Default selection on a vault-configured host resolves 'vault', registered + seeded:
python3 scripts/backend_selection.py --doctor   # → storage [OK] selected backend 'vault' (existing vault_path) — registered; seeded from <vault>; exit 0

# 2. An uninstalled plugin fails loud (no silent device-local fallback):
python3 scripts/agentm_config.py --storage-backend foo
python3 scripts/backend_selection.py --doctor   # → storage [FAIL] storage backend 'foo' … Install the plugin …; exit 1
python3 scripts/agentm_config.py --unset storage.backend   # restore

The [FAIL] row proving the preview never silently demotes to device-local is pinned by test_no_silent_device_local_fallback (the TestFailLoud class) for the engine guard and by TestStoragePreview for the preview surface (scripts/test_backend_selection.py#L324).

• Storage seam — the verb-by-verb contract, the BackendRegistry, and the backend selection (part 5) surface.
• The memory↔storage seam — why selection fails loud instead of demoting, and why the engine cutover was a step beyond V5-1 (it shipped in V5-3).
• Installer CLI reference — the agentm_config.py config CLI that stores storage.backend alongside vault_path / state_mode.
• Run without a vault — the related state_mode / device-local path on a vault-less machine.