Skip to content

CONCEPT Cited by 1 source

Agent-first storage primitive

Agent-first storage primitive names the design posture of building a storage service whose API shape, economics, and protocol choices are optimised for the shape of agent workloads first, with human developers as a secondary audience, rather than retrofitting an existing human-centric storage service for agent use.

What "agent-first" means concretely

Four properties recur in 2026-04 Cloudflare storage/retrieval launches that each self-describe as agent-first:

  1. Per-session / per-customer / per-agent isolation is the default. One instance per caller-identified scope, not one shared instance that applications must partition. Matches one-to-one-agent shape — the deployment unit of an agent is one instance per (user, task, conversation) and its storage should follow.
  2. Zero idle cost — concepts/scale-to-zero economics. Unused-but-existing state is not a drag. Agents are "massively single-tenant" — of ten million provisioned storage instances, 1 % might be active at any moment, and charging for the other 99 % at hot-instance rates breaks the model.
  3. Protocol / API choice biased toward training-data familiarity. If a protocol / API is "deep in the training data of most models", agents can interact with it through their ambient knowledge rather than via custom skills, CLIs, or MCP servers that have to be distributed and loaded. This is the load-bearing claim behind patterns/git-protocol-as-api: Git is chosen as the Artifacts wire protocol specifically because LLMs already know it.
  4. Agent-ergonomic APIs beside the protocol. REST + native bindings + forthcoming language-specific SDKs sit alongside the protocol so non-agent callers (Workers, Lambda, serverless functions) have a less-ceremonial path. Cloudflare Artifacts' env.ARTIFACTS.create() / .import() / .fork() / .get() is the canonical shape.

Canonical wiki instance

Cloudflare Artifacts (2026-04-16):

"We think there's a need for a new primitive: a distributed, versioned filesystem that's built for agents first and foremost, and that can serve the types of applications that are being built today." — Artifacts launch post

Every Artifacts design decision reads as a concrete answer to "what does agent-first mean here?":

  • Per-repo Durable Object → isolation + single-writer ordering per agent-defined scope.
  • Pricing keyed to storage + operations with no hot/cold tier → zero idle cost.
  • Git as the wire protocol → training-data familiarity.
  • REST + Workers binding + SDKs → non-Git-client callers.

Canonical wiki sibling instances

Distinguishing from "works for agents"

Many storage systems work fine for agent use without being agent-first: S3 + DynamoDB + Postgres all serve agent state perfectly well, but their pricing, API shapes, and isolation stories were designed around multi-user applications. An agent-first primitive reverses the bias — the one-to-one, bursty-then-dormant, training-data-familiar-protocol shape is the default, and multi-user access is expressible but not optimised.

Open questions

  • Lock-in vs portability. The more agent-specific conveniences a storage primitive ships (fork / import / git-notes for Artifacts; runtime-provisioned namespaces for AI Search), the more load-bearing the platform becomes. No settled answer.
  • Price-point stability across beta → GA. Artifacts' 2026-04 prices ($0.15 / 1 k ops + $0.50 / GB-month + generous free tier) are explicitly hedged ("should this pricing change").
  • Cross-primitive composition. Artifacts + AI Search + DO + R2 + KV overlap in what they can store; the boundaries between them are clearer in marketing than in use (Artifacts' post itself mentions per-customer config rollback as a use case — but per-tenant config is also a natural fit for DO + KV).

Seen in

Last updated · 200 distilled / 1,178 read