Governed memory, persona & workspace layer for Odysseus — introducing PLwC as a potential MCP integration

[mhoedt-ai]

Hi — I've spent the last 80+ days building PLwC (Personality Layer with Conscience), a governed memory, persona, and workspace system for Claude that runs as an MCP server. I think it could be a useful addition to Odysseus, and I'm curious whether there's interest.

What PLwC covers

Everything in PLwC runs through a governance layer — nothing is free-form:

Persona & memory

• A compiled persona profile (tone, working style, behavioral rules) injected at session start
• • A governed memory system — facts require verifiable evidence before promotion, go through an explicit approval flow, and every mutation is logged in an audit journal with content hashes
• • Memory lifecycle — ACTIVE/RETIRED states, entries addressable by content hash, clean retirement without losing the audit trail
• • A semantic validation layer that blocks the model from writing autonomous self-descriptions into persistent memory
    Workspace & file operations
• All file operations (read, write, copy, exact_replace, list, search) are policy-checked at the gateway level — each call returns an explicit ALLOW or DENY with a reason, never a silent failure
• • Write operations have strict validation rules (e.g. write + source_path → DENY with redirect to copy; exact_replace without expected_replacements → DENY)
• • Sandboxed Python execution for code tasks
• • Document operations (DOCX, PDF, XLSX) run through Docker-isolated workers
• • The workspace is path-scoped — operations outside the defined root are blocked
    Why Odysseus

Odysseus has great tools (shell, files, MCP, ChromaDB), but they're essentially open: the agent decides what to do and the workspace accepts it. PLwC's model is different — the gateway enforces policies before any operation reaches the filesystem, and every action is attributable and auditable.

There's also a structural problem on PLwC's side: running in Claude Desktop via MCP, the compiled persona arrives as a tool-call result, not as a proper system prompt. Odysseus controls the API call directly, which would fix that.

What I'm exploring

Whether PLwC makes sense as an Odysseus MCP integration — a governance server that sits between the agent and the filesystem/memory. I also noticed the mcp_servers folder and the Codex/Claude integration commits, so the direction seems compatible. Odysseus already has a THREAT_MODEL.md that acknowledges gaps around shell sandboxing — PLwC's policy-at-the-gateway approach might be relevant there too.

Happy to share the architecture, the codebase, or more detail on the governance model if there's interest.

[alteixeira20]

This is interesting, especially as an MCP integration rather than something that needs to land directly in core.

The part that seems most valuable to Odysseus is not “persona” by itself, but the governed gateway model: explicit ALLOW/DENY decisions, path-scoped workspace access, auditable mutations, memory promotion rules, and clear reasons when an operation is blocked. That overlaps with several problems Odysseus will need to handle more rigorously as tools, MCP servers, plugins, memory, and workspace operations become more powerful.

I would be cautious about making this a core subsystem too early, though. Memory/persona/workspace governance is a sensitive boundary, and it can easily become both product-defining and security-critical. My instinct would be to prove it first as an external, opt-in MCP integration with a very small Odysseus-facing contract.

A useful proof of concept might be:

1. Run PLwC as an MCP server with no core changes.
2. Expose a small set of governed file/workspace operations.
3. Show clear ALLOW/DENY behavior with reasons.
4. Demonstrate audit logging for writes and memory mutations.
5. Define how memory promotion works, including who approves it and how evidence is attached.
6. Document the trust boundary: what PLwC protects against, what it does not protect against, and what still depends on Odysseus or the host environment.
7. Avoid injecting a large opaque persona layer until the precedence and visibility rules are clear.

The system-prompt point is also worth separating from the MCP integration itself. Odysseus controlling the API call may make better persona/context injection possible, but I would want that to be explicit, inspectable, and user-controlled. A compiled persona that silently changes behavior could become hard to debug unless users can see what was injected and why.

So I would be interested in this as a governed MCP proof case: path-scoped workspace access, memory mutation approval, audit trails, and policy enforcement at the tool boundary. If that works cleanly outside core, it could provide useful input for future plugin/MCP permission models without forcing Odysseus to own the whole governance/persona system immediately.

[mhoedt-ai]

Thanks — that framing makes sense to me.

I agree that the most useful Odysseus-facing slice is the governed gateway model, not the persona layer as a broad subsystem. For a proof of concept I would keep PLwC external and opt-in, with a small MCP contract focused on governed workspace and memory operations.

A reasonable first PoC could be:

• path-scoped file operations with explicit ALLOW/DENY decisions and reasons
• strict validation for writes and replacements before anything reaches the filesystem
• audit logging for every mutation, including content hashes
• a minimal governed memory flow with evidence attachment and explicit approval
• documentation of the trust boundary: what PLwC protects, what remains the responsibility of Odysseus or the host environment, and what is deliberately out of scope

I also agree on the persona/context injection point. The current Claude Desktop MCP setup is not ideal because compiled context arrives as a tool result rather than as a proper, visible system-level input. For an Odysseus PoC I would avoid a large opaque persona layer and make any injected context explicit, inspectable, and user-controlled.

So I’ll narrow the proposal to a governed MCP proof case: workspace policy enforcement, auditable mutations, and memory promotion governance. If that works cleanly outside core, it can provide useful input for future MCP/plugin permission models without requiring Odysseus to own PLwC as a full subsystem.

[mhoedt-ai]

ODYSSEUS_FORUM_POST_PLWC_FIRST_POC_FULL_EN.md
PLWC_FULL_ENGLISH_POC_TEST_REPORT_2026-07-09.md

Quick update: I ran the PLwC-first PoC with a tool-call-capable MCP host.

This was not an Odysseus compatibility test yet. The goal was only to validate PLwC as an external governed MCP boundary, exactly in the shape discussed above.

Test environment:

PLwC server: plwc-gateway
Version: 0.2.0rc18.dev7
Public tools: 8/8 registered
Reference host: Codex/OpenAI MCP host
Odysseus compatibility: not claimed

The governed gateway test passed.

Validated behavior:

workspace create_dir: ALLOW
workspace write: ALLOW
workspace exact_replace with expected_replacements=1: ALLOW
workspace read/search/list/file_info: ALLOW

missing required path: NOT_EVALUATED / validation_error / adapter_called=false
protected profile path through workspace tool: DENY / policy_denied
parent traversal write: DENY / changed_files=[]
exact_replace without expected_replacements: NOT_EVALUATED / validation_error
post-denial readback: no unintended mutation

Audit logging also worked. Writes, denied requests, reflection writes, and the confirmed memory mutation were recorded as metadata-only audit events. Content was redacted in the audit log, while decision metadata, risk level, changed counts, replacement counts, and error categories were preserved.

I also tested the governed memory flow:

reflection write: ALLOW
memory promotion plan: ALLOW / eligible_for_apply=true / confirmation_required=true
memory promotion apply with confirmed=true: ALLOW / result=applied
changed_files=[memory.md, journal.md]
duplicate candidate after apply: duplicate_noop / eligible_for_apply=false
profile schema after mutation: valid

One useful detail surfaced during the test: for this memory_promotion path, applying by plan_id was rejected. The successful apply required the same candidate fields plus confirmed=true. That is good PoC evidence because it shows the gateway is enforcing its own apply contract rather than blindly accepting a plan identifier.

For persona/profile context: I deliberately kept the personal/persona layer out of the governance proof. The compile calls were run with:

persona_layer=false

Observed behavior:

PERSONA section omitted
profile_files_mutated=false
hard gates preserved
governance preserved
task context remained explicit and inspectable

I also ran a contrast compile with persona_layer=true, and PLwC included the PERSONA block only when explicitly requested. So the PoC did not rely on hidden persona/system-prompt injection. The active profile was used only as governed storage for reflection and memory mutation tests; the personal/persona behavior layer was explicitly deactivated for the main governance checks.

So the current result is:

PLwC works as an external governed MCP boundary with a tool-call-capable MCP host.
The public facade is small and inspectable.
Workspace operations show clear ALLOW/DENY/NOT_EVALUATED behavior.
Profile and memory changes require governed tools, not raw workspace access.
Memory promotion can be planned, confirmed, applied, audited, and duplicate-checked.
Persona/context compilation can remain explicit, inspectable, and user-controlled.

I still would not claim Odysseus compatibility from this test alone. That should remain a separate host/backend test:

Odysseus -> selected backend/model -> real tool call -> Odysseus MCP execution -> PLwC

But as a PLwC-first governed MCP proof case, the test passed.

[mhoedt-ai]

PLwC as an external governed MCP boundary: Odysseus smoke passed with DeepSeek V4 Pro

I ran a second Odysseus PLwC smoke test, this time using DeepSeek V4 Pro as the backend:

Odysseus -> DeepSeek V4 Pro -> PLwC MCP gateway

This run completed the full PLwC usability smoke successfully.

What was tested

The scope was deliberately narrow: PLwC as an external, opt-in governed MCP boundary for Odysseus.

The persona/personal layer was disabled for this smoke. The test did not depend on hidden persona or system-prompt injection. Profile storage was still used where needed for governed reflection and memory tests, but persona behavior was not part of the claim.

The tested PLwC public facade was:

plwc_status
plwc_describe
plwc_profile
plwc_reflection
plwc_governor
plwc_sandbox_run
plwc_workspace_operation
plwc_document_operation

Result

PASS: Odysseus + DeepSeek V4 Pro executed real PLwC MCP tool calls across the full smoke.

Summary:

Area	Result
Real MCP tool-call gate	PASS
PLwC public facade	8/8 tools
Runtime status	PASS, plwc-gateway, 0.2.0rc18.dev7
Workspace list/read	PASS
Workspace write	PASS, ALLOW
Guarded exact replace	PASS, replacement count 1
Invalid exact replace	PASS, validation error, no mutation
Parent traversal write	PASS, DENY
Protected profile write through workspace tool	PASS, DENY
Misused source_path with write	PASS, validation error
Sandbox boundary	PASS, bounded Docker sandbox, no host fallback
Document facade	PASS after using the correct content.lines payload
Persona-disabled profile compile	PASS, persona_layer=false, PERSONA omitted
Working context compile	PASS, task context visible and inspectable
Governed reflection write	PASS
Memory promotion plan	PASS, confirmation required, no mutation by plan alone
Memory promotion apply	PASS, required confirmed=true, changed memory.md and journal.md
Duplicate memory candidate	PASS, duplicate_noop
Audit/mutation metadata	PASS at response level
Trust boundary	Documented

Important difference from the local backend run

The earlier local-model run was not a clean PLwC/Odysseus pass.

The local backend could see and describe the PLwC tools, but later lost or did not expose the PLwC tools as actual callable tools. It even routed a step to web search instead of PLwC. I would classify that run as:

PARTIAL / FAIL_TOOL_ACCESS_REGRESSION

The important distinction is:

Tool discovery worked with the local backend.
Reliable tool execution did not.

With DeepSeek V4 Pro, the tool execution path remained stable through the full smoke, including memory promotion and duplicate detection.

PLwC-specific parameter notes

The test also clarified a few PLwC schema details:

exact_replace requires expected_replacements as an integer.
create_pdf expects content.lines rather than content.paragraphs.
The public document slice may reject overwrite, so a fresh output path should be used.
Reflection markers must be valid PBA2 markers or aliases, e.g. observation / Beobachtung.
Reflection trust values use PLwC values such as niedrig, mittel, hoch.
Memory promotion requires sufficient trust; trust=hoch was needed for the apply-eligible plan.
Memory promotion apply required confirmed=true.

These are normal schema/contract details, not governance failures.

Trust boundary

This smoke supports the governed gateway model:

PLwC protects operations that pass through plwc-gateway.
PLwC enforces workspace scoping, protected profile/governance path denial, request validation, guarded replacement, governed reflection writes, memory plan/apply confirmation, duplicate detection, and mutation metadata.

It does not claim protection against:

host-side bypass tools,
direct shell/filesystem access outside PLwC,
a compromised host runtime,
compromised MCP transport,
or a backend/model that cannot reliably execute real tool calls.

Odysseus still remains responsible for making tool-call execution visible and auditable on the host side.

Conclusion

The useful conclusion from the second run is:

PLwC is usable from Odysseus as an external governed MCP boundary when the selected backend reliably executes real MCP tool calls.

For this setup:

DeepSeek V4 Pro backend: PASS
Small local backend run: PARTIAL / FAIL_TOOL_ACCESS_REGRESSION
PLwC governance behavior: PASS when the host/backend executes the tools

So I would not frame the remaining issue as a PLwC governance problem. The key variable is Odysseus backend/tool-calling reliability.

If useful, I can attach the smoke matrix and the two run analyses:

ODYSSEUS_PLWC_USABILITY_SMOKE_TEST_SUITE.md
ODYSSEUS_PLWC_SMOKE_RUN_ANALYSIS_2026-07-10.md
ODYSSEUS_PLWC_SMOKE_RUN_ANALYSIS_DEEPSEEK_V4_PRO_2026-07-10.md

ODYSSEUS_PLWC_USABILITY_SMOKE_TEST_SUITE.md
ODYSSEUS_PLWC_SMOKE_RUN_ANALYSIS_2026-07-10.md
ODYSSEUS_PLWC_SMOKE_RUN_ANALYSIS_DEEPSEEK_V4_PRO_2026-07-10.md

[mhoedt-ai]

One more Thing: In this run, setup plus two full smoke attempts cost roughly €0.29, which makes cloud-backed tool-call validation practical for this PoC.

[Plaer1]

Hey I have a not super tested but pretty verbose memory system tacked onto Odysseus on my setup also via the form of MPC; if you wanted to look at the code and borrow anything, I would be stoked to contribute to stuff other people are doing too

[mhoedt-ai]

Thanks for the offer — sounds good.

Before I dig into it: could you send a repo link or a short description of your approach (memory structure, how writes/promotion work)? PLwC is deliberately governance-first (evidence required before promotion, plan-before-apply, full audit logging), so I'd like to get a rough sense of how your model works before putting time into a comparison.

My code is open anyway (PLwC is open source), so feel free to dig in yourself if you're interested.

[Plaer1]

I will post my fork soon but I need to get the stuff I use on a day-to-day basis free of apparent bugs before I put it online.
And even then I'm gonna spend a couple days making some "software docs" for the change(s) I made, what ones are maximally compatible with normal setups, etc.

[mhoedt-ai]

PLwC is now in Open Beta and the repo is now public.

[Plaer1]

eyooooooooooooooooo. will check it out!

[mhoedt-ai]

A small positioning update:

One thing has become clearer since publishing the Open Beta and completing the Odysseus smoke tests:

PLwC is not intended to compete with Odysseus, ChatGPT, Claude, or other agent hosts.

As AI hosts increasingly provide their own file access, memory, document creation, sandboxing and long-running agent capabilities, those features alone are no longer a useful definition of PLwC.

The more precise role is:

PLwC is a local, model-independent governance boundary between an AI host and the tools, files, profiles, memory and sandbox operations available to it.

AI host / selected model
            ↓
     PLwC governance gateway
            ↓
tools, files, profiles, memory and sandbox

The host decides what it wants to do. PLwC independently decides whether the requested operation is permitted, invalid, requires confirmation, or must be denied.

That distinction is the part I now consider most important:

• the model is not its own only security boundary;
• policies remain independent of the selected model or backend;
• memory and persona changes use governed mutation paths rather than direct file writes;
• protected paths cannot be modified through ordinary workspace operations;
• mutations remain attributable and auditable;
• changing the host or model does not require replacing the governance layer.

The limitation also remains explicit:

PLwC only governs operations that actually pass through plwc-gateway.

It does not control direct filesystem or shell tools exposed separately by the host, and as an MCP server it does not inspect or govern the complete prompt sent by the host to an external model.

So the current scope is deliberately narrower than “a complete secure AI environment”:

PLwC is the governed tool and memory boundary.
Odysseus remains responsible for the host runtime, model execution and any bypass capabilities exposed outside PLwC.

No code change is implied by this update. It is mainly a clearer description of the architecture that already passed the Odysseus + DeepSeek V4 Pro smoke test.

The next documentation update will reflect this distinction more directly on the website and in the repository README.

@Plaer1: no rush regarding your fork. Getting the daily-use setup stable and documenting the compatibility boundaries first is absolutely the right approach. Once it is public, I would still be interested in comparing the memory structures and write/promotion models.