06-reference

treybig how agents use systems differently

2026-05-14·reference·source: Treybig (Innovation Endeavors)·by Davis Treybig
agent-infrastructureharness-engineeringagent-tooling-stackhot-path-infracomputing-infrastructurevc-thesis

"How Agents Use Systems Differently" — @Davis Treybig (Innovation Endeavors)

Why this is in the vault

Treybig names the other half of the agent-era hot-path stack — the half that the Anthropic-buys-Bun / OpenAI-buys-Astral acquisitions ([[2026-05-14-technically-package-managers-ai-labs-acquisitions]]) did not touch. Bun and Astral collapsed the package-manager + execution toolchain; that's the dev-side of the hot path. Treybig's piece is about the data-side: databases, vector search, object storage, observability, dev sandboxes, data warehouses. Each of those gets re-architected when the primary client is an agent doing 10-100x more queries, bursty parallel, longer query strings, write-once-burn-the-namespace patterns.

This is load-bearing for two RDCO threads: (1) the agent-tooling-stack / hot-path-infra investing thesis — Treybig is the operator-side validation of which infra categories are structurally up for grabs and which incumbents (Snowflake, Elasticsearch, S3, Datadog) are mis-architected for the new client; (2) the productization-gap thesis from [[2026-05-13-fde-asymmetric-edge-rdco-positioning]] — many of these tier-1 infra vendors will ship raw primitives and need productized workflows on top.

The core argument

  1. Agents use systems with structurally different workload shape. 10-100x more queries on the same data, bursty-parallel rather than human-sequential, sub-minute analytical workflows that used to take hours, thousands of tiny artifacts rather than fewer large ones, exhaustive high-cardinality exploration rather than pre-aggregated dashboard reads.
  2. Agents are smarter clients than humans. They write longer, more precise queries with heavy operator use, can be told about a system's internals and adjust accordingly, and run iterate-fail-correct loops where each query refines the previous. This inverts the smart-server / dumb-client assumption — the right shape is now a thinner server with more exposed internals.
  3. The architectural elements that go from optional to critical: snapshotting and time-travel; cheap copy-on-write branching with git-like rebase/merge semantics; elastic stateless workers with storage-compute separation; high-concurrency support per single agent client; contention mitigation via CRDTs / versioned filesystems / fine-grained locking; metadata efficiency to handle 1000x more objects (the "small file problem"); tiered storage and aggressive compaction for cost; server-side session state for incremental caching; thin APIs exposing ranking / query expansion / indices to the agent; sampling and pre-production simulation; lightweight local-execution modes for fast iteration.
  4. Thesis: systems must be re-architected, not incrementally patched. Treybig is actively scouting founders rebuilding these categories from agent-first first principles.

Mapping against Ray Data Co

Strong mapping. Five connections, in priority order:

  1. The agent-tooling-stack thesis just got its other half. [[2026-05-14-technically-package-managers-ai-labs-acquisitions]] told us the labs are absorbing the toolchain hot path (package managers, sandboxed execution). Treybig is telling us the data hot path (databases, search, storage, observability) is still independent infra and probably stays that way — labs aren't going to buy Snowflake. So the durable-margin question for agent-era infra is now bifurcated: dev toolchain = labs-absorbed; data stack = independent and rebuildable. This sharpens any RDCO infra-investing thesis pass — tier-1 BUY context stores in the [[concepts/2026-05-14-four-tier-buy-build-stack-soloproneur-tam-filter]] frame all sit in Treybig's data-stack half, not the toolchain half. Good news for picks-and-shovels investing; bad news for anyone hoping to build a competing toolchain.

  2. Defensibility migration — operator-side confirmation. [[concepts/2026-05-13-amble-is-software-losing-its-head-defensibility-migration]] argues that the locus of defensibility is migrating off the UI layer down into deeper infra and proprietary data. Treybig is the operator-side proof. He's a VC pricing the migration by writing checks into the new infra layer. The eight startups he names are concrete instances of where new defensibility is being constructed (object-storage-native vector indices; branching Postgres; versioned filesystems for parallel agent edits). If the Amble thesis is correct, this is what its UI-down-to-infra phase looks like at the data layer.

  3. Layer-stack with the Innermost Loop thesis. [[2026-05-12-diamandis-innermost-loop-ai-infrastructure-thesis]] is the bottom of the stack — power, chips, data centers, frontier-lab capex. Treybig is the middle of the stack — the databases / observability / dev sandboxes that consume that compute and serve agents. Same investing thesis (infra wins under wrappers), different layer. Worth being deliberate: RDCO's investing surface should pick a layer rather than spreading across both. Diamandis-layer requires capital scale RDCO doesn't have; Treybig-layer is more accessible to a soloproneur via secondaries or angel checks — but the lab-absorption risk is also higher at this layer for any sub-category that drifts toward the toolchain side.

  4. Tier-1 BUY map. [[concepts/2026-05-14-four-tier-buy-build-stack-soloproneur-tam-filter]] says tier-1 (context stores, search, observability) is BUY, not build. Every Treybig name is tier-1 by definition. The mapping for RDCO is not "build one of these" — it's "pick correctly when buying for your own agent stack, and track them as investing candidates." Specifically: Neon and turbopuffer are already on the RDCO consider-list for the COO agent's own data layer.

  5. Productization-gap for the FDE wedge. [[concepts/2026-05-13-fde-asymmetric-edge-rdco-positioning]] argues RDCO's asymmetric edge is productized FDE work on top of raw primitives. Most of Treybig's eight startups are raw primitive vendors — they ship the engine, not the workflow. That's the gap. A Bauplan or Tigris customer in 2027 will still need someone to wire it into their actual agent fleet, write the prompt templates, set the eval harness, ship the dashboards. That's MAC commercial product territory. The Treybig list is also a target-customer list for MAC.

Investing-thesis startup roster

Startup Treybig's category framing RDCO targeting filter pass?
Bauplan_labs OLAP / data lakehouse rebuilt for agent 10-100x workload, small-data native Maybe — interesting but RDCO doesn't have a niche-anchored reason to track it past general data-stack awareness
turbopuffer Vector search, object-storage-native, 100x+ cost reduction, millions of small per-customer namespaces Yes — RDCO needs vector search for the vault + agent memory; on the buy-side consider-list now, on the watch-side as a possible angel investing candidate
TigrisData Distributed S3-compatible object storage, versioned filesystem, small-file problem Defer — overlaps R2/S3 which RDCO is already on; no anchoring bottleneck
mesa_dot_dev Git-and-filesystems primitive for fine-grained parallel-agent isolation without coarse locking Yes — directly relevant to multi-agent COO architecture; worth a thesis pass and possibly a kick-the-tires demo
p0 Security (agent-specific surface, identity/perms for fleets) Defer — security infra is downstream of having the agent fleet in the first place; revisit when RDCO crosses 3+ persistent agents
daytonaio Dev sandboxes with full branching/merging without remote leakage Yes — directly maps to RDCO's worktree-style agent dev environment story; the [[2026-04-09-technically-claude-code-meta-ads-autonomous-loop]] thread has been pointing here
neondatabase Serverless Postgres with database branching Yes — already RDCO's tentative pick for any agent-native Postgres need; Treybig's framing sharpens why
usefiretiger / FireboltHQ Data warehouse rebuilt around Iceberg + agent small-data / high-concurrency patterns Defer — RDCO doesn't operate a data warehouse and is unlikely to need one in the next 12 months

Three names cross the targeting-system prioritization filter for an active thesis pass: turbopuffer, mesa_dot_dev, daytonaio. The other five are status-only.

Where Treybig is light: no pricing, no honest take on which categories the labs will eventually absorb (he is structurally biased to assume independence — his fund needs that to be true), and no view on which incumbents (Snowflake, Datadog, ES) successfully retrofit vs. get displaced. The retrofit question is the most expensive one and the one we should keep watching independently.

Related