The Fork in the Stack

Two announcements landed in the same week. They solve overlapping problems. They reveal completely different beliefs about what's happening.

On April 7, Amazon launched S3 Files: a POSIX filesystem view layered on top of S3. The pitch is practical — your AI agents can now grep and cat and sed directly against object storage, no sync pipelines or SDK wrappers needed. Data never leaves S3. Standard Unix commands just work.

On April 16, Cloudflare launched Artifacts: a Git-native versioned filesystem for agents. Create millions of repos programmatically. Fork sessions. Time-travel through state. Built on Durable Objects and a custom Git server written in Zig, compiled to a ~100KB WASM binary.

Here's the thing: both products are built on old technology. S3 Files runs on EFS and NFS. Artifacts runs on Git — a protocol from 2005. Neither team invented their foundations. The difference isn't old versus new. It's what shape the abstraction takes.

#The Retrofit

S3 Files solves a real problem. The object-vs-file impedance mismatch has tortured engineers for twenty years. You can't tail -f an S3 object. You can't run pandas.read_csv() against a bucket without downloading the file first. The workarounds — data duplication, sync pipelines, SDK wrappers — all carry operational overhead that compounds at scale.

Amazon's solution is elegant engineering: EFS under the hood, bidirectional sync, intelligent caching (files under 128KB get pulled into fast storage, larger files stream from S3). NFS v4.1, POSIX permissions stored as S3 metadata, TLS 1.3 in transit. It works with existing buckets. No migration required.

The agent narrative gets bolted on afterward. "Agents use file-based tools natively." "Multi-agent pipelines need shared mutable state." True statements, both. But the product wasn't designed for agents. It was designed to solve a pre-existing pain point that agents happen to also feel.

This is the retrofit pattern: take something that works, make it accessible to a new consumer. The world doesn't change. The adapter does.

#The New Bet

Cloudflare's Artifacts starts from a different premise: agents don't just need access to files. They need versioned, forkable, disposable state.

The design decisions reveal the thinking. Every agent session gets its own repo — not a shared filesystem, an isolated workspace with full history. Fork from any point. Roll back. Diff. Share a session by sending a URL. Pick up someone else's work by forking their state. The Git protocol was chosen not because agents need source control, but because Git's data model — commits, branches, diffs, merges — maps onto how agent work actually flows: iterative, branchable, reversible. Cloudflare says it plainly: "Agents know Git. It's deep in the training data." That's a retrofit argument! They picked a 20-year-old protocol precisely because it's familiar. But what they built on top of it — millions of disposable repos, per-session forks, programmatic creation — required writing a Git server from scratch in Zig. The foundation is old. The shape is new.

Internally, Cloudflare uses Artifacts to persist sandbox state and session history in per-session repos. The filesystem and the conversation travel together. Fork a debugging session to hand it to a colleague. Time-travel through both the code and the prompts that produced it.

This is what makes the distinction slippery. Artifacts isn't "new tech" — it's old tech rearranged into a shape that matches a new workload. The building blocks are familiar. The assembly is not.

#The Split Is Everywhere

Storage is just where it's most visible. The same fork runs through the whole stack, and each layer tells you something about where we are in the transition.

Compute. AWS Lambda was built for short-lived, stateless functions — the opposite of agent sessions, which are long-running, stateful, and non-deterministic. Here's what that mismatch looks like in practice: an agent researching a topic might make twelve LLM calls over ten minutes, waiting for each response before deciding the next step. On Lambda, each wait risks a timeout. State has to be externalized to DynamoDB or S3 between invocations. The agent's "memory" lives in a database, not in the runtime.

AWS knows this. Their own documentation for Bedrock AgentCore concedes that existing primitives "were never designed for the peculiar demands of AI agents." Their response: Lambda Durable Functions, announced at re:Invent 2025 — checkpoint-and-replay semantics bolted onto Lambda so functions can pause, persist state, and resume later. It's clever engineering, but it's a checkpoint system stitched onto a stateless runtime. The function still doesn't have state; it serializes and deserializes it at each step.

Cloudflare's Durable Objects start from the opposite assumption: every agent is a stateful actor with its own SQLite database. When idle, it hibernates — zero compute cost. When a message arrives (HTTP, WebSocket, scheduled alarm, inbound email), the platform wakes it, loads its state, and hands it the event. The agent does its work, then goes back to sleep. State isn't externalized and restored; it's just there, in memory, when the agent wakes up. That's the difference between "stateless function that persists state externally" and "stateful actor that hibernates."

Protocols. MCP (Model Context Protocol) is the most interesting case because it lived the full arc in real time.

When MCP launched in November 2024, remote communication required two endpoints: a GET /sse connection for the client to receive responses, and a separate POST /messages endpoint to send requests. In practice, this meant managing two HTTP connections per agent session, correlating requests across them, and handling the inevitable failures when the long-lived SSE connection dropped mid-operation. If your agent was waiting for a slow tool call and the SSE connection timed out, the response was lost. You had to reconnect and retry.

Within five months, the MCP team deprecated SSE entirely and shipped Streamable HTTP — a transport they designed from scratch. One endpoint: POST /mcp. For simple calls, it returns a normal HTTP response. For long-running operations, the response upgrades to an SSE stream on the fly. The server can push notifications back to the client on the same connection. The practical difference: you go from managing two connections with correlation logic and reconnection handling to making a single HTTP request that adapts to whatever the interaction requires.

Meanwhile, A2A (Agent-to-Agent) skipped straight to the new bet — a protocol for peer relationships between agents, with discovery via "Agent Cards," task negotiation, and streaming status updates built in from day one. MCP assumes a hierarchy (model calls a tool). A2A assumes peers (agents negotiate with each other). The relationship topology is baked into the protocol, not bolted on.

Auth. This is where the picture gets messy — and honestly, it's where the retrofit is winning for now. MCP adopted OAuth 2.1 as its authorization standard: PKCE, dynamic client registration, .well-known metadata discovery. The full enterprise auth stack, designed for humans clicking "Allow" in a browser, now repurposed for agents.

In practice, this means an MCP client that gets a 401 Unauthorized has to open a browser, redirect the user through a consent screen, receive an auth code via callback, and exchange it for an access token — the same dance every web app has done since 2012. It works. It's well-understood. It plugs into existing identity providers.

But it assumes a human is present to click "Allow." For fully autonomous agents — an agent that wakes up at 3am to process a queue — the browser redirect is a dead end. Cloudflare's Artifacts sidesteps this entirely: await env.ARTIFACTS.create(name) returns a repo with a token. No browser. No consent screen. The auth model matches the consumer. Whether the broader ecosystem lands on OAuth-for-agents or invents something new is genuinely unresolved. MCP bet on the retrofit. It might be right — enterprise IT departments already understand OAuth. But the tension between "human approves access" and "agent acts autonomously" hasn't been resolved. It's just been deferred.

#What the Bet Reveals

Look at the pattern across all three layers:

The retrofit says: agents are a new kind of user. Give them access to what exists, and they'll figure it out. The value is compatibility — works with your existing stack, plugs into your existing identity providers, runs on your existing infrastructure.

The new bet says: agents are a new kind of computing. They need primitives designed for how they work — iterative, parallel, disposable, branchable. The value is leverage — when the infrastructure matches the workload, you get capabilities that retrofits can't reach.

But I want to be honest: the line is blurry and it moves. MCP started as a retrofit (SSE) and evolved toward a new shape (Streamable HTTP) — but adopted a retrofit for auth (OAuth 2.1). Lambda started stateless and bolted on checkpointing. Nothing is purely one camp. The "new" isn't the technology — it's the abstraction, the shape of what's exposed to the consumer. Same old building blocks. Different architecture.

S3 Files will immediately help thousands of teams who have AI pipelines reading from S3 today. Artifacts won't help anyone until they rethink their architecture around per-session repos and forkable state. The retrofit has adoption. The bet has ceiling.

So let me make the ceiling concrete.

#What the New Shape Makes Possible

Here's a task: an agent is fixing a bug. It has three plausible approaches — retry logic, connection pooling, or async rewrite. It needs to try all three against the same test suite and pick the one that passes.

On a POSIX filesystem, this is painful. The agent either tries them sequentially (slow, and the filesystem is mutated after each attempt, so you need cleanup logic to restore state), or you build an orchestration layer that copies the working directory three times, runs each approach in a separate copy, and compares results. That orchestration layer doesn't exist in the filesystem. You have to build it.

With forkable state, this is a primitive. Fork three times from the same snapshot. Run each approach in its own fork. Compare. Pick the winner. The branching is the storage model, not something bolted on top.

This isn't theoretical. It's already shipping.

ConTree, built by the Nebius AI R&D team, offers sandboxed execution with Git-like branching for exactly this pattern. Branch from any checkpoint, explore paths in parallel, pick the winner. Their selling point against Docker is blunt: "Containers can't branch state. ConTree can." They built it for agents doing tree search — Monte Carlo tree search over code, where each node is a filesystem state and each edge is an attempted fix.

MIT's EnCompass framework formalizes the same insight from the academic side. You annotate "branchpoints" in your agent program — places where the LLM's output might vary — and EnCompass automatically clones the runtime to explore multiple paths in parallel, backtracking when paths fail. The researchers frame it as separating the search strategy from the workflow. But that separation only works if the infrastructure can fork cheaply. On a filesystem, cloning a runtime is expensive. With versioned state, it's a pointer copy.

Cloudflare's own Project Think — their next-gen Agents SDK, announced the same week as Artifacts — stores conversations as trees where each message has a parent_id. Fork a conversation to explore an alternative without losing the original path. Compact older messages without destroying them. The conversation history and the filesystem travel together in the same versioned structure.

OpenAI's Codex already runs each task in its own cloud sandbox, preloaded with your repo. Their subagent system spawns specialized agents in parallel and collects results. But each sandbox is a fresh container — there's no branching from a shared state, no diffing between approaches, no rolling back to a checkpoint. The isolation is there. The versioning isn't.

That's the gap. The filesystem model gives you isolation (separate directories) and persistence (files stick around). The versioned model gives you isolation, persistence, and time travel — the ability to branch, diff, merge, and replay. Each additional property enables a class of agent behavior that the previous model can't support without external tooling.

#The Design Physics

I keep coming back to a frame from an earlier essay: constraints shape what's possible. The choice of storage primitive is a design decision about what agents can do.

A POSIX filesystem encodes assumptions: files are edited in place, directories are hierarchies, there's one timeline. Those assumptions don't match how agents actually operate — iterating, branching, exploring, backtracking.

A versioned store encodes different assumptions: every state is a snapshot, every mutation is a commit, branching is free, merging is possible. Git is old too — but the abstraction built on top of it enables capabilities that the filesystem model actively prevents.

The infrastructure you choose doesn't just serve your agents. It shapes what they can become. S3 Files means your agents can grep a bucket. Forkable state means your agents can try three approaches simultaneously, compare the results, and discard the losers — without anyone writing orchestration code. That's not a quality judgment. It's a physics difference.

#Where It Goes

The honest answer: both patterns will coexist for a long time. Most teams will reach for the retrofit first — it's faster, cheaper, lower risk. The new bets will grow underneath, adopted by teams building agent-native products where the old primitives genuinely don't fit.

But I'd watch the Cloudflare pattern. Not because Cloudflare specifically will win — that's a business question, not an architecture question — but because the type of thinking they represent tends to compound. Every new primitive that matches how agents work becomes a building block for the next. Versioned state enables session replay enables collaborative debugging enables multi-agent branching. Each layer makes the next possible.

The retrofits don't compound the same way. They remove friction, which is valuable, but they don't open new design space. S3 Files means your agents can grep a bucket. That's useful today and exactly as useful in five years. Artifacts means your agents can fork reality. Where that leads is harder to predict — and that's exactly the point.

The fork in the stack isn't about old technology versus new technology. Everything is built on something that came before. The question is whether you preserve the old shape or build a new one.

The bet you make — same building blocks, different architecture — shapes the world you build.