[Feature Request] Extend Nowledge Mem integration with automatic setup, Working Memory injection, and session lifecycle support

Start by reading the existing memory provider adapter in apps/cli/src/lib/memory-providers.ts and the implemented Agent Role memory design note linked in the issue. Then review the session export discussions in #112 and proposal #68, plus the Codex integration reference, to map existing setup and lifecycle capabilities. Done means supported harnesses have opt-in setup, startup context, tools and guidance, transcript capture, separate capability status, and an acceptance path covering manual and delegated sessions.

Affected area

Agent runtime / ACP

Problem or workflow pressure

Lody already integrates with Nowledge Mem for memory identity management and Agent Role binding. I would like that integration to provide a complete, usable memory workflow for Lody-managed sessions.

In my current setup, Codex provides the experience I need: startup Working Memory/context, guidance for using memory, callable tools, and automatic conversation capture through lifecycle hooks. I have not been able to configure an equivalent complete experience consistently across the other harnesses I use in Lody.

Connecting the MCP server alone does not provide those automatic behaviors. I still need to understand each harness's plugin installation, configuration files, hook support, and update procedure. Native-application support also does not necessarily mean the same integration works when that harness runs through Lody.

I would like to enable Nowledge Mem in Lody and have Lody handle the supported setup and lifecycle integration, instead of manually assembling and maintaining a separate toolchain for each harness.

Desired outcome

After a user connects and enables Nowledge Mem in Lody:

1. Lody reuses the selected Mem connection and identity, and handles the required setup for supported harnesses without manual configuration-file or hook editing.
2. Context Bundle / Working Memory is available before the agent begins the first task. A later voluntary tool call should not be reported as automatic startup injection.
3. The agent receives appropriate memory tools and guidance for retrieval and saving.
4. Real conversation transcripts are captured automatically at supported lifecycle checkpoints, rather than relying on the agent to summarize or remember to save them.
5. Manual and delegated sessions receive the same configured integration.
6. Lody reports tool connectivity, startup-context injection, and transcript capture separately, including unsupported capabilities and actionable failures.
7. The integration coexists with native plugins without duplicate context injection, tools, or transcript capture, and provides a supported update/repair path.

The user-facing goal is a Codex-like complete memory experience within Lody, with clearly documented support boundaries.

Proposed solution

Extend the existing Memory integration with an opt-in setup and capability check for Lody-managed sessions.

The implementation could combine automatic installation/configuration of official Mem connectors with Lody-owned lifecycle integration where appropriate. I am not requesting that every harness use Codex's hook format or that Lody reproduce every native plugin internally.

Where Lody owns the lifecycle, it could load startup context before dispatch and capture the canonical conversation after supported completion/checkpoint events. Where an official native connector already provides a capability, Lody should coordinate ownership to avoid running it twice.

Expose a small capability/status view for each supported harness: tools, startup context, memory guidance, and automatic capture. Unsupported features should remain explicit instead of treating a healthy MCP connection as complete integration.

Alternatives or workarounds

• Installing official Mem plugins separately for each harness works where supported, but requires manual setup and maintenance and does not establish compatibility with Lody's execution mode.
• Injecting only the Mem MCP server provides callable tools but does not guarantee startup Working Memory or automatic transcript capture.
• Prompting the agent to read memory and save the conversation depends on model behavior and is not equivalent to reliable lifecycle integration.
• Using only Codex avoids some setup differences but prevents me from getting the same memory workflow when choosing other harnesses in Lody.

Trade-offs or non-goals

This should extend the existing Nowledge Mem integration, not introduce a general-purpose plugin marketplace.

Equivalent outcomes matter more than identical hook names. Support can be introduced incrementally, with an explicit capability matrix rather than a promise that every harness supports every lifecycle event.

Setup and automatic transcript capture should be opt-in and respect the selected Mem identity, Space, and endpoint. Existing native configuration should be preserved, and capture should be coordinated to avoid duplicate imports.

Memory-service failures should be visible and should not silently appear successful or prevent unrelated agent work from continuing.

Generic per-agent MCP selection is a separate feature. It can support this integration, but it does not replace startup context and lifecycle behavior.

Additional context

Existing foundations and related work:

• #1246 added Agent Role memory providers with Nowledge Mem.
• The current adapter manages provider status and identities and maps the selected identity to NMEM_AGENT_ID:
  https://github.com/LodyAI/Lody/blob/91fa467a205c71966b715356a7bf04b501fbb199/apps/cli/src/lib/memory-providers.ts#L46-L120
• The implemented design note explicitly leaves agent-side Mem plugin installation as a separate prerequisite:
  https://github.com/LodyAI/Lody/blob/91fa467a205c71966b715356a7bf04b501fbb199/.agents/notes/implemented/feature/2026-10-04-agent-role-memory.md
• The Codex integration provides a concrete reference for the desired startup context, memory guidance, MCP tools, and automatic transcript capture:
  https://mem.nowledge.co/docs/integrations/codex-cli
• #112 and proposal #68 discuss a stable, provider-neutral session export contract. That could support reliable transcript capture; this request additionally covers user-facing setup, startup context, and the complete Mem integration workflow.

An acceptance scenario would be enabling Mem once, creating both a manual session and an orchestrator-created session using a supported non-Codex harness, and verifying that startup context is present before work begins, memory tools work, and the actual conversation is captured automatically without per-harness manual hook configuration.

Before submitting

• I searched the existing issues and did not find a duplicate request.
• This request concerns an open-source component in this repository, not a hosted service, Web or mobile app, account, or billing issue.
• I removed credentials, private source, conversations, prompts, personal data, and other sensitive information.