The source checkout keeps canonical skills at repository root and packages
runtime and benchmark assets under mcp/src/agents_remember/package_data/. The
MCP runtime_install tool reconciles those assets into ar-coordination/.
agents-remember/
skills/ # canonical skill source tree
scripts/
sync-skills.py # copies root skills into generated targets
mcp/
src/agents_remember/
install/
package_data/
runtime/
agents-md-files/
coordinator/AGENTS.md
skills/AGENTS.md
system/AGENTS.md
tasks/AGENTS.md
providers/
requirements/
patches/
skills/
c-00-initialize-memory-repo/ # generated copy of root skills/
l-01-session-job-lifecycle/
w-02-light-task-workflow/
system/defaults/examples/
benchmarks/
providers/
mcp/
Edit skills/ directly. Do not edit the generated skill copies in
mcp/src/agents_remember/package_data/runtime/skills/ or the harness starter
packages by hand; run python3 scripts/sync-skills.py after root skill edits.
ar-coordination/
AGENTS.md
providers/
requirements/
patches/
runners/
<provider>/<instance-id>/
data/
<provider>/
logs/
<provider>/
skills/
system/
AGENTS.md
tasks/
AGENTS.md
memory-repos/
benchmarks/
notes/
worktrees/
temp/
runtime_install owns package runtime assets only:
AGENTS.md templates--include-benchmarks is passedIt does not own live settings, notes, tasks, worktrees, normal memory repo content, temp files, onboarding content, or provider databases.
ar-coordination/providers/ is provider runtime state. The source installer
reconciles package-owned defaults from
agents_remember/package_data/runtime/providers/. Dependency-skipped installs
preserve live Docker runner instances, image build roots, data, and logs; full
provider reinstall treats Docker runner instances as recreatable while
preserving data and logs. Provider dependency installation and full provider
reinstall are MCP-owned operations driven by MCP authority settings. Pinned
requirements, patches, Docker image locks, logs, and per-instance runtime state
must be recoverable. Durable provider data lives under
ar-coordination/providers/data/.
Provider Docker topology is source-controlled package data. Stable Dockerfiles,
base Compose files, and override templates live under
agents_remember/package_data/runtime/providers/; lifecycle code fills those
templates with MCP-derived paths, ports, image tags, container names, and repo
roots at command time. Rendered Compose overrides are passed to
docker compose -f <package-base> -f - ... through stdin and are execution
input only. They are not written into ar-coordination/ or the model workspace,
and status/debug payloads may report only the rendered override hash plus
Compose/image/container state.
Provider dependencies and artifacts are coordination-owned runtime state, while
live provider execution uses Docker runner images/containers and
provider-family artifacts under providers/runners/<provider>/. For GrepAI,
MCP-derived provider settings expand memory roots into workspace projects;
managed mode mirrors those roots into providers/runners/grepai/index-roots/
before launching GrepAI so its unavoidable per-project .grepai/ config and
symbol files stay under provider-owned runtime paths. GrepAI workspace config,
runtime state, cache, and mirrors live under providers/runners/grepai/,
while user-facing logs live under logs/providers/grepai/ and all roots share
one lifecycle-owned PostgreSQL/pgvector Docker backend whose persistent data
root is under providers/data/grepai/postgres/. For CodeGraphContext,
MCP-derived provider settings build an agents-remember/codegraphcontext:<pin>
runner image, run bounded CGC commands and watchers through Docker Compose as
the host user when supported, and expand code roots into per-repo instance roots
under providers/runners/codegraphcontext/<repo-id>/.codegraphcontext/ so
.env, config.yaml, .cgcignore, logs, and state remain outside indexed
source repositories. Those repo instances share one lifecycle-owned FalkorDB
Docker backend on the shared CGC Docker network whose persistent data root is
under providers/data/codegraphcontext/falkordb/, and reinstall/update must
preserve providers/data/ and logs/providers/ unless an explicit destructive
lifecycle command is requested.
The Python provider lifecycle, provider setup, and benchmark runner behavior
lives under package-owned MCP modules; they are not installed into coordinator
runtimes and no parallel source-level scripts/ execution route is kept.
Normal provider install/status/start flows go through MCP tools and
package-local provider modules.
When benchmark installation is enabled, runtime_install reconciles package-owned benchmark content under ar-coordination/benchmarks/ and preserves only user-generated outputs under ar-coordination/benchmarks/user-runs/. Source benchmark content includes case manifests, prompts, author results, docs, and workspace templates, not pre-created workspaces. Generated benchmark workspaces are resettable state; normal user memory under ar-coordination/memory-repos/ is not touched.
Each generated benchmark case workspace has one shared code checkout area under workspaces/<case-id>/repos/ and one benchmark-local coordination root under workspaces/<case-id>/ar-coordination/. prepare renders workspaces/<case-id>/AGENTS.md from the benchmark template, then clones both pinned code repositories and pinned memory repositories into those resettable workspace locations. Variants are execution modes and result groups, not duplicated workspace trees.
skills_install copies the packaged skills into a harness skill root for
maintenance/manual and non-package installs. It is MCP-owned and does not create
symlinks. The package-based first-run path gets these skills from the copied
harness starter package instead. The packaged skills are flat (one folder per
skill), so each is copied directly:
<install-root>/<skill-name>/
<skill-name> is the skill’s lowercase frontmatter name. There is no layout option or namespace folder — the source is already flat, so the installer just copies the skills across.