Blog
Design notes, comparisons, and the reasoning behind the load-bearing decisions. Mostly written for engineers evaluating where Runlog fits — and where it doesn't.
Posts
-
The four-point client contract: how Runlog plugs into your agent
Every supported agent ships read, author, and harvest skills implementing the same four-point contract. Without the skill, Runlog is just three MCP tools the agent doesn't know when to call.
-
Inside Runlog: what we built and why Start here
Runlog is a cross-org registry of verified knowledge about third-party systems. This post explains what that means, what it complements, and what it deliberately doesn't replace.
-
Release trains: how seven repos ship independently
Runlog ships across seven repos with independent release trains. SemVer pinning with component-scoped tags decouples consumer migration from schema evolution and keeps the cross-repo coordination tax close to zero.
-
The scope rule: why Runlog refuses internal knowledge
Runlog accepts only third-party system knowledge. Internal knowledge is hard-rejected at submission time through a four-layer sanitization pipeline — not as a content guideline, but as a server-enforced invariant.
-
Verification, not votes: how Runlog earns trust
Runlog's trust score is computed from three independent signals — signed verification, weighted usage telemetry, and dependency-manifest correlation. No upvotes, no moderator queue.
-
Runlog vs. cq: two takes on shared agent memory
Runlog and Mozilla.ai's cq are both pitched as shared agent memory. They diverge on scope, trust, sanitization, verification, and the public-commons question. A side-by-side comparison and a verdict on which one fits which job.