2026.08.22The Agent Runtime Problem: Four Things a while-Loop Doesn't Give You15 min read What a runtime owns that a framework does not Four quadrants, each naming a problem an agent runtime has to own. One, durable state: a crash between the tool and the push, answered by two commits around one uncertain call. Two, session ownership: the terminal dies with the agent, answered by a daemon that reports working or blocked. Three, the orchestration loop: the author reviews its own diff, answered by splitting the context window rather than the model. Four, identity and money: no name to present and no way to pay, answered by HTTP 402 plus a delegation boundary. The four are independent, and no project has all four. What a runtime owns that a framework does not four independent problems — no project on this list has all four 1. durable state crash between the tool and the push→ two commits per uncertain effect 2. session ownership the terminal dies with the agent→ a daemon that owns the session 3. the orchestration loop the author reviews its own diff→ split the context, not the model 4. identity and money no name to present, no way to pay→ HTTP 402 plus a delegation boundary a framework gives you a while-loop and tool plumbing a runtime owns what survives the process
2026.08.17X's Phoenix Ranker: A Transformer That Cannot See Its Own Batch33 min read One sequence, three regions Three stacked bands, one per region of the Phoenix ranking model's input sequence. First, the user prefix at positions 0 to 1: two hashed identifier lookups and two hashed IP lookups, plus country, language, latitude and longitude, gender, age and installed apps; it attends to the user prefix and the history. Second, the history at positions 2 to 1023: post hashes, author hashes, semantic ID, the action taken, dwell time, timezone, local hour, product surface and post age; it attends to the user prefix and the history, bidirectionally rather than causally. Third, the candidates at positions 1024 to 1087: post hashes, author hashes, semantic ID and context, but no action and no dwell, because those are what the model predicts; a candidate attends to the user prefix, the history and itself, and nothing else. Right-anchored rotary position embedding puts the newest history event at position 1023 whatever the history length, and every candidate receives position 1024. A candidate's score therefore depends on the viewer and that candidate only, never on which other candidates share its batch. One sequence, three regions the Phoenix ranker reads 1088 positions in a single non-causal pass user — positions 0…1 two hashed id lookups, two hashed IP lookupscountry · language · lat/lon · gender · age · installed appsattends to: user + history history — positions 2…1023 post hashes · author hashes · semantic ID · action takendwell time · timezone · local hour · surface · post ageattends to: user + history — bidirectional, not causal candidates — positions 1024…1087 post hashes · author hashes · semantic ID · contextno action, no dwell — those are what the model predictsattends to: user + history + itself, and nothing else right-anchored RoPE puts the newest history event at 1023 whatever the history length every candidate gets position 1024 a candidate score depends on the viewer and that candidate alone never on which candidates share its batch
2026.08.11Pi's Durable AgentHarness: An Agent Loop That Survives kill -918 min read Three stores, one invariant Three stacked bands, one per durable store in a Pi AgentHarness session. First, entries — the conversation itself: messages, compaction summaries and branch summaries, written once, never edited or deleted, belonging to no lane. Second, registers — current mutable state: the lane leaf, the lane configuration, operation metadata and the total operation state, plus facts; a register is overwritten or deleted and keeps no write history, and the operation-state register is the program counter recovery reads. Third, the usage ledger — one append-only row per settled attempt, never edited or deleted, never in the tree. All three share one monotonic sequence number. A transaction is the only write primitive. Recovery reads the operation-state register; it does not replay a journal or infer state from what is missing. Three stores, one invariant every durable payload is an entry, a register, or a ledger row entries — the conversation messages, compaction summaries, branch summarieswrite-once · never edited · never deleted · belongs to no lane registers — current mutable state lane.leaf · lane.config · op.meta · op.state · factsoverwrite or delete · no write history · this is the program counter usage ledger — cost history one row per settled attempt · token and cost eventsappend-only · never edited · never deleted · not in the tree all three share one monotonic seq — a transaction is the only write primitive recovery reads op.state; it does not replay a journal or infer from what is missing
2026.08.07Bun's Zig→Rust Rewrite in 11 Days: The Loop, Not the 64 Claudes23 min read Bun’s port loop: split the context window A four-stage loop running top to bottom. At the top, the binding spec: PORTING.md and LIFETIMES.tsv, holding the Zig-to-Rust pattern rules and a proposed lifetime for every struct field in the codebase. It binds all four stages below it. Next, one implementer, which sees the Zig source, the spec, and its own reasoning, and writes the port. Its diff — and nothing else — goes to two adversarial reviewers, each instructed to assume the code is wrong; neither sees the implementer's reasoning. Their findings go to one fixer, which applies every finding before the code lands. Sixteen such loops ran per git worktree across four worktrees, roughly sixty-four Claude instances at peak, and the same loop shape drove all three phases: translating 1,448 files, clearing about 16,000 compiler errors, and fixing every failing test. Bun’s port loop: split the context window the reviewer gets the diff and nothing else — never the implementer’s reasoning binds all four diff only findings PORTING.md + LIFETIMES.tsv the binding spec · Zig→Rust patterns, a lifetime per struct field 1 implementer sees the Zig source, the spec, and its own reasoning adversarial reviewer adversarial reviewer 1 fixer applies every finding — only then does the code land sees the diff only · instructed to assume the code is wrong 16 loops per worktree · 4 git worktrees · ~64 Claudes at peak the same loop drove all three phases: translation, compiler errors, failing tests
2026.08.07herdr Joins Y Combinator: A Rust Agent Runtime, Not Another tmux14 min read herdr: the agent runtime Three layers. On top, clients: Claude Code, Codex, opencode and a human. Each attaches to the herdr daemon. The daemon owns every terminal session, persists agent state, and is reachable from anywhere through the bundled TUI (herdr --remote self-installs in seconds). Below, the sessions it spawns, one per agent, marked working, blocked or idle, each surviving agent restarts. A terminal pane belongs to an agent; a pane belongs to a tab; tabs belong to a project. herdr: the agent runtime agents attach to a daemon that owns every session and tracks its state attach spawns · owns Claude Code Codex opencode Human herdr daemon owns every session · persists agent state terminal session terminal session terminal session working blocked idle state detected per pane · sessions survive agent restart a terminal pane belongs to an agent · a pane belongs to a tab tabs belong to a project · run them anywhere, keep them running herdr --remote self-installs in seconds
2026.08.05Cloudflare Wallets and cloudflare.pay: Identity and Payments for AI Agents18 min read Cloudflare Wallets delegation tree Four layers of authority. A human account owner funds an Account Wallet holding the stablecoin balance. The Account Wallet delegates capped authority to three Virtual Wallets, each carrying its own weekly budget, per-call ceiling and merchant allowlist. Each Virtual Wallet issues an API key to one agent, which spends without per-transaction human approval. No agent can exceed the limits set above it. Delegated spending authority who is allowed to spend what funds · sets the ceiling delegates capped authority API key Human account owner a Cloudflare account, not a keypair Account Wallet stablecoin balance · on-ramp / off-ramp Virtual Wallet Virtual Wallet Virtual Wallet research agent ETL agent reader agent inference · $100 / wk max $2 per call data feeds · $20 / wk allowlist: 4 hosts web content · $5 / wk allowlist: 12 hosts research.acme etl.acme reader.acme no human approval per call · every child is bounded by its parent handles resolve under <name>.cloudflare.pay
2026.08.05x402 Native Payments: HTTP 402 Protocol for AI Agents20 min read x402 UML sequence diagram Twelve numbered steps across four lifelines. Solid arrows are requests, dashed arrows are responses, and self-messages are local work. An alt fragment splits the flow after verification: the invalid branch returns another 402 and stops, the valid branch settles the payment on-chain and returns the resource. x402 payment sequence solid = request · dashed = response · self-message = local work Client Resource Server Facilitator Blockchain alt [invalid] [valid] discover authorize verify settle & respond 1 · GET /weather 2 · 402 Payment Required PAYMENT-REQUIREDprice · tokennetwork · payTo 3 · Sign authorization EIP-3009 · signed locally 4 · Retry + signature PAYMENT-SIGNATURE 5 · POST /verify 6 · VerificationResponse isValid 402 + PAYMENT-REQUIRED client re-signs or aborts 7 · Fulfill resource prepare the paid work 8 · POST /settle 9 · Execute payment transferWithAuthorization 10 · Confirmed 11 · SettlementResponse success · tx hash 12 · 200 OK + data PAYMENT-RESPONSE Client Resource Server Facilitator Blockchain
