I maintain Fulcrum — a local-first agent control plane for coordinating multi-agent coding work. There are dozens of agent frameworks on the market in 2026. The question “why another one?” deserves an honest answer, and here it is: none of the others did the boring operational parts that make the model actually usable at 3,400 commits a year.

What Fulcrum actually is

Fulcrum is a small TypeScript runtime that exposes, via an MCP server and a CLI, a handful of primitives that any coding agent (Claude Code, Codex, Gemini, Cursor, any MCP-speaker) can hit:

  • Task tracking — start/update/complete a unit of work, with WIP limits and blocker tracking.
  • Hybrid memory recall — an FTS5 + vector + optional graph store with supersession and confidence tracking, so agents can accumulate durable context across sessions without re-summarising every time.
  • Chief-of-Staff context — a world-state snapshot that other agents can consume as a “here is what’s happening across the workspace” brief, rather than re-discovering state per-session.
  • Agent-run lifecycle — register, heartbeat, block, complete. An idle-but-unfinished run surfaces in the CLI instead of disappearing.

Everything persists locally. There is no hosted component, no telemetry by default, no vendor lock. It runs on the same machine as your editor and your agents.

The space it’s solving for

Most agent frameworks on the market in 2026 are optimized for one of two shapes:

Shape A: The cloud-hosted orchestrator. LangChain-hosted, LlamaIndex-hosted, the vendor-specific ones. Their primitives assume you’re okay with your agent’s task state living on someone else’s machine and their billing plan applying to every step.

Shape B: The in-editor runtime. The built-in agent in Claude Code, Cursor, etc. Their primitives assume you’re working in one editor at a time with one agent at a time, ephemerally, and that anything durable is the user’s problem.

Both of those shapes fail when you’re doing what I do: many agents in rotation across multiple engagements, with real context that needs to persist across sessions, and an engineering discipline that depends on task tracking the agents can see.

Fulcrum lives in the third shape: local-first, multi-agent, agent-visible. The agents can query the task list and the memory directly; the state belongs to you, not the vendor; and the operational primitives (WIP, blockers, heartbeats) are first-class.

Design choices that matter

A few decisions that I’d defend in a review:

1. Agents get read access, humans get write access

By default, agents can read everything and write very little. An agent can record progress on a task it owns; it can write to the memory layer; it can heartbeat. It cannot reassign tasks to other agents. It cannot escalate permissions. It cannot invoke teams. The human (me, or the operator) does that.

This is the same “read liberally, write carefully” posture you’d give a junior engineer. It’s also the posture that keeps multi-agent runs from turning into a Hobbesian state where everyone reassigns everyone’s work to themselves.

2. Memory is tiered, not flat

The memory layer has three tiers: L0 (raw dumps, immutable, zero truncation), L1 (curated wiki-style pages, with confidence and retention, edited by a curator agent), L2 (vectors over L1). Recall goes through L1 with L0 back-refs, so agents can follow any claim to its raw source.

This architecture is not novel (the MemGPT and related lineage inspired a lot of it), but it’s implemented in a way that makes the provenance trail cheap to follow. When Fulcrum tells an agent something, the agent can ask “where did this come from?” and get an answer.

3. Role boundaries are enforced, not suggested

Fulcrum has a notion of agent roles (engineer, tester, reviewer, chief-of-staff, etc.). Only chief_of_staff can invoke teams. Only role-appropriate agents can claim certain tasks. These aren’t conventions — they’re checked at the MCP layer. If a software_engineer agent tries to invoke a team, it gets an error.

The reason to bake this in: without it, agent workflows rapidly collapse into “everyone does everything,” which is exactly the pathology multi-agent is supposed to avoid.

4. It works offline

No network calls required for core operations. The whole thing runs against local SQLite, local vault markdown files, and local embeddings. If the homelab’s internet goes out, Fulcrum keeps working, and so do the agents pointed at it.

What it’s not

To set expectations:

  • It is not a frontier agent framework. It doesn’t try to be a model. It’s a control plane that sits next to whatever agent you already run.
  • It is not a managed product. There’s no hosted version. You clone the repo, you run it, you own the data.
  • It is not battle-tested at scale. It’s battle-tested on my scale — multiple agents, years of session history, real engagements. It will surface rough edges when someone else runs it on their scale. That’s why it’s OSS.

The “why bother” answer

The honest answer to “why write this when X exists” is: I wrote it because using X was costing me 20 minutes per session in overhead, and Fulcrum costs me 30 seconds. Multi-agent, multi-engagement work has fixed overheads that compound fast. Either you pay them or you invest once in a tool that makes them go away. I invested once.

If you’re doing similar work — multiple agents, durable context, real task discipline — try Fulcrum. If you’re doing one-agent, one- session, ephemeral work, you don’t need it. That’s fine. It’s not trying to be everything.

The pattern generalises

The thing I’m most proud of in Fulcrum is not the code. It’s the pattern: local-first, agent-visible, multi-agent, persistent. That pattern is going to eat a lot of the hosted-orchestrator market in the next two years. The teams building on top of vendor-locked orchestrators are going to wake up wanting this shape and not having it. I’d rather be on the side of the people building the shape than the side waiting for someone else to.

Also: my commit graph in the past year is mostly Fulcrum and the site you’re reading this on. If you want to know what between-seats Mo does with his time, that’s the answer. Unemployment has never shipped so many commits.