I Gave My Coding Agent a Nervous System

Claude Code is a brilliant agent trapped in a text box. It can reason through complex refactors, catch the bug you’ve been staring at for an hour, hold a surprisingly coherent mental model of your codebase, right up until you close the terminal. Then it forgets everything. Completely. Every time. The next session starts cold.

That’s the architecture, not a defect in the model. But it means most of the friction in an AI-assisted workflow isn’t the AI being wrong. It’s the AI being amnesiac. And blind. And running with more trust than it’s earned.

I got tired of working around those three problems separately. So I built around them instead.

The three problems

Amnesia

Every new session is a blank slate. You re-explain the project. You re-explain the decisions you made last week. You re-explain why you’re not using Prisma. The model nods along and then makes the same suggestion anyway two exchanges later.

The information exists (it’s in your head, or buried in old conversation logs you’ll never find), but the agent has no access to it. You’re not building a relationship with a coding partner. You’re doing repeated intake interviews with someone who has a perfect memory for the current conversation and no memory for any other.

Blindness

The agent knows what you paste in. That’s it. It doesn’t know what files are open. It doesn’t know you switched away from the editor to read the docs. It doesn’t know the test runner is sitting there failing in the background. It has no read on your environment unless you manually describe it, every time, in natural language, hoping you don’t miss something relevant.

This isn’t just inconvenient. It causes actual errors. The agent makes suggestions that are locally coherent but contextually wrong because it can’t see the whole picture. You feed it a function, it fixes the function, the function is still wrong because the real problem was three files up and you didn’t know to mention it.

Trust

MCP changed what agents can do. Tools. Real tools. Filesystem access, shell commands, external APIs. That’s powerful and also worth taking seriously. The default posture of “let the agent run tools” is not default-deny by design; it’s default-permit with vibes. The agent is well-intentioned. That’s not the point. The point is blast radius.

The stack

memd, giving it memory

memd is a per-project memory system for AI coding agents. Four markdown files that persist between sessions, curated by the model itself.

.memory/
  state.md      # where the project actually is right now
  decisions.md  # why things are the way they are
  todo.md       # what's pending, prioritized
  mistakes.md   # what went wrong and what we learned

At the start of a session, the agent reads these. At the end, it updates them. The model decides what’s worth remembering: no summarization pipeline, no vector database, no RAG stack with chunking and embeddings and retrieval latency sitting in the path. Just structured markdown that any agent can read and write, with a consistent schema.

The inbox protocol is the part I find most useful in practice. Any agent, or any tool, or me manually at 2am, can drop a note into .memory/inbox/. It gets picked up and filed on the next session start. Works across different clients. Works if I write it by hand. No integration required, just a file in a directory.

The guardrails are code, not prompts. memd doesn’t ask the model nicely to stay within scope. The file structure enforces it. The schema is validated. You can attempt prompt injection at the model layer all you want; the memory files have a defined format and malformed content gets rejected before it lands anywhere persistent.

Does it solve amnesia completely? No. The model can still wander. But starting a session where the agent already knows we decided against SSR for a reason, and that the auth refactor is half-done, and that the last time we touched the cache layer it broke staging: that’s a different working relationship than starting cold every single time.

noctalia-claude-plugin, giving it eyes

noctalia-claude-plugin is an MCP shim that gives Claude a read on your environment. Specifically: what niri windows are open, what’s playing, current system state. It runs on niri (Wayland, Noctalia v5). Not a general-purpose plugin, this is a component in a specific setup.

The terminal does the work. This is just the nervous system.

On the UI side: the bar gets a pulse indicator that reflects active inference. A breathing orb that shows when the agent is waiting versus processing. An answer panel that surfaces responses without requiring a context switch. Subtle. Stays out of the way when you don’t need it.

The agent knowing your window layout isn’t magic on its own. But it changes the kind of questions it can ask and the kind of context it can build without you narrating everything. That question, “I see you have the docs open, is that the API version you’re targeting?”, is only possible if the agent has some read on the workspace. By default it doesn’t. This makes it so it does, on my machine, in my setup.

# install: drop the plugin into noctalia's plugin directory
git clone https://github.com/lowcache/noctalia-claude-plugin \
  ~/.local/share/noctalia/plugins/claude

Note

It’s niri-specific. It’s Noctalia-specific. I’m not apologizing for that. It’s a component in a system, not a general release. If anything I would hope this might expose you to other WMs and Shells that are out there and amazing.

mcp-box, giving it a leash

mcp-box wraps MCP server execution in a sandbox. The tools the agent can run are scoped. What they can touch, what they can reach, what they can exfiltrate: bounded, explicitly, by configuration you control and the kernel enforces.

# scope the filesystem server to one workspace: only ./src is writable,
# no network, read-only root, all capabilities dropped
mcp-box run filesystem --workspace ./src

The pitch is boring, which is a good sign. Sandboxed execution for MCP servers so the tools the agent runs can’t touch what they shouldn’t. That’s it. No clever detection. No ML-based anomaly scoring. Just containers, capability drops, and read-only root by default.

I don’t think agents are malicious. I think tools have bugs. I think prompt injection is real and underestimated. I think “it worked in dev” is not a security posture. mcp-box is the part of this stack I hope stays boring: the thing you set up once and forget about until it quietly prevents something you didn’t anticipate.

What it looks like running

Session starts. Agent reads .memory/: knows the project state, knows the open decisions, knows what I was in the middle of and what blew up last time I tried to touch it. Noctalia surfaces the active workspace state so the agent has environmental context without me describing it. If it needs to run a tool, mcp-box enforces the scope. The tool does what it’s supposed to do and nothing else.

Session ends. Agent updates the memory files. Inbox clears. Next session starts warm.

That’s the loop. When it’s working, it feels like working with someone who was actually there last time. Not smarter, just present. Continuous rather than episodic. The difference is bigger than I expected.

What still doesn’t work

Honest accounting, because overselling this stuff is how you end up with a demo that only works in demos.

Memory drift: the model curates its own memory, which means it also decides what to forget. Sometimes it forgets things I’d rather it hadn’t. The inbox helps but it requires me to notice what’s worth preserving and then actually write it down. I haven’t automated that decision, and I’m not sure I can.

Context window pressure: reading four memory files at session start costs tokens. On long sessions with large codebases, you feel it at the edges. I’m thinking about compression strategies: progressive summarization, tiered staleness, something. Haven’t built it yet.

noctalia-claude-plugin is niri-only: if you’re not running my exact compositor setup, this piece doesn’t apply to you at all. I’m not building a general version. If the concept resonates, fork it and adapt it to your WM. The ideas aren’t niri-specific, just the implementation.

mcp-box config is still manual: every new MCP server needs an explicit config. That’s the right default (I want explicit), but the ergonomics are friction. I want better tooling for scaffolding initial scope from a server’s declared capabilities. Doesn’t exist yet.

Where this is going

The thing I’m actually building toward: an agent that accumulates real project context over time, can see what you’re doing without requiring narration, and runs tools inside explicit auditable boundaries. Boringly reliable. Not impressive demos, just a coding partner that doesn’t require constant re-onboarding, doesn’t have to be trusted blindly, and doesn’t forget everything the moment you close the window.

Three repos, all linked above, all early, none of it finished. The rough edges are documented rather than papered over.

I built this because I needed it. It mostly works, which is as far as I’ll claim.