The Anvil, Not the Hammers: Where fakoli-state Goes Next

The views expressed here are my own and do not represent those of any current or former employer.

This week I did something uncomfortable. I pointed a fleet of research agents at my own work and asked them to tell me what I got wrong.

The fakoli stack is three Claude Code plugins I’ve been building since early this year: fakoli-flow orchestrates work through an intent-driven pipeline with critic gates, fakoli-crew provides eight specialist agents, and fakoli-state is a local-first state engine that tracks tasks, claims, and evidence in SQLite. I’ve written about the first two. This post is about the third, because the audit changed my mind about where the value actually lives.

What the audit found

I asked the reviewing agents to compare each piece against the field: Beads, claude-task-master, GitHub’s spec-kit, superpowers, Claude Flow, and Anthropic’s own native features. The honest scorecard:

Things I built that others built first. PRD-to-task parsing shipped in claude-task-master before I wrote mine. A local task graph with ready-work detection is the heart of Beads. A brainstorm-plan-execute pipeline with review gates is superpowers’ whole thesis. None of this was copying. It was parallel invention, the same problems pushing different people toward the same shapes. But I’m done describing those parts as novel, because they aren’t.

The thing that stung. My wave-engine docs say the critic gate “cannot be skipped.” The audit pointed out that nothing enforced that. It was a prompt-level convention: a strongly worded suggestion to a language model. The whole pitch of the critic gate is that discipline should be structural, and mine wasn’t.

So I fixed it. The gate is now enforced by hooks: when a code-writing agent completes, a PreToolUse hook denies dispatch of anything except the critic or the fixer until a review actually happens. A fix re-arms the gate, so fix cycles mechanically require re-review.

And here’s the part worth admitting in public: my first version of that fix had a bug. The hook emitted a JSON shape that current Claude Code versions silently ignore: the gate would have looked enforced while enforcing nothing. An automated reviewer caught it before merge, at the highest severity. The system whose entire purpose is “claims of completion require adversarial verification” had its enforcement layer saved by adversarial verification. I have never felt a lesson land harder.

Things that held up. Three ideas survived contact with the field intact. Evidence-backed completion (where a task can’t reach done without submitted artifacts, enforced by the state machine rather than by prompt) is something almost nobody else ships, and the 2026 consensus on agent verification says it’s the right call. Predictive file-conflict detection at claim time, before any work starts, is ahead of the published practice of “isolate in worktrees and hope.” And lease-based claims with expiry and renewal (so a crashed agent’s work returns to the pool automatically) turn out to be rare outside the biggest fleet experiments.

Why the state layer is the moat

Here’s the uncomfortable strategic read. Anthropic now ships native agent teams with shared task lists, claiming, file locking, and dependency blocking. Dynamic workflows can spin up dozens of parallel subagents with built-in adversarial convergence. The dispatch mechanics I spent months refining in fakoli-flow are becoming platform features, and the platform will improve them faster than I can.

What the platform does not have (and what is structurally hard for a platform feature to have) is durable, project-scoped, evidence-bearing state. Native task lists are ephemeral; they live in a home-directory cache and vanish on cleanup. fakoli-state lives in the repository. The tasks, the claims, the evidence trail, the audit log: they belong to the project, not to a session.

In fakoli-state, the source of truth is an append-only JSONL event log. SQLite is just a projection: you can delete the database and rebuild it byte-for-byte by replaying events. Every claim, every status change, every piece of submitted evidence is an event with an audit trail. That architecture decision, which felt like over-engineering when I made it, is now the foundation for everything that comes next.

So the strategy inverts. fakoli-flow becomes a thin policy layer (the intent-driven plan format, the gate policy, the evidence rules) riding on native orchestration as it matures. fakoli-crew stays as the opinion layer: role discipline, tool restrictions, language conventions. The engineering investment goes into the state engine. The hammers are becoming commodities. The anvil is mine.

What shipped this week

The audit produced changes, not just conclusions.

The critic gate became hook-enforced, as above. Code review got split into two stages (spec compliance first, criterion by criterion, then code quality) because a reviewer that leads with quality can polish its way past a missing requirement. The verification skill gained an adversarial refutation pass: a second verifier whose only job is to break the first verifier’s PASS verdicts, with its own commands. A criterion passes only when both agree.

fakoli-state’s complexity scoring now closes the loop: tasks scoring above a threshold queue for automatic breakdown instead of just sitting in a report, the one idea I took directly from claude-task-master. And the lock contention path got exponential backoff with jitter, because fixed-interval polling starves late arrivals when a whole wave of agents hits the event log at once.

One change is a refusal. The audit initially recommended unifying the CLI and MCP surfaces into a shared dispatch layer; they looked duplicative. A closer reconnaissance showed both were already thin wrappers over the same managers, and the refactor would have added two hundred lines of indirection to save fifty lines of boilerplate. The idea is retired, with the evidence written down next to the decision. Auditing your own roadmap is worth doing precisely because some of your good-sounding ideas don’t survive it.

Where it goes: state that travels with the repo

The next move is the one I’m most excited about, and it comes from taking Beads seriously.

Today, fakoli-state’s event log is local to one machine. Clone the repo somewhere else and the state stays behind. The fix is conceptually simple: commit the event log to git, treat git as the sync and history layer, and let the SQLite projection rebuild anywhere. The log is already the source of truth; this is the architecture finishing the thought it started.

One design decision blocks it. My event IDs are sequence numbers: E000042 means “the forty-second event on this machine.” The moment two branches append independently, they collide. The spec I published this week replaces them with hash-chained IDs: each event’s identity derived from its content and its parent, globally unique without coordination, forming a per-branch chain that forks and merges the way git itself does. Replay becomes order-tolerant and idempotent: merge two branches’ logs, deduplicate by hash, apply in causal order. When two branches claimed the same task, the reconciler resolves it after the merge and records the loser as superseded, keeping the audit trail intact.

Just as important is what I’m not taking from Beads: no versioned-SQL database dependency, no background daemon, no memory-decay machinery. The discipline that kept fakoli-state at one storage technology and zero resident processes is the same discipline that keeps it maintainable by one person with a day job.

The lesson under the lesson

In April I wrote that baara (work, in Mandinka) is the thing the blacksmith does at the anvil. I keep coming back to that image, because this audit sharpened it. The agents are hammers: increasingly powerful, increasingly interchangeable, increasingly someone else’s to improve. What makes the work trustworthy is the anvil: the durable surface that holds its shape between blows, that remembers what was forged and can prove it.

Most of the energy in agent tooling right now goes into the hammers. Smarter orchestration, bigger swarms, cleverer dispatch. The audit convinced me the scarce thing is the other part: boring, durable, evidence-bearing state that survives the session, travels with the repository, and can show its receipts.

That’s where fakoli-state is going. Build the anvil well, and it outlasts every hammer in the shop.