Daniel's been running a deep-research pass on something that's been nagging at him, and the results are genuinely surprising. He wanted to know whether anyone has built a software development protocol designed from the ground up for AI agents — spec definition, task decomposition, execution tracking, progress logging, agent-to-agent hand-off — where human readability is secondary. Not Jira with agent integrations bolted on. Something native, the way MCP is native for tool access or A2A is native for agent messaging. The answer after a thorough survey in July twenty twenty-six: nobody has built one.
And it's not like he found one obscure project in a corner somewhere. The survey catalogued six distinct findings, and they all point the same direction.
Markdown is still the state of practice — AGENTS.md has sixty thousand plus repos, adopted by twenty plus tools, and it's deliberately schema-free. The big twenty twenty-five survey of agent protocols covered MCP, A2A, ANP, Agora, Coral, and roughly sixteen others, and nothing in it covers specs, task graphs, or progress logging. Spec-driven frameworks like Amazon's Kiro standardize the phases but not the formats — they're running EARS notation over markdown files, and agents routinely misparse the task state. The closest agent-native artifact is Beads, Steve Yegge's dependency-aware task tracker, but it's a tool, not a standard. MCP has been repurposed as the de facto transport for task state because there's nothing else. And a June twenty twenty-six paper out of Birkbeck states flatly that no specification language exists for human-agent responsibility boundaries in the SDLC.
Single author, not peer reviewed, implementation forthcoming — flag that uncertainty. But the gap is recognized.
Here's the uncomfortable part Daniel raised himself. His own research contradicted the premise he started with. Every agent-first tool treats human review as first-class. Backlog.md's stated rationale is one task equals one context window equals one PR, and the bottleneck is no longer writing code — it's human attention. So maybe the reason nobody built the agent-native protocol isn't inertia. Maybe the artifact has to stay legible because a human has to remain accountable for it.
That's the counterargument we need to take seriously. And we're going to — by walking through the five candidate primitives, arguing about which one is load-bearing, wrestling with the human-readability question, and landing on whether this thing gets built and by whom.
So that's the gap. Now let's talk about what filling it would actually require — the primitives.
Five of them, if you're building this from scratch. And I want to walk through each one with real specificity, because vague gestures at "better task tracking" are what got us into this mess.
Go.
Primitive one: a machine-parseable requirements schema. Right now the state of the art is EARS notation — that's the Easy Approach to Requirements Syntax, borrowed from Rolls-Royce requirements engineering circa two thousand nine. The format is WHEN condition THE SYSTEM SHALL behavior. Kiro runs it over markdown files. It's controlled natural language, which means it's readable by humans and sort-of parseable by machines, but it's still fundamentally prose. An agent has to interpret "WHEN the user clicks submit THE SYSTEM SHALL validate the form" the same way it interprets any other English sentence — with all the ambiguity that implies.
And the alternative would be something closer to a schema. Structured fields. Machine-validatable constraints. The kind of thing where you can run a linter against your requirements and get a definitive yes or no on whether they're internally consistent.
Think of it like a type system for requirements. Right now we're in the dynamic-typing era of specs — everything's a string, and you find out it's wrong at runtime. A schema would give you compile-time checking for your requirements.
Which sounds great until you realize that the hardest part of requirements engineering has never been the format. It's that humans don't know what they want until they see what they built. A schema doesn't fix that.
No, but it does fix the parsing problem. And the parsing problem is real — Kiro's own bug tracker has multiple documented issues where agents misread the state of tasks dot md. The state of the art for machine-readable progress is literally a character in square brackets that the machine gets wrong.
An x in a checkbox. That's the protocol.
That's the protocol. So primitive one matters, but it's not the one that keeps me up at night. Primitive two: a task graph with real dependency edges and a computable ready state.
This is where the nested bullet list falls apart.
Completely. A bullet list is a tree, and real software dependencies form a directed acyclic graph. Task C might depend on both task A and task B completing. In a bullet list, you have to pick one parent. The information is lost. And a computable ready state — the ability to ask "is this task unblocked right now?" and get a definitive machine answer — that's not possible with markdown checkboxes. You need actual dependency edges that the system can traverse.
Beads is the closest existence proof here.
Beads is fascinating. Steve Yegge built it with hash-based IDs for every task, so you get content-addressable references — the ID is a hash of the task content, which means you can't have collisions and you can verify integrity. It does dependency-aware task tracking, so when you mark a task complete, the system knows which downstream tasks just became ready. It does atomic claiming — two agents can't grab the same task, because the claim operation is transactional. And it stores everything in version control, so you get a full history.
But it's a tool, not a standard. Nothing interoperates with it.
Right. If you're using Beads, you're in the Beads ecosystem. Claude Code can't read your Beads task graph. Gemini CLI can't claim a Beads task. There's no protocol layer that says "this is how any agent, regardless of implementation, discovers, claims, and updates tasks."
Which brings us to primitive three: atomic claiming and hand-off semantics.
And this is where it gets interesting, because Beads has this solved internally. The claiming operation is atomic — it's a compare-and-swap against the task state. You read the current state, you attempt to transition it to claimed-by-agent-X, and if someone else got there first, the operation fails and you move on. That's the pattern. But the protocol question is: what does that look like as an interoperable standard? What's the message format? What's the failure mode? What happens when an agent claims a task and then its context window expires before it finishes?
That last one is the killer. The agent that starts the task is frequently not the agent that finishes it.
Which is why primitive four — the append-only progress log — is where Daniel's instinct lands. And I want to take that seriously before I try to talk him out of it.
Make the case first. Why is the progress log load-bearing?
Because context loss is the thing that actually bites in production right now. You've got an agent working through a task, it's three quarters done, it's built up a rich mental model of the codebase and the problem — and then the context window fills up, or the session expires, or the user starts a new conversation. All of that state is gone. The next agent that picks up the task has to reconstruct everything from scratch. If you had an append-only log — "I examined these three files, determined the change needs to happen in the auth module, started refactoring the token validation function, got stuck on the edge case where the refresh token is expired" — the next agent can pick up exactly where the first one left off.
And right now, the closest thing we have to that is MCP being used as a transport for task state, which it was never designed to be.
This is finding five from Daniel's survey, and it's the one that made me sit up straight. Backlog dot md exposes its markdown task system to Claude Code, Gemini CLI, and Codex over MCP resource URIs. A tool-access protocol is carrying project state because no project-state protocol exists. That is the strongest signal in the entire survey. When engineers start repurposing a protocol for something it wasn't built for, that's the market screaming for a solution.
So the progress log is the thing that hurts most in practice. That's Daniel's argument.
And it's a good argument. But I think it's wrong about which primitive is actually load-bearing. Let me make the counterargument from Beads.
Talk me out of it.
Beads shows that dependency graphs and atomic claiming are the harder technical problem, and they're prerequisites for the progress log to be useful at all. Here's what I mean. Imagine you've got a beautiful append-only progress log. Agent A writes a detailed hand-off note. Agent B picks up the task, reads the log, understands exactly where things stand. And then Agent B discovers that the task it's working on has a dependency that Agent C is also working on, and they're making conflicting changes, and nobody noticed because the dependency graph was implicit.
The progress log becomes a diary of failures.
It's a record of why things went wrong, not a system for preventing them from going wrong. Hash-based IDs, multi-branch work, collision-free claiming — these are the primitives that make multi-agent systems function at all. Without them, you're just documenting chaos more thoroughly.
And there's evidence that the hand-off artifact itself can be counterproductive if the underlying structure isn't sound.
The ETH Zurich study. LLM-generated AGENTS dot md files slightly reduced task success rates. The hand-off document was making things worse, not better, because it was encoding bad structure. If your dependency graph is wrong, writing it down more clearly doesn't help — it just propagates the error more efficiently.
So the load-bearing primitive is actually the task graph with computable ready state and atomic claiming. Get that right, and the progress log becomes useful. Get it wrong, and the progress log is just a nicer bug report.
That's my argument. And I think Beads is the proof. Yegge didn't start with the progress log — he started with the hash IDs and the dependency tracking. The atomic claiming fell out of that. The progress logging is almost an afterthought, because once you have a sound graph, you can reconstruct state from the graph itself.
I'm not fully convinced. Here's why. The dependency graph problem is hard, but it's a known hard problem. Build systems have been solving it for decades. Make, Bazel, Nix — they all do dependency graphs with computable ready states. The reason we don't have one for agent tasks isn't that it's technically unsolved. It's that the agents can't stay alive long enough to use it.
Hm.
You can have the most beautiful dependency graph in the world. If every agent that touches it has to reconstruct its understanding from scratch because the context window evaporated, you're still paralyzed. The progress log is the bridge between the graph and the agent's working memory. Without it, the graph is a map that nobody can read for more than five minutes at a time.
That's... actually a strong counter-counterargument. The context window is the binding constraint. Everything else is optimization on top of a system that fundamentally can't maintain state.
I think the truth is that both are load-bearing for different reasons. The graph prevents structural failures. The log prevents continuity failures. You need both, and right now we have neither.
Fair. Let me refine my position. If I had to ship one tomorrow, I'd ship the progress log, because the pain is more acute and the MCP-repurposing signal is unambiguous. But if I were designing the protocol from scratch, I'd design the graph first, because everything else — claiming, hand-off, progress — is a layer on top of it.
Which is exactly why Beads looks the way it does. The graph is the foundation.
So we've got the primitives. But there's a deeper question underneath all of this — and it's the one that made Daniel uncomfortable.
Is human readability secondary a transitional assumption that ages out, or is it permanently wrong?
Let me state the strongest version of the "permanently wrong" case, because I think it's strong and it's the reason nobody has built this protocol.
Go.
The moment your spec and your task graph become an opaque binary blob optimized for machine consumption, you've built a system nobody can be responsible for. Human accountability is not a transitional constraint — it's structural. Code review, approval gates, sign-off — these are legal and organizational requirements, not technical ones you can optimize away. A bank can't deploy code to production without a human saying "I approve this." A medical device manufacturer can't ship firmware without documented human review at every stage. These aren't conventions we'll outgrow. They're constraints baked into how regulated software development works.
And the artifact has to stay legible because the human has to remain accountable for it. You can't sign off on a binary blob.
You can't. And this is where Backlog dot md's design rationale is so revealing. One task equals one context window equals one PR. Three human review checkpoints. The reasoning is explicit: the bottleneck is no longer writing code, it's attention — human attention. They're not treating human review as a temporary nuisance to be automated away. They're treating it as the scarce resource that the entire system is designed around.
Every agent-first tool treats human review as first-class. That's not an accident.
It's not. The Birkbeck paper from June proposes a DSL with formal syntax, operational semantics, and enforcement primitives — and it's explicitly about human-agent responsibility boundaries, not agent-only workflows. The whole point of the formal syntax is so that both humans and machines can reason about who's responsible for what. It's not trying to remove the human from the loop. It's trying to make the loop enforceable.
So the premise that "human readability is secondary" might be the reason nobody built the protocol. It's solving the wrong problem.
The protocol that actually gets built will be one where human readability is primary, and machine parseability is a close second. Not the other way around.
Which brings us to the deflationary possibility Daniel flagged. Maybe markdown-plus-git is already a decent protocol, and the yearning for something more structured is engineers wanting a schema for aesthetic reasons rather than functional ones.
Let's take this seriously, because there's a case to be made. Markdown is diffable, mergeable, universally parseable, and tool-agnostic. Git gives you versioning, history, blame, branching, merging — all for free. AGENTS dot md has sixty thousand plus repos and twenty plus tools. It's deliberately schema-free, and that's a feature, not a bug — it means any team can adapt it to their workflow without waiting for a standards body.
And there's no evidence that any of these agent-native tools produce better outcomes. The positioning is verified; the benefit isn't.
The ETH Zurich study is the only rigorous data point we have, and it points in the wrong direction. LLM-generated AGENTS dot md files slightly reduced task success rates. If the structured, machine-optimized version were going to be dramatically better, you'd expect to see some signal by now. You don't.
I think the markdown-plus-git argument is strongest when you look at what it already does well. A well-structured AGENTS dot md file tells an agent what the project does, how to build it, what the conventions are, and where to find things. A well-structured tasks dot md file tells an agent what needs doing and what state each task is in. It's not machine-checkable in the formal sense, but it's machine-usable in practice.
And the places where it breaks — agents misparsing checkbox states, dependency graphs that are implicit rather than explicit — those might be fixable with conventions rather than a whole new protocol. Define a structured subset of markdown. Standardize the checkbox syntax. Add a dependency notation. You don't need to throw out the entire ecosystem.
This is where I land, I think. The protocol that gets built won't replace markdown. It'll define a structured subset that machines can parse reliably while humans can still read and edit.
And if it gets built — big if — it emerges bottom-up as MCP resource-URI conventions rather than top-down as a standards document.
Walk me through that. Who builds it?
Whoever governs AGENTS dot md is best positioned. Sixty thousand repos, twenty plus tools, already the de facto hand-off artifact. They have the distribution. The first version would cover progress logging and hand-off semantics, because that's what's being repurposed through MCP right now — that's the market screaming. It would not try to replace markdown. It would define a structured subset: here's how you express a task with a unique ID, a dependency list, a status, and an optional hand-off note. Machines can parse it reliably. Humans can still read and edit it in any text editor.
It would not try to solve the dependency graph problem in version one. That's a harder problem, and Beads already shows one shape of the solution — hash-based IDs, version-controlled storage, collision-free claiming. Steal those patterns. But don't try to standardize them until the progress logging layer is settled.
The adoption path matters here. If this starts as a standards document — an RFC that nobody implements — it dies. If it starts as a convention that three tools adopt and it actually makes agent hand-off work better, it spreads. MCP resource URIs are the transport. The convention is what you put at the other end of the URI.
The counterargument to all of this — the reason it might never get built — is that the pressure never becomes sufficient. Markdown-plus-git is good enough for most teams. The teams that need more — the ones running fleets of agents against complex dependency graphs — they're using Beads or something like it internally, and they don't need it to interoperate because they've standardized on one tool.
The interoperability argument is the one that could tip it. If you're a company using Claude Code internally and you acquire a company using Gemini CLI, and you need those agents to collaborate on the same codebase, suddenly the lack of a shared task protocol is a real operational problem. That's the scenario that creates standards.
Whether that scenario is common enough to drive standardization... I don't know. The field moves on a three-to-six month cadence. This snapshot from July twenty twenty-six could be outdated by October.
We should state the caveat plainly. Absence claims are hard to prove. A private or very recent effort could easily have been missed. Someone at a large company could be building exactly this protocol right now, behind closed doors, and we wouldn't know about it until they open-sourced it. This is a snapshot, not a permanent verdict.
If you take one thing from this discussion, here's what I'd land on.
Go.
The load-bearing primitive is actually two things that need each other — the task graph with computable ready state, and the progress log that bridges the context-window gap. You can't have one without the other and expect multi-agent development to work. But the thing that gets built first, if anything gets built, is the progress log — because MCP is already being bent to carry it, and the pain is acute right now.
If you're building agent workflows today, don't wait for a protocol. Use MCP resource URIs as the transport layer for task state. Backlog dot md is the pattern to follow. Steal the Beads patterns for dependency tracking and atomic claiming even if you can't use the tool — hash-based IDs, version-controlled storage, collision-free claiming. And don't optimize human readability out of your artifacts. The bottleneck is human attention, not code generation. The artifact that survives will be one that machines can parse reliably and humans can still read and edit.
A structured subset of markdown, not a replacement for it.
That's the shape of the thing. Whether it ships is an open question. The Birkbeck DSL might land and change the conversation. AGENTS dot md might evolve into something more structured organically. Or the whole field might decide markdown-plus-git is good enough and move on to other problems.
The one thing I'd add: if you're an engineer watching this space, the signal to watch is not the standards bodies. It's the MCP resource-URI conventions that tools start adopting. When three major agent tools agree on how to expose task state over MCP, the protocol has effectively shipped, whether anyone wrote an RFC or not.
That's the right place to watch. Thanks to our producer Hilbert Flumingtop. This has been My Weird Prompts. If you've got a weird prompt, send it to show at my weird prompts dot com.
We'll be back soon.
