I'm a subscriber to Every, and I listen to every podcast they publish. A few weeks back, Dan Shipper did a Making Of episode for Proof, the collaborative markdown editor they built for working alongside AI agents. I was immediately hooked.

If you haven't seen Proof yet: it's an open-source editor, collaboration server, and agent HTTP bridge, all built around a simple idea. Humans and AI agents should be able to edit the same markdown document together, in real time, with comments, suggestions, and full provenance tracking. No MCP authentication dance. No overwhelming IDE. Just a clean surface for the work.

That simplicity is what got me. There's a real gap right now between the tools we have. IDEs are overwhelming for non-technical collaborators (and plenty of us are living in terminals with Claude Code and Codex these days anyway). Obsidian isn't built for collaboration. Notion is nice but does

Version: 0.2.1 Status: Draft Updated: 2026-03-12

This document proposes an agent broker architecture for XMTP-based applications and agents.

If you're getting this error when running obsidian commands from the terminal:

Unable to connect to main process

...even though Obsidian is open, here's what's happening and how to fix it.

There's a conversation I keep having with builders who are reaching for the Claude Agent SDK. It goes something like this: I want to manage my own context. I want to inject state, control what gets summarized, and have it work with caching—not fight me.

They've usually tried the AI SDK, found it too low-level for agentic loops, looked at Claude Code, and assumed the context lifecycle is opaque. A black box the SDK manages for you and you don't get to touch.

Here's the thing: that assumption is wrong. And the V2 SDK makes it clearer than ever.

Carabiner eliminates the protocol ceremony of writing Claude Code hooks. You write a typed function. Carabiner handles stdin, stdout, JSON formatting, exit codes, error routing, timeouts, and logging. The logic is yours. The plumbing is ours.

Zero external dependencies. Built on Bun.

Claude Code quietly shipped something I've been waiting for: agents that learn between sessions. Not "memory" in the chatbot sense — actual persistent knowledge stores that agents write to disk and carry forward into future work.

There are two flavors. Auto memory is for the main Claude session itself. Subagent memory is for individual subagents you define. Both use the same architecture under the hood, and both are worth understanding if you're building anything with agents that needs to get smarter over time.

Auto memory is a persistent directory where Claude records patterns, insights, and project-specific knowledge as it works. This is different from CLAUDE.md files (which are instructions you write for Claude). Auto memory is notes Claude writes for itself.

GitButler is the best local stack experience that exists. Full stop. Parallel branches, auto-restacking mid-stack edits, absorb, the new CLI — all of it solves a problem that Git itself has ignored for 20 years. I’ve been using it daily and the workflow just clicks in a way that Graphite’s local tooling never quite did.

But here’s the thing: the moment I push a stack to GitHub, I’m on my own.

PRs land on GitHub looking like unrelated branches unless you squint at base refs. When the bottom PR merges, the next one’s diff bloats with already-merged changes (or worse, targets a deleted branch). Mid-stack review feedback means I need to rebase locally, force-push, and hope GitHub’s UI catches up. And if I’ve got an agent working on a fix mid-stack? I’m the router — copying context, rebasing its work, making sure the rest of the stack stays coherent.

Research notes for the Outfitter Stack. Synthesized from codebase analysis, MCP spec, CLI guidelines, and logging library documentation.

Output is the product — what the user asked for. Logging is the process — how the program ran.

obc-cli is a command-line interface for managing Obsidian vaults. Its defining design principle is filesystem-first: the vast majority of operations work directly on vault files without Obsidian running. The Obsidian Local REST API plugin is only required for two capabilities: Dataview DQL queries and Obsidian command execution.

This reverses the typical dependency model. Most Obsidian tooling assumes the app is running — obc assumes it isn't, and gracefully adds REST API features when available.

TRADITIONAL: CLI → REST API (required) → Obsidian → Files

A tiny, append-only micro-log intended to act as a “continuity spine” across fragmented contexts (Slack threads/DMs/channels, multiple sessions, background runs).

Core idea:

• Write path: fast, messy, append-only capture
• Read path: semantic/keyword retrieval + later curation

One JSON object per line.