私はFulcrumを管理している — マルチエージェントのコーディング作業を 調整するための、ローカルファーストなエージェントコントロールプレーンだ。2026年、 エージェントフレームワークは数十存在する。「なぜまた別のものを？」という問いは 正直な答えを受け取るべきで、それがこれだ：他のどれも、年間3,400コミットで モデルを実際に使えるものにする退屈な運用部分を実装していなかった。

Fulcrum が実際に何であるか

Fulcrum は小さな TypeScript ランタイムで、MCP サーバーと CLI を通じて、 任意のコーディングエージェント（Claude Code、Codex、Gemini、Cursor、 MCP対応の何でも）が使えるいくつかのプリミティブを公開する：

  • タスクトラッキング — 作業の単位を開始/更新/完了し、WIP制限と ブロッカートラッキングを持つ。
  • ハイブリッドメモリリコール — FTS5 + ベクター + オプショナルなグラフ ストアで、スーパーセッションと信頼度追跡付き。エージェントが毎回要約し 直すことなくセッションをまたいで永続的なコンテキストを蓄積できる。
  • チーフオブスタッフコンテキスト — ワークスペース全体の状態スナップショット で、他のエージェントが「今ワークスペースで何が起きているか」のブリーフとして 消費できる。セッションごとに再発見しなくていい。
  • エージェントラン ライフサイクル — 登録、ハートビート、ブロック、完了。 アイドルだが未完了のランはCLIに表示される。消えない。

すべてローカルに永続化される。ホストされたコンポーネントはない、デフォルトで テレメトリなし、ベンダーロックインなし。エディタとエージェントと同じマシンで動く。

どのスペースを解決しているか

2026年のエージェントフレームワーク市場のほとんどは、二つの形の一つに 最適化されている：

形A：クラウドホスト型オーケストレーター。 LangChain、LlamaIndex、 ベンダー固有のもの。そのプリミティブは、エージェントのタスク状態が他人の マシンとその課金プランに乗ることを前提としている。

形B：エディタ内ランタイム。 Claude Code、Cursorなどの内蔵エージェント。 そのプリミティブは、一度に一つのエディタで一つのエージェントが、一時的に 作業することを前提とし、永続的なものはユーザーの問題とする。

これらの形はどちらも、私がやっていることには合わない：複数のエンゲージメントに またがってローテーションする多数のエージェント、セッションをまたいで持続する 必要のある本物のコンテキスト、エージェントが見られるタスクトラッキングに 依存するエンジニアリング規律。

Fulcrum は第三の形に住む：ローカルファースト、マルチエージェント、 エージェント可視。 エージェントはタスクリストとメモリを直接クエリできる。 状態はベンダーではなく君のもの。そして運用プリミティブ（WIP、ブロッカー、 ハートビート）はファーストクラスだ。

重要な設計上の選択

レビューで守れるいくつかの決定：

1. エージェントは読み取りアクセスを得て、人間は書き込みアクセスを得る

デフォルトで、エージェントはすべてを読み、ほとんど書かない。エージェントは 自分が所有するタスクの進捗を記録できる。メモリ層に書き込める。ハートビートを 打てる。他のエージェントにタスクを再割り当てすることはできない。権限を昇格する ことはできない。チームを起動することはできない。それは人間（私やオペレーター）がやる。

これはジュニアエンジニアに与える「広く読み、慎重に書く」姿勢と同じだ。マルチ エージェントランが全員が全員の作業を自分に再割り当てするホッブズ的状態に なるのを防ぐ姿勢でもある。

2. メモリは階層化されていて、フラットではない

メモリ層には三つの階層がある：L0（生のダンプ、不変、切り詰めなし）、L1 （キュレーターエージェントが編集する、信頼度と保持付きのウィキスタイルページ）、 L2（L1上のベクター）。リコールはL0のバックリファレンス付きのL1を経由するので、 エージェントは任意のクレームを生のソースまで追うことができる。

このアーキテクチャは新しくない（MemGPTと関連する系譜がかなりのインスピレーション を与えた）が、出所のトレイルを安価に追えるように実装されている。Fulcrum が エージェントに何かを伝えるとき、エージェントは「これはどこから来たのか？」と 聞いて答えを得られる。

3. ロール境界は提案ではなく、強制される

Fulcrum にはエージェントロールの概念がある（エンジニア、テスター、レビュアー、 チーフオブスタッフなど）。chief_of_staff だけがチームを起動できる。ロールに 適したエージェントだけが特定のタスクをクレームできる。これらは慣習ではなく — MCP 層でチェックされる。software_engineer エージェントがチームを起動しようとすると、 エラーになる。

これを組み込む理由：なければ、エージェントのワークフローはすぐに「全員が すべてをやる」に崩壊する。それはまさにマルチエージェントが避けるべき病理だ。

4. オフラインで動く

コア操作にネットワーク呼び出しは不要だ。すべてがローカルのSQLite、ローカルの vault markdownファイル、ローカルの埋め込みに対して動く。ホームラボのインターネット が落ちても、Fulcrum は動き続け、それに向いているエージェントも動き続ける。

何でないか

期待を設定するために：

  • フロンティアエージェントフレームワークではない。 モデルになろうとしていない。 君がすでに動かしているエージェントの隣に座るコントロールプレーンだ。
  • マネージドプロダクトではない。 ホストされたバージョンはない。リポジトリを クローンして、動かして、データを所有する。
  • スケールでのバトルテスト済みではない。 私のスケールではバトルテスト済みだ — 複数のエージェント、年単位のセッション履歴、実際のエンゲージメント。他の 誰かが彼らのスケールで動かすときに荒削りなエッジが出るだろう。だからOSSだ。

「なぜやるのか」の答え

「Xが存在するのになぜこれを書いたのか」への正直な答えは：Xを使うとセッションごとに 20分のオーバーヘッドがかかっていたが、Fulcrum は30秒だから書いた。 マルチ エージェント、マルチエンゲージメントの作業には固定オーバーヘッドがあり、 高速で複合する。払い続けるか、消し去るツールに一度投資するかだ。私は一度 投資した。

似た作業をしているなら — 複数エージェント、永続的なコンテキスト、本物の タスク規律 — Fulcrum を試せ。一エージェント、一セッション、一時的な作業なら 必要ない。それで構わない。何でもになろうとしていない。

パターンは一般化する

Fulcrum で私が最も誇らしいのはコードではない。パターンだ：ローカルファースト、 エージェント可視、マルチエージェント、永続的。このパターンは今後二年でホスト型 オーケストレーター市場の多くを食っていくだろう。ベンダーロックインされた オーケストレーターの上に構築しているチームは、この形を求めて目覚め、持って いないことに気づく。私はその形を構築している人々の側にいたい。

また：過去一年のコミットグラフはほとんどFulcrumとこのサイトだ。席と席の間の Moが時間を何に使っているかを知りたければ、それが答えだ。無職がこれほどの コミットを出荷したことはない。