🪣 Buckets as Substrate

Substrate.run raised $100 million. Impressive bucket!

Here's their public API:

text = ComputeText(prompt=prompt)
response = substrate.run(text)

That's the substrate. Two lines. A constructor with a prompt parameter, and a method that under the hood calls the OpenAI SDK with retry logic. The category-claim name is doing all the marketing work. The technology is a thin wrapper around inference APIs you could write yourself in an afternoon.

This isn't really about Substrate.run specifically. It's about a class of companies whose entire pitch is selling commodity resources at premium prices, dressed in a category-claim name that does the work the technology doesn't.

The naming tell

Once you notice it, the pattern is everywhere:

Substrate.run isn't a substrate. It's an orchestration layer that sits above the actual substrate (model APIs). A real substrate is the thing you build on.
Segment doesn't do segmentation. It's a data router that ships events to other tools, which then do the segmentation. Segment itself doesn't cohort anything.
Medium isn't a medium. It's a blogging CMS with paywalls and an engagement algorithm. The platonic medium would be a neutral conduit; Medium-the-product is a specific opinionated product that adopted the abstract noun.
X isn't a letter you can lizardly possess and trademark, but apparently the lizard-brained legal system disagrees if you have enough money.

The pattern: pick an abstract conceptual noun for an entire category, attach it to a narrow product, let the buyer's mental shortcut do the marketing. The name claims to be the category, not just an entry in it. The SEO benefits are immense. Google search results suffer. No mention of actual substrates on the first page of results. The misrepresentation is structural.

The tell is precision. When the name is technical and specific — Postgres, Redis, ffmpeg, sqlite — the work is usually substantive. When the name is abstract and grandiosly category-evoking — Substrate, Medium, Segment, Platform, Foundation — suspect the product doesn't fulfill the category it claims.

Nx: the bucket business

The current king of bucket-selling-as-substrate is Nx. They sell content-addressed build cache. That's 200 lines of Python with an S3 backend — every modern build system already has one. Bazel has one. Turborepo has one. Buck has one. They market it as "developer productivity infrastructure," charge enterprise prices, and have built their entire business on cravenly funneling developers into their proprietary cloud tier.

The bucket-as-a-service fatcats cravenly take over stale open source projects and quietly redirect them into their sales funnel. The free open source maintainers stop responding to issues; the migration path quietly bends toward Nx Cloud; the free tier gets crippled enough to push enterprise adoption. Open source as a customer acquisition channel.

When you pay for an Nx enterprise license, you're paying for:

S3 buckets you could spin up yourself
A bad web dashboard
Sales motion and lock-in
They will remorselessly throw a wrench in your CI pipeline if they have decided you owe them money. Need to fix an urgent customer-facing bug? Sorry, go talk to Nx support.
Nx support is notoriously sluggish and snide because they assume that their customers are idiots. Otherwise they wouldn't be their customers. And the entire business model is lock-in. Sound familiar?
The illusion that this is "infrastructure" rather than "cache wrapper with a marketing budget."

That's the move. Sell buckets, claim it's substrate, treat the open source ecosystem as a customer pipeline.

The actual substrate problem nobody is solving

The hard problem in AI right now isn't orchestration. It isn't memory-as-RAG. It isn't "agent frameworks." It's context management for complex projects that evolve over time.

Concretely:

Persistent, structured state that survives across sessions
Declarative goals — where you are, where you're trying to go, what closing the gap requires
Refinement loops, because AI rarely one-shots correctly. The first output is the block of marble arriving at the studio. The sculpture happens in the iterative chipping.
Audit trails — so you can ask "why did the AI make that decision?" and get a real answer
Multi-agent coordination over the same shared substrate

None of these are what Substrate.run or LangChain or most of the funded AI tooling actually solves. They solve adjacent problems — composition, retrieval, parallelization — and hand the hard part back to you.

The hard problem is invisible in a pitch deck because you can't demo it in 30 seconds. It requires the audience to have built something agentic and felt the pain of context drift, goal vagueness, and one-shot pretense. The funded ecosystem is structurally biased toward problems that fit on a slide.

Why AI is good at coding

There's a specific reason AI works for coding while struggling with most other "easier" domains: git is already the substrate.

Git provides everything sculpture-theory needs:

Declarative goals (specs, tests, "fix this bug")
Structured state (files, lines, ASTs the AI can inspect)
Refinement as the native mode (edit, run, fail, fix, run, pass)
Audit trail (every chisel stroke is a commit, with author and message)
Cheap reversal (git revert, git reset)
Review surface (diffs, PRs, accept/reject/iterate)

The AI didn't have to invent any of this. It walked into a 20-year-old substrate already shaped for iterative refinement against declarative goals. Cursor, Aider, Claude Code — all of them are fundamentally "LLM with good context surface on top of git."

Corollary: AI will be good at X when there exists a substrate for X. The substrate is the precondition for AI competence. Not the model. Not the wrapper. The structure of the domain itself, made explicit and queryable.

Where AI struggles, look for the missing substrate:

Long-horizon agent work — no domain substrate, agent forgets what it's doing
Knowledge management — no equivalent of git for prose evolution
Healthcare decisions — fragmented records, no unified state model
Most "AI agents" — the substrate is implicit, ad-hoc, untyped

The funded AI tooling space is trying to substitute clever model wrapping for substrate building. It doesn't work because the substrate isn't a wrapper around the model. It's the structure of the domain itself.

Sucka VCs

And for VCs, they are absolutely in the category of people whose jobs are now obsolete because of AI.

Software VCs justify their dilution by claiming three things:

You need capital to scale a team
You need their network and credentialing
You need their pattern-matching wisdom

AI breaks all three.

For most software products — especially substrate-shaped ones where the value is architectural depth rather than headcount — solo plus AI is now plausibly competitive with a 20-person funded team. You don't need to scale a team if AI is doing 10x leverage on engineering. You don't need their network if you can reach customers directly through content (AI-leveraged). You don't need their pattern-matching if AI can also pattern-match the same playbooks.

The dilution math has always been brutal:

Seed: 20-25% gone for $2-5M
Series A: another 20-25%
Series B: another 15-20%
By Series C, you own maybe 15-30% of your own company in common stock that's last in line behind a stacked preferred chain
In moderate exits, founders frequently make zero while VCs hit their multiple

That math was acceptable when capital was the only path to scale a software business. It isn't anymore. Keeping 100% and shipping at AI-accelerated pace is the strictly dominant strategy for anything substrate-shaped.

VCs aren't obsolete as a category yet — they still fund capital-intensive businesses where the calculus stands. But for software substrate work, they're rapidly losing product-market fit with founders who can actually execute solo.

The 2026 funded teams will look impressive on the surface. The 2030 substrate-shaped work being built quietly today will look obvious in retrospect.

What to actually build

If you're working on a hard AI-adjacent problem and the funded ecosystem isn't solving it for you, it's almost certainly because the substrate for your domain doesn't exist yet. Build the substrate. Not as a SaaS to sell — as the architectural foundation for what you're actually doing.

The substrate doesn't have to be a startup. It can be:

A doctrine — architecture writing that captures the principles
A working reference implementation you maintain for yourself
A teaching codebase other practitioners can fork
An open-source pattern library

The leverage comes from the principles being right, not from the code being packaged. Datasette and DuckDB became influential without being VC-shaped because they're correctly shaped instead.

The funded "AI infrastructure" space will mostly evaporate over the next 3-5 years as the underlying providers commoditize the orchestration features. The thing that survives is substrate doctrine — the writing about how to think about distributed state evolution, declarative goals, refinement loops, audit-as-architecture.

Build that. Quietly. Keep 100% of it. Watch the bucket-sellers churn through their hype cycles while you compound on actual depth.