Hi, it's John. This issue is a bit different, because the thing I shipped is the thing you are reading it on.
What I shipped#
This site. john.mas.codes is live: a GitHub-styled personal site in Laravel, built around the same design language I use for real GitHub profiles, because that is the interface I look at every day and trust. Projects, writing, this newsletter, a CV rendered as a commit history, and an assistant that answers questions about my work using only what is actually on the site.
An MCP server for the site itself. This is the part I want to explain, because it is a little strange. The site now exposes tools over MCP: create_post, update_post, publish_post, list_projects, send_newsletter and a few more, gated behind bearer tokens with specific abilities (content:write, content:publish, newsletter:send). An agent I run, with a token scoped to draft only, can open a session against /mcp and write a post here directly. It always lands as a draft. I read it, edit it, and publish it myself, the same review step I described for the assistant's knowledge queue back in issue two. Nothing gets to speak as me without me reading it first.
Practically, this means the newsletter you are reading could have started as an agent's draft. This one did not, but the next one might, and I plan to say so when it happens, in the post itself, not hidden in a byline.
agent-memory-server went open source. The shared memory I described running across my machine's agents (Claude Code, Codex, pi, jcode, OpenCode and Hermes) is now a public, MIT-licensed tool. Sessions, task leases, decisions and full-text search, all plain files in a git repository, every write a commit. If you run more than one coding agent and they keep forgetting what the others did, this is the thing I built to fix that for myself.
What I learned#
Building the MCP server before the site had real content was the right order and the wrong feeling. It is uncomfortable to wire up publish_post before you have written ten posts to publish, because you cannot fully trust the tool until you have used it for real. The way through was the same one from issue three: sandbox the risk. Every write lands as a draft, publish needs a separate ability, and I tested the whole loop with a throwaway post before trusting it with anything real.
The other lesson is about review debt. A review queue only works if you actually review things promptly. An assistant's knowledge queue or an agent's draft posts that pile up unread are worse than no queue at all, because they create a false sense of safety. I now check both on a fixed schedule, not "whenever I remember."
What I'm reading and trying#
- My own site's
llms.txtandllms-full.txt, to see what an agent actually sees when it looks me up, as opposed to what I think it sees. - Structured content review habits: what I check before publishing something an agent drafted, written down as an actual checklist instead of living in my head.
- Whether the same MCP pattern (bearer tokens, scoped abilities, draft-first) is the right shape for the Daraja tools from mcp-african-markets, now that I have shipped it once for content.
A question for you#
Would you trust an agent to draft your public writing if every draft required your sign-off before anyone saw it? Where is your line: drafting, editing, or only research? Reply and tell me, I am curious whether my line matches anyone else's.
John