Milestone
M7 — Standards + ecosystem. This is the pluggable-standard work for the memory-engine axis: making AgentKeys' memory-ranking integration a config-driven standard so third-party HTTP-API vendors plug in as data, not code.
What
A specification (planning/docs only) for a generic, config-driven HTTP adapter on the memory-engine axis (arch.md §22). Every memory-ranking vendor whose contract is "POST {query, top_k} → JSON array of scored hits" (OpenViking, mem0, Supermemory, Honcho, RetainDB, Memori) collapses onto one adapter crate (agentkeys-memory-http) driven by a declarative profile (endpoint + header template + request-body template + a JSON-Pointer {score, text, uri} response mapping). A new HTTP-API vendor becomes a profile file, not a crate — never a server-fleet rebuild, zero-recompile for operator-loaded profiles.
Vendors that don't fit the gate-then-rank-over-HTTP shape (Holographic = local/in-process; anything non-HTTP / multi-round) keep a per-vendor crate.
Plan doc
docs/plan/standards/memory-engine-http-adapter.md (on branch claude/sad-turing-223c73 until merged) — reviewed via /plan-eng-review (CLEAR) + a codex outside-voice pass (8 findings, all folded). Discoverable from arch.md §22.
Prerequisite
Scope — stages (all post-#179)
- H1 —
agentkeys-memory-http crate: profile schema + RFC 6901 resolver + concrete HttpRankEngine (bounded timeout + response-size caps) + shared gate-bound reconcile applying the full SelectionBudget (max_lines+max_bytes) + bundled openviking.json; hook drops the "openviking" literal.
- H2 — operator profile sources + endpoint-host-class egress enforcement + master allow-list + the egress audit
op_kind (arch §15.3b ritual + hook audit client).
- H3 — mirror sync (write-through on
memory.put, delete-through on teardown, batch reconciler; idempotent by line-ULID).
- H4 —
mem0 + Supermemory profiles (prove a real non-OpenViking vendor — the abstraction-stability gate); retire agentkeys-memory-openviking.
- H5 —
agentkeys wire generalization + arch.md §22 update + promote plan to spec/.
- H6 (cross-plan dep) — signed profile manifest bound to the
Config data class (classifier-service P1); off the critical path.
Key invariants (carried from the engine seam, #177)
- Gate-as-bound — the adapter only ever reorders gate-authorized lines; it can never widen visibility (a malicious/over-broad profile or endpoint cannot leak unauthorized content).
- Never load-bearing for availability — any error / timeout / empty / no-match → deterministic fallback engine.
- Egress posture —
local vs cloud enforced on the endpoint host (not a self-declared field), master-allow-listed, audited; the durable store stays K3-encrypted regardless of which engine ranks it.
Related
Planning/docs only — no code lands in the originating worktree; implementation is the H1–H6 stages above.
Milestone
M7 — Standards + ecosystem. This is the pluggable-standard work for the memory-engine axis: making AgentKeys' memory-ranking integration a config-driven standard so third-party HTTP-API vendors plug in as data, not code.
What
A specification (planning/docs only) for a generic, config-driven HTTP adapter on the memory-engine axis (arch.md §22). Every memory-ranking vendor whose contract is "POST
{query, top_k}→ JSON array of scored hits" (OpenViking, mem0, Supermemory, Honcho, RetainDB, Memori) collapses onto one adapter crate (agentkeys-memory-http) driven by a declarative profile (endpoint + header template + request-body template + a JSON-Pointer{score, text, uri}response mapping). A new HTTP-API vendor becomes a profile file, not a crate — never a server-fleet rebuild, zero-recompile for operator-loaded profiles.Vendors that don't fit the gate-then-rank-over-HTTP shape (Holographic = local/in-process; anything non-HTTP / multi-round) keep a per-vendor crate.
Plan doc
docs/plan/standards/memory-engine-http-adapter.md(on branchclaude/sad-turing-223c73until merged) — reviewed via/plan-eng-review(CLEAR) + a codex outside-voice pass (8 findings, all folded). Discoverable from arch.md §22.Prerequisite
agentkeys-coreinto leaf crates — the clean provider seam). This issue is the named "Follow-up" from refactor(memory-engine): extract engine + OpenViking provider out of agentkeys-core (kill the broker rebuild cascade) #179.Scope — stages (all post-#179)
agentkeys-memory-httpcrate: profile schema + RFC 6901 resolver + concreteHttpRankEngine(bounded timeout + response-size caps) + shared gate-bound reconcile applying the fullSelectionBudget(max_lines+max_bytes) + bundledopenviking.json; hook drops the"openviking"literal.op_kind(arch §15.3b ritual + hook audit client).memory.put, delete-through on teardown, batch reconciler; idempotent by line-ULID).mem0+Supermemoryprofiles (prove a real non-OpenViking vendor — the abstraction-stability gate); retireagentkeys-memory-openviking.agentkeys wiregeneralization + arch.md §22 update + promote plan tospec/.Configdata class (classifier-service P1); off the critical path.Key invariants (carried from the engine seam, #177)
localvscloudenforced on the endpoint host (not a self-declared field), master-allow-listed, audited; the durable store stays K3-encrypted regardless of which engine ranks it.Related
Planning/docs only — no code lands in the originating worktree; implementation is the H1–H6 stages above.