ArielTM

A different axis that holds up: a tiny always-loaded index pointing at per-fact files that load on demand. Claude Code's auto-memory uses this. The part that does the work isn't the lookup, it's the index itself acting as a filter. Every new fact has to summarize into one line that earns its keep, or it doesn't get saved. Stuff that misses the bar either gets rediscovered during work or wasn't load-bearing. 52% Recall@5 from forgetting is a real research win, but the production lever has been bounding the always-loaded set, not scoring what to forget

Orchestration harnesses get eaten. Markdown ones don't. A CLAUDE.md, an evals script, a lessons-learned.md per repo. Smarter models just get more out of them. The bet that hurts is the hand-rolled AutoGen graph.

The browser analogy holds because publishers wanted browsers. Sites lived with User-Agent and robots.txt because the click paid for it.

AI agents are the destination. No return click to bargain with. That's why Cloudflare just went default-block + 402 Payment Required instead of waiting on a standards body.

Open standards on the agent side are the easy half. Getting sites to show up is the part W3C can't fix alone.

The architecturally distinct bit is that you're validating at the service-action layer (send-email, merge-PR, transfer-funds) instead of at the tool-call layer inside whichever agent's running. A permission hook in Claude Code is only as trustworthy as the Claude Code process itself, and it doesn't carry over if you swap in a different agent next week. PS sits one layer up with stable, cross-agent semantics, and it's the thing that actually holds the OAuth tokens, so the agent can't leak them even if it wanted to.

Push-to-approve on a separate device is also the right channel, since the whole point is that you don't trust whatever just asked.

Curious: are the per-service schemas hand-written or generated from each provider's OpenAPI?

kqueue/FSEvents is tempting here, but Darwin drops same-process notifications. If you've got a publisher and listener in the same process the listener just never fires. Nasty thing to chase. stat polling looks gross but it's the only thing that actually works everywhere.

What happens on WAL checkpoint? When the file shrinks back, does that trigger a wakeup, or does the poller filter size drops?

The worktree part is the easy half. Running parallel Claude Code subagents, the bottleneck is never "can they run without stomping each other's files." That's solved the moment each one has its own checkout.

The hard problem is architectural consistency. Agent A renames a type to X. Agent B, in a different worktree, independently renames the same type to Y because neither saw the other's decision. When you merge, neither worktree is "wrong" but the code is incoherent. You need either a shared decision log that every agent reads before starting, or an orchestrator that hands out scope narrow enough that no two agents can collide.

Zed's post is solving filesystem-level parallelism. The harder coordination problem is semantic, and that's where time savings from parallelization go to die.