Where the Wave Breaks: The Layer Nobody Wants to Build

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

This is the third and last post in a series. Part 1 traced spec-driven development back to its forty-year-old ancestors. Part 2 walked the 2025–2026 field (Spec Kit, Kiro, Tessl, task-master, BMAD, Agent OS, OpenSpec) and ended on an observation I want to start this one with:

The popular tier of the spec-driven wave is, underneath the ergonomics, stateless prompt-scaffolding. A great document, handed to an agent, and trust. The spec might be durable. The execution is a conversation that ends when the tab closes.

I want to spend this post on the layer that’s missing, because I think it’s the only genuinely hard thing left in this space, and I think the reason almost nobody builds it is that it’s boring, in the specific way that load-bearing infrastructure is always boring.

Three questions a folder of markdown can’t answer

Here’s a test. Take any spec-driven tool and ask it three questions in the middle of a real, multi-agent, multi-day build:

1. Who is working on this task right now, and what happens if they crash?
2. Was this task actually done, or did an agent just say it was done?
3. Three weeks from now, can you prove what was built, by whom, and why it passed?

A markdown spec, even a beautifully anchored one, cannot answer any of these. It wasn’t built to. As I wrote when I first hit this wall: markdown can’t tell you who claimed a task without a human reading the document, and its worst failure mode is that it’s silently overwritable. If your project state is markdown files in a docs/ directory, you don’t have project state. You have project notes that hopefully reflect what’s true.

Those three questions map to three pieces of machinery: durable state, task leasing, and evidence-based verification. Let me take them one at a time, because each one is a place the wave breaks.

Durable state

Not “the spec persists.” The execution persists. There’s a canonical store (for me, a SQLite database that lives in the repository) that knows the status of every task, every claim, every piece of evidence, and survives any session reset, model swap, or crashed agent. The conversation is ephemeral. The state is not.

This is the single biggest gap. In Part 2’s maturity spectrum, even the “spec-anchored” tools anchor the spec while letting the execution state evaporate. The two are different. You can have a perfectly durable spec and still have no idea, after lunch, what your three agents actually did this morning.

Task leasing

The moment you run more than one agent, you need a way for one to say “I’ve got this task” in a way the others are forced to respect. Not a label. Not a convention in a chat. An exclusive lease, with an expiry and a heartbeat, recorded in the canonical store. If the agent holding it crashes, the heartbeat stops, the lease expires, and the task returns to the pool to be picked up by someone else, automatically, with no human untangling it.

I gave fakoli-state claims with both a lease_expires_at and a last_heartbeat_at precisely because markdown doesn’t have them. Honest agents renew their lease every few minutes; crashed work gets reaped fast. That’s not a nice-to-have. That’s the difference between “parallel agents” and “a race condition with good marketing.”

Evidence over claim

This is the one I feel most strongly about. The shortest way to describe what’s broken about “the AI says it’s done” is that it’s a self-report from an actor who has never been audited, and who has been trained to be agreeable. A model fine-tuned to be helpful will tell you it’s done before it’s done, not out of malice, but because “done!” is the helpful-sounding token.

So in my system the agent doesn’t get to narrate the ground truth. A hook captures it (the actual files that changed, the actual command output, the actual test result) at the boundary, as it happens. When the agent submits its work, it cites from that captured buffer; it doesn’t get to invent it. The hook supplied the truth; the agent supplied the curation. A task can’t move to “done” unless the evidence matches the verification contract that was written before the work started.

That’s the layer. Durable state, leases, evidence. Three boring, load-bearing pieces of machinery, and the popular tier of the spec-driven wave has approximately none of them.

I am not the only one who noticed

Here’s the part that convinced me I was right about where the gap is, rather than just talking my own book.

While I was building this, a security firm, Praetorian, published a writeup of an internal platform they’d built for autonomous development. I had never seen their code. They had never seen mine. And we built the same organ.

They open with the thesis I’d have opened with: the bottleneck is “not model intelligence, but context management and architectural determinism.” Then they describe their architecture, and it’s eerie. A dual-state model (ephemeral runtime state plus persistent manifests) so workflows “survive session restarts” and resume from the last checkpoint. Parallel developer agents that coordinate through a lockfile mechanism (.claude/locks/{agent}.lock) to prevent races on shared files. And a hard rule that code “cannot be marked complete until independent Reviewer and Tester agents have passed it.”

Durable state. Task leases. Evidence-based verification. Independently arrived at, by a team solving the same problem from the security side instead of the infrastructure side.

When two teams who’ve never met grow the same three organs in response to the same pressure, that’s not a coincidence and it’s not a fad. That’s the shape of the actual problem showing through. The spec was never the hard part. The state under the spec is the hard part, and the people who go all the way to autonomous, multi-agent, trustworthy execution all end up building it, because there’s no way around it.

Why I got here from a different road

In Part 1 I said I came at this from the infrastructure side, and I want to close the loop on why that mattered.

Spec Kit came out of research into making LLMs more deterministic. That’s the spec road, and it’s a good road. I came out of years of running declarative infrastructure: Terraform, desired state, plan and apply, a canonical state file, drift detected and reported instead of papered over. When I looked at the agentic mess, I didn’t see “how do I steer this model.” I saw “this is desired-state reconciliation with a language model in the loop, and I already know that desired-state reconciliation without a durable state file is a story you tell yourself until the second outage.”

So I built the state file first. The Terraform analogy designed fakoli-state for me, joint for joint: the PRD is the configuration, the database is the state, the work packet is plan, and apply is the commit point where reviewed work, with its evidence attached, transitions to done. Plan before apply. Canonical state separate from derived views. Drift detected, never papered over.

The spec-driven wave inherited the dream from MDA and RDD and Software 2.0. It mostly did not inherit the machinery (the durable, drift-aware state layer) that makes the dream survive contact with a real, parallel, multi-day build. Terraform figured that machinery out twenty years ago. It’s just that the people building spec tools mostly didn’t come from the place where they’d have learned it the hard way.

The hammers and the anvil

I wrote recently that the platforms are starting to ship the dispatch mechanics (agent teams, task lists, file locking) as native features. The hammers are getting better and they’re becoming someone else’s to improve. That’s fine. I don’t want to own the hammers.

What the platforms don’t have, and what is structurally hard for a stateless scaffolder to add without becoming a different product, is durable, repository-scoped, evidence-bearing state that travels with the project and can show its receipts. The spec-driven wave gave the industry the dream. The convergence (Praetorian, fakoli-state, and whoever’s next) is the industry rediscovering that the dream needs an anvil.

Intent as the source of truth was always going to win; it’s a forty-year-old idea and it’s correct. But intent is cheap, and there are now a dozen good tools to capture it. The scarce thing is the surface underneath: the boring, durable, drift-aware state that holds its shape between the blows, remembers what was forged, and can prove it.

The hammers are commodities. The anvil is the work.

This concludes the series. If you want the implementation: Plan, Claim, Apply: Building fakoli-state. If you want the operating model the three plugins add up to: The Fakoli Style.