Devlog #5: When the Platform Catches Up

In devlogs 1–4 I watched multi-agent setups collapse, consolidate, get rewritten under me, and finally treat the spec as the leverage. This is what happened when I tried to replace everything I built.

Claude 4.6 shipped native Agent Teams. Spawn teammates, send messages, track tasks, shut them down. All built into Claude Code. No MCP servers. No tmux. No external plumbing.

This was Claude 4.6, early 2026. The platform has kept climbing since. The argument below is about what stayed missing while it did.

I've been building this exact thing for months.

So I did what anyone would do. I turned off our stack and ran native teams on a real task. Three agents, a feature branch, a Friday afternoon. The messaging was instant. Zero setup. I felt stupid. I'd been hand-rolling something the framework just shipped.

That lasted about two hours.

I closed the terminal to grab coffee. Came back, reopened Claude Code. Everything was gone. The task list, the agent state, the coordination context. Evaporated. I ran br ready out of habit. My beads were still there. The native work wasn't.

That's when the thesis crystallized.

The plumbing was never the hard part.

What Worked (And Where It Broke)

Credit where it's due. The messaging is genuinely better than what we had. Real peer-to-peer DMs instead of polling a mailbox file. Broadcast with automatic delivery instead of write-and-hope. The shutdown protocol is cleaner than killing tmux panes and hoping nothing was mid-write.

Setup is zero. One environment variable. Our stack requires tmux, an MCP server for Agent Mail, named session management, and a beads directory. Native teams require... nothing.

I spawned three agents on a refactoring task. They picked up work, messaged each other, tracked dependencies. It felt like watching someone rebuild your garage from nicer materials.

Then I needed to validate what they'd done.

There's no validation layer. No /vibe check. The agents declared "complete" and expected me to believe them. If you've followed this series since devlog 1, you know how that ends. It's the "tests passing" lie, except now it's three agents lying in parallel.

I let one agent run overnight. In the morning, it had closed 4 tasks. Two were actually done. One passed a test that verified nothing. One was just... wrong. Wrong with conviction. Cleanly wrong.

That's 50% accuracy with no audit trail. Our stack catches this. Native teams don't even try.

Plumbing vs. Orchestration

The distinction that keeps surviving every rebuild:

Plumbing is how agents talk to each other. Spawn, message, shutdown. Pipes and sockets. Native teams handle this well.

Orchestration is why they talk. What work to assign. When to validate. How to learn from what just happened. When to stop. What to do when an agent gets stuck. How to recover when you close the terminal (or it closes itself).

Native Teams:
  Spawn → Message → Hope → Shutdown

Our Stack:
  Research → Plan → Pre-mortem → Spawn → Wave orchestration
  → Validation contracts → review → preserve → link when relevant

Claude just shipped Docker. The Kubernetes layer is still ours.

A Durable Knowledge Trail: Still Worth Instrumenting

Native teams are a great tutorial zone. Zero setup, instant feedback, you learn the patterns fast. No endgame: no progression system, no XP that persists between runs.

Every native team starts from zero. Spawn agents, do work, session ends, knowledge evaporates. Permadeath. Fresh character, no save file.

Our stack keeps a trail.

In The REPL Is Dead, I reported closed issues, reusable formulas, searchable history. When I start a new task, I search past work first. Devlog 4 made the case for spec versioning: my v1 specs now start at the sophistication level of my old v3s.

The flywheel I use now is simpler to name. A bead preserves the work, decisions, and evidence. If a lesson generalizes, an LLM wiki preserves a reviewed page with links back to that work. A later bead can cite the page. Native teams do not provide that durable bookkeeping by themselves.

I believed that trail was the gap that mattered most. Months later I ran an honest A/B in Devlog #6: treatment with the corpus scored worse than a curated baseline. Practice still worth ~2 minutes. Compounding as a moat: unproven on the evidence I have. The gap that held up under the ruler was verification, not memory.

I've rebuilt the transport layer three times. The learnings file didn't care which messaging system delivered them. It also didn't automatically make the next agent smarter than a good baseline.

The Trust Problem Scales

I expected trust to matter less at scale.

Our stack has a principle baked into the foundation: never trust agent claims. Mandatory verification before marking anything complete. The /vibe check runs automated validation gates. The /pre-mortem simulates failures before you burn implementation cycles.

I thought native teams might not need this, that maybe Claude 4.6 was reliable enough.

It isn't. Not at scale. Not overnight. Not when you're running three agents and can't babysit all of them.

The wave orchestration biases toward forward progress because it has gates. The /crank FIRE loop finds ready work, implements, reports, and evaluates. Native teams are ad-hoc. You spawn agents and they coordinate through good intentions.

Sometimes that works. Usually it doesn't.

I should've known better. Devlog 1 documented this exact failure mode: "18% of tasks needed a second pass. If you're not validating AI output, you're not shipping code. You're shipping hope."

That was true with one agent. It's more true with three.

Try It

Don't take my word for it. Feel the gap yourself.

1. Enable native teams: set CLAUDE_AGENT_TEAMS=1 (the flag as of early 2026; if it's moved, the current docs will say so)
2. Spawn 3 agents on a real task, not a demo, something you care about
3. Let them work for an hour. Watch the messaging. Appreciate the zero-setup.
4. Close the terminal.
5. Reopen it.

Everything's gone. The task list. The agent context. The work assignments.

Now build the simplest persistence layer you can. A JSON file that survives the session. A git-backed issue that remembers what was assigned. Anything that outlasts the terminal.

That's the gap. Once you feel it, you'll understand why the orchestration layer exists.

What's Next

Native teams are real, and they'll get better. Persistence will come. Maybe knowledge management after that. The platform is climbing the stack: single-agent chat, then tool use, then subagents, now teams.

The smart move is hybrid: take the better messaging and zero-setup, layer our orchestration on top. That's what I run now. Native plumbing underneath, our persistence and validation on top.

Last devlog I said the spec is the leverage. That's still true. Specs only help if something independent checks the claim of done. Native teams don't. Not yet.

Devlog #6 answered the open question I'd left here: under honest metrics, the Knowledge Flywheel as moat failed its first A/B. The gatekeeper survived.

The plumbing got absorbed. The orchestration didn't. Verification is what I'd bet on next, not memory-as-moat.

Previous: Devlog #4: Why Your AI Coding Specs Keep Failing.