The memory↔process client seam (scripts/process_seam.py) gives you a small, read-only, graceful-no-op view. You call this seam from a process (like the crickets development-lifecycle phases today, or the V5-9 MCP server tomorrow). You use it instead of reaching into the memory engine's internals. It exports three functions. It composes these functions only from the DC-7-frozen public memory readers (resolve_project, resolve_active_plan, active_plan_paths, project_state_root, is_available — harness_state_dir retired under agentm-vault plan 15). It never uses a write path. The importable Python module forms the contract ([LC-1]). The python -m entrypoint gives you a convenience shim for non-Python shell callers.

You pass a context dict (or None) to each function. The keys are optional:

You use this to surface what could be saved from this context. You do this without saving it ([LC-2]). The function enriches the candidate with the resolved project slug and the vault target. It copies the candidate. It never mutates it. This lets you invoke the existing /memory save path.

It never persists data. It imports no write path. It calls no write path. You (the caller) or the engine's reflection judge save-worthiness. The seam deliberately avoids judging this.

You use this to resolve the harness state path for which in the current context. It wraps resolve_project and active_plan_paths (agentm-vault plan 15 dropped harness_state_dir from this composition — the seam now reads the same task-layout resolution resolve_active_plan returns). This gives you V5-10 named-plan awareness for free.

You use this to find one of a project's homes, so a plugin never composes a project layout itself (agentm-vault, resolve-the-project-homes). The project is the one bound to cwd through its .harness/project.json, or the one project names by slug. The answer is the project directory the resolver already names, with which joined onto it, so it is the same on the vault-root and memory-root layouts. It is returned whether or not the directory exists yet, and nothing is created.

A project named by slug has no checkout, so only the device-level state_mode applies to it: a .harness/.project-mode marker in whatever repo the process happens to stand in is never read in its place.

This acts as a thin shell shim ([LC-1]). You use it to expose the same functions to non-Python hosts. It always exits 0 on the graceful-no-op paths — the absent-memory degrade never wedges your process. state-path also exits 4 on one deliberate, non-graceful case: a bare call on a project that keeps its plans in numbered tasks, which has no singleton to answer with (agentm-vault plan 10). That's a refusal for the caller to act on, not a wedge — see the TaskNameRequired row above.

python3 scripts/process_seam.py state-path plan
python3 scripts/process_seam.py project-path desk --project movies-tv-games
python3 scripts/process_seam.py offer-save-here --kind decision --slug foo --body-file -

The Python module forms the contract. The entrypoint gives you a convenience for shell callers.

• Named plans — the resolve_active_plan precedence, the task layout, the exit-4 bare-call refusal state_path wraps, and list-plans --project SLUG for a project with no checkout.
• Memory↔process seam — This explains why the seam exists. It details the one-way dependency. It outlines the graceful-no-op philosophy.
• CI gates — This shows the check-one-way-imports gate's process-seam rule. This rule enforces the one-way edge. (CONS-1 merged the former standalone check-process-seam-import-direction.sh into this config-driven Python checker).
• AgentMemory context payload — This defines the read-only memory contract the seam composes over.
• AgentM HLD — V5 unbundling — This records the decision that introduced the seam concept.