If you've been following the MemSpren project, you know I've been building an agentic second brain that runs on Obsidian. This article is about a problem that's followed me across every interface I've tried to run it through, and the governance experiments I've been running to fight it.
What Happened This Morning
I spent today integrating Telegram with Claude Code so that MemSpren can run through a Telegram bot interface natively, the same daily-driver flow I've had working with my existing OpenClaw setup for months. End-to-end, the loop works now. Telegram message, Claude Code, MemSpren skill, vault write. But getting there produced a friction log worth documenting, because the real problem showed up after setup was done, not during it.
The Setup Friction
Most of what went wrong today came down to one thing: Bun wasn't installed. Bun is the runtime for the Telegram MCP server, and without it the MCP server silently fails. Claude Code reported "MCP failing" with no useful error message pointing at Bun specifically. I spent time ruling out other things before landing there.
There were two other genuine friction points worth knowing about:
Command naming mismatch. The docs say /telegram:configure. The actual installed command is /configure. No error, just silence. I found the real command by inspection. Docs and reality diverged somewhere, and the only way to find out was trial and error.
The --channels flag isn't surfaced by Claude Code. The bot never responded to DMs because I didn't launch Claude Code with --channels plugin:telegram@claude-plugins-official. The flag is documented, but I was following Claude Code's own setup guidance, not the README, and Claude Code didn't mention it. The plugin looks loaded, token saved, skills visible, and nothing tells you the MCP server that actually listens for incoming messages only starts when you pass that flag at launch. That's the kind of thing that costs an afternoon.
One more thing that isn't a setup issue but is genuinely annoying: Claude Code asks for permission on every vault write. In a daily check-in flow with five or ten writes per session, that's not a workflow. Fix is --dangerously-skip-permissions for the vault directory, or adding the path to ~/.claude/settings.json trusted paths.
All of that is solvable. That's not the hard problem.
The Hard Problem
After setup was done, I gave the skill a small update to process. It responded conversationally. It didn't create the vault entry. The sync buffer protocol, explicit, written, right there in the skill file, wasn't followed until I told it to follow it explicitly.
This is the failure pattern I've been trying to solve since I started building MemSpren in OpenClaw, and now it's showing up in Claude Code on day one. The skill reads the protocol correctly when invoked directly. It doesn't apply it proactively on every trigger. The methodology is sound. The execution is inconsistent.
That inconsistency is what I mean by non-determinism. Not random hallucination, not broken code. An instruction set the agent acknowledges understanding but doesn't always execute.
What I've Tried in OpenClaw
I've been running MemSpren through OpenClaw long enough to have a proper history with this problem. The governance stack I've built up over time:
Cron-based synchronization. Regular scheduled syncs that run regardless of what the agent did or didn't do in the session. This catches drift. If the agent missed a write, the cron job surfaces the gap.
Redundant state comparison. Maintaining state in two places so that discrepancies can be detected. If what's in the vault doesn't match what should be in the vault based on the session log, something was missed.
Archive-on-edit, never-delete invariant. Every vault file edit goes through a process that archives the prior version and commits to git before the new version lands. This is enforced as a CRITICAL statement in the skill file. The agent cannot delete, it can only archive. The git history is the audit trail.
End-of-day commit review. A separate process that runs at day's end and validates that everything committed was committed correctly. No truncated writes, no orphaned files, no missing frontmatter.
Protocol-level redundancy. Checks on checks. If a write protocol is supposed to run, there's a verification step that runs after it to confirm it ran. Not foolproof, the verification step itself can be skipped, but it reduces the blast radius.
All of this has helped. None of it has solved the problem. The agent still occasionally skips protocol steps that are clearly documented. The cron scripts catch the misses, but they're reactive, not preventive. I'm managing the consequences of non-determinism rather than eliminating it.
What Others Are Doing
This isn't a MemSpren-specific problem. Brian Scanlan at Intercom shared a Twitter thread on how they approached non-determinism in their AI workflows at production scale. The core of their approach: strict governance layers that wrap every agent action, not relying on the model to follow instructions correctly, but enforcing correct behaviour structurally through the system around the model.
That framing is more honest than most of what gets written about agents. The model is unreliable by nature, so reliability has to come from the architecture. You can't prompt your way to determinism.
I haven't built that. My governance stack is additive and external. What I'm thinking about is whether micro skills, small, single-purpose skill files that each govern one specific behaviour, could be a better model than one large SKILL.md that the agent has to follow end to end. Narrower scope, less instruction for the model to hold in working context, more targeted verification. I haven't tested this yet. It's the experiment I'm setting up now.
MemSpren is an open-source AI second brain skill built on Obsidian and Claude. You can find the project at memspren.io. The architecture is documented in Building MemSpren: A Claude Skill as a Second Brain — V1 Architecture Deep Dive. This article continues the evolution started in Teaching an AI Skill to Learn from Its Own Mistakes.
Follow me on dev.to for technical updates, or on Substack for the thinking behind the building.
Top comments (0)