agent-memory-server
PublicSelf-hosted, git-backed memory any AI agent can plug into
Hi, I'm John. I build AI agents that do real work.
Full-stack engineer in Nairobi. Laravel, TypeScript and Python, with agents that call real tools and tests that prove they recover.
Tool-calling agents wired into real systems, with memory, human approval for anything irreversible, and evals before they ship.
Memory servers, parallel worktree orchestration, chaos tests and scheduled jobs: the plumbing that makes agents reliable.
HR, hiring and marketplace platforms in Laravel, Next.js and React Native, with tests, CI and deployment from day one.
M-Pesa Daraja payments, callbacks and reconciliation, exposed to agents through MCP servers.
Self-hosted, git-backed memory any AI agent can plug into
Parallel coding agents in isolated git worktrees, merged deterministically
MCP servers for African fintech: M-Pesa payments, reconciliation, sandbox by default
Chaos testing for AI agents: inject failing tools, grade the recovery
An AI coding agent that lives inside VS Code
A work and gig-economy platform connecting talent to opportunity
Busiest day: 489 on Sep 29
This site speaks MCP
My agents draft articles and newsletter issues here through a Model Context Protocol server. I review, then publish.
$ claude mcp add --transport http portfolio \
https://john.muthee.mutexai.net/mcp \
--header "Authorization: Bearer jm_..."
# then, in a session
> draft this week's build notes from my commits
create_post(type: "newsletter", status: "draft")
โ Draft saved for review
How I work with agents
I run several coding agents that share one durable memory made of markdown, JSON and git commits. Here is why plain files beat a vector store, and how sessions, leases and decisions work.
A short note on a naming habit from the mutexai.net assistant. Read-only tools get plain verbs. Anything that writes gets a verb that says so, on purpose, so a reviewer never has to guess.
Three agents on one checkout means trampled files and lost work. Giving each task its own git worktree, its own model and a deterministic merge step fixed that for me.
Happy-path demos tell you nothing about what an agent does when a tool returns a 500. I test agents like distributed systems: inject faults on purpose and score recovery against bluffing.
Clone, install, run the tests, then separate real regressions from environmental noise. Why I built repo-doctor as a deterministic pipeline first and an agent second.
A short email about building agents and the systems around them. No hype, no tracking pixels.
Latest: Build notes #4: this portfolio is live, and I can no longer write my own posts