Mnemon Laravel Package

Technical Evaluation

Framing note: Mnemon ships as a deployable Laravel application (Passport for OAuth, Filament v5 for admin), not a composer-installable library. The integration surface is HTTP + MCP, not PHP code. A TPM should evaluate it as a sidecar service, not as a dependency to composer require.

• Architecture fit: Clean sidecar boundary. It owns its own Postgres database and speaks MCP over Streamable HTTP at POST /mcp, so it imposes no runtime coupling on existing Laravel services. Cost is a new stateful service (Postgres 17 + pgvector) plus an embedding provider in the estate. Fits teams already standardized on Postgres; degrades meaningfully on SQLite-only shops (semantic search off, benchmark gap of +0.12 recall@5 / +0.14 hit_rate@1).
• Integration feasibility: High on the client side — 14 documented MCP tools, standard OAuth 2.1 with Dynamic Client Registration and device grant, a one-command installer, and /mnemon:doctor that validates tools, config, token, reachability and a live tool call. Low on the "Laravel package" side — no service provider, no publishable config, no events, no queue integration, no documented PHP API. There is nothing for an application developer to extend; everything is protocol-level.
• Technical risk: The author's own limitations list contains several authorization-relevant items, which is the dominant risk: a wiki page's wing is derived from its name rather than its sources (generically named pages can be scoped wrongly); a restricted context_set still rebuilds wiki-wide wiki:index/wiki:log; wiki_lint auto-fix requires an unrestricted token. In a single-tenant deployment these are cross-project leakage vectors rather than cross-tenant, but they are still information-boundary bugs. Additionally: the admin panel treats any registered user as admin; reverse proxy support is explicitly untested end to end (and that is the path to production TLS); no streaming on the transport; append-only palace with no stated retention or compaction story; license not stated in the notes.
• Key questions to put to the maintainer before adoption:
  1. License and redistribution terms?
  2. Versioning/deprecation policy for the MCP tool schemas and the on-disk palace schema?
  3. Is there a supported export/portability path for palace + wiki content (lock-in check)?
  4. What is the tested backup/restore procedure?
  5. What happens on an embedding-provider outage — do writes fail, queue, or silently fall back to full-text?
  6. What is the cost/behavior of switching embedding drivers (full re-embed of an append-only corpus)?
  7. Are the wing-restriction edge cases covered by dedicated authz tests, or only by the general 697-test suite?
  8. Is multi-instance deployment supported (shared Postgres + multiple app containers), or does the hook/session design assume one?

On the benchmark: it is honest (retrieval layer only, methodology and caveats published) but the QA leg is judged by the same model family that answers, so treat the +0.070 accuracy delta as directional rather than a procurement justification. It is useful for internal A/B on your own corpus, not as a vendor claim.

Integration Approach

• Stack fit: Laravel (Filament v5 implies a current major), PHP 8.x, Postgres 17 + pgvector, optional OpenAI or Ollama embeddings, Docker Compose for local. It will sit beside an existing Laravel monolith, not inside it — separate Passport user table, separate session/auth model, separate deploy pipeline. Plan for that duplication explicitly rather than assuming SSO; nothing in the release notes suggests identity federation.
• Migration path: Greenfield; there is no importer from Confluence, Notion, an existing vector store, or a prior memory tool. Realistic path: (1) validate retrieval quality against your own queries using the read-only demo at trymnemon.com; (2) stand up a keyless self-host on loopback; (3) re-run the same query set with real embeddings and compare — this is important because the keyless→embedded switch changes result ordering, so any prompt or workflow tuned in keyless mode will drift when embeddings are enabled; (4) only then migrate real content.
• Compatibility: Postgres 17 is the supported target (CI runs the suite against it); SQLite is a degraded mode, not a peer. Reverse proxy requires TRUSTED_PROXIES and is untested end to end — budget a spike, especially around OAuth redirect/callback and device-flow endpoints behind TLS termination. OAuth 2.1 + DCR is natively compatible with the Claude Code plugin flow; Cursor/ChatGPT/other clients are manual MCP configuration. No streaming means long tool calls must survive proxy idle timeouts.
• Sequencing (recommended):
  1. Demo-based retrieval eval against a fixed query set (½ day, no infra).
  2. Keyless self-host on a single engineer's machine, loopback-bound.
  3. Postgres + pgvector, with Ollama embeddings for a no-egress pilot; switch to OpenAI only after a data-handling decision.
  4. Reverse proxy + TLS spike; document the working config since upstream hasn't tested it.
  5. Model wings/rooms to your actual project boundaries before onboarding users — this is a product taxonomy decision with rework cost if deferred.
  6. Claude Code hooks pilot with a small group; note auto-update is enabled by the installer and is otherwise off by default for third-party marketplaces — a supply-chain decision to make consciously, not inherit.
  7. Assign an owner for wiki compilation cadence (see below) or explicitly accept a stale wiki.

Operational Impact

• Maintenance: Highest-risk dimension. Self-described "working personal tool, not a finished product," at v1.0.0 with a single maintainer and no stated LTS or support window. Expect schema churn in both the palace and the MCP tool surface. Every upgrade needs a DB snapshot and a rollback path; treat it like a database-adjacent service, not a stateless container.
• Support: Community issues only; no vendor escalation. /mnemon:doctor is a genuine support-cost reducer on the client side and should be the first thing in any internal runbook. Budget internal ownership: one engineer as de facto maintainer.
• Scaling: The binding constraint is storage growth, not request throughput — the palace is append-only and never compacts, so pgvector index size and full-text index bloat grow monotonically with agent usage. Embedding generation on write is the cost driver (OpenAI: egress + per-token spend; Ollama: local CPU/GPU contention). Single-tenant design means no noisy-neighbor problem, but also no consolidation across teams — you deploy one instance per team or accept a shared admin surface where every registered user is an admin.
• Failure modes to instrument:
  • Embedding provider outage → unclear whether writes fail, queue, or degrade to full-text; must be determined and alerted on.
  • Silent retrieval degradation if pgvector/Postgres features are unavailable (falls back to full-text + recency rather than erroring).
  • Wiki staleness accumulating silently — mnemon:auto-compile-stale reports only; nothing self-heals.
  • Access token expiry at 1 hour mid-agent-session, with refresh to 90 days; device-flow re-auth UX is unproven at scale.
  • Restricted-token edge cases producing over-broad or over-narrow visibility — both are incidents, and the "hidden reads like missing" property makes them hard to detect.
  • Reverse proxy misconfiguration breaking OAuth redirects or MCP endpoint routing.
• Ramp-up: End users: low — plugin install plus one doctor command. Operators: moderate — Postgres/pgvector, embedding driver selection, OAuth consent-screen semantics, and wing modeling. Realistic pilot estimate: ~1 engineer-week including the proxy spike and a query-set evaluation. The expensive part is not technical; it is deciding the wing/room taxonomy, which is a product decision that determines whether the access-control model helps or gets in the way.

Recommendation: Adopt as a bounded pilot, not a platform commitment. Gate general availability on three things: (a) license clarity, (b) a documented export/portability path, and (c) the authorization edge cases either fixed upstream or accepted in writing by your security owner. The retrieval benchmark and the MCP/OAuth surface are strong for a v1.0.0; the tenancy model, proxy story, and maintenance posture are not yet enterprise-shaped.