The most promising territory for a small team isn’t another large framework. It’s the opposite: infrastructure software you can explain in one sentence, ship as one binary or embed as one library, run with almost no operational burden, and that solves one irritating problem unusually well. SQLite and nginx are the right mental models because their appeal is architectural, not just functional: small surface area, predictable behavior, few dependencies, easy deployment, and usefulness far beyond the original use case. (More on that in the SQLite and nginx pattern as a product strategy.)

This list deliberately leaves “tiny version of Redis, Kafka or SQLite” territory behind. That was the first list of 20 primitives. The more interesting search space is a primitive that introduces a new operation, one developers might eventually feel should have existed all along. Some research paper or niche project has probably explored pieces of these. They’re meant as category-level concepts, not smaller copies of familiar products.

Forty primitives

1. Reach. Store a current state plus transition rules and continuously maintain which states are reachable from here: REACHABLE(current_state). A database answers what is; Reach answers what can happen. Uses: AI agent safety, workflows, infrastructure, manufacturing, cybersecurity attack paths.

The Counterfactual Store does resemble a Markov chain at the conceptual level. Both deal with states and the possible transitions between them. But a Markov chain is mainly a mathematical model for probabilistic transitions: given that I’m in state A, what’s the probability the next state is B, C or D? And the classic Markov property says the next-state probability depends on the current state, not the full history.

The Counterfactual Store is deterministic branching, not probabilistic transition. If the current application state is A, you create a hypothetical A′, change something, propagate the consequences, inspect the result and throw it away without touching A. No probability needs to be involved anywhere.

One direction that feels genuinely different from the earlier list of 20 primitives is a Counterfactual Store. Adjacent ideas certainly exist. Provenance databases, event sourcing, probabilistic databases, simulation systems and version control all touch pieces of it. But as a deliberately tiny infrastructure primitive, there’s no established category built around this exact abstraction.

Normal databases answer “what is true?” Temporal databases, and Temporal KV, add “what was true?” A Counterfactual Store adds a third basic question: what would be true if X were different?

Somebody pastes a population figure into a shared spreadsheet: 1,234,567. It might have come from a census table, a Wikipedia infobox, a city press release or a model’s summary of one of those, and three weeks later nobody can say which. The paste kept the digits. Everything that made them believable stayed in a browser tab that closed long ago.

A value without provenance is a rumor with a data type.

Feed forty articles about a rumored plant restart to a summarizer and you get one smooth paragraph: several outlets report that production will resume in March, though the ministry has pushed back. It reads well. It also throws away what you’d need to act on it. You can’t tell which outlets reported it, whether each had its own source or all copied one wire story, or what the ministry actually said, a denial or a polite refusal to comment.

An agent is ninety tool calls into a refactor. Step 12 was a grep that returned 52 KB, and all of it is still in the prompt. The user’s instruction from step 1, “never touch db/migrations”, fell out of the window ten steps ago, because the framework drops the oldest messages first. The agent edits a migration. Nothing malfunctioned; the truncation rule did exactly what it was written to do.

A nightly agent job triages new issues. One night an issue arrives with a 400 KB log attached. The agent reads it, a tool call fails, the agent retries, and the loop runs until the month’s token budget is gone. Meanwhile cron, which has no idea what a token is, starts the next run on schedule. Now two copies are fighting over the same issue tracker.

Cron was built for jobs that cost nothing, finish in seconds and do the same thing every time. Agent jobs cost money per token, run for an unpredictable time and can loop. The useful ones are still boring and periodic: summarize what changed in a repo since yesterday, triage new issues each morning, check a competitor’s pricing page weekly. What they need is a scheduler that stays as small as cron and adds four things: a cost ceiling, a timeout that actually kills, an overlap rule, and state carried between runs. Anything past that is an orchestration platform, a different and much larger product.

An agent keeps a memory table, and two rows matter for today’s task: a supplier’s headquarters city, written eleven months ago, and a freight quote, written three hours ago. A SELECT returns both in the same shape. The headquarters is probably still right. The quote may already be wrong. Nothing in either row says so, and the agent repeats both in the same flat tone.

A row has no idea how old its truth is. It might carry a created_at, and a careful person can compute an age from it, but the decay rate belongs to the kind of fact, not to the table. A three-week-old headquarters address is fine. A three-week-old shipping rate is fiction. Server health goes bad in half a minute. No timestamp column holds that knowledge, and nothing forces a query to read it anyway.

Cloud coding agents start each task on a fresh machine. Before the agent can run a single test, something has to install the right runtime, start a database, configure environment variables, and download dependencies. Every platform that runs agents wants those instructions in its own file: Copilot expects a setup workflow, Cursor builds a Dockerfile, other platforms want shell scripts or configuration in other formats. A team that uses two or three agents writes the same setup two or three times, and mistakes usually show up later as an agent session that stalls because a database port wasn’t open or a runtime was the wrong version.

A coding agent spends its day reading text written by strangers: issues on your issue tracker, snippets pasted into prompts, code from repositories, instructions on web pages. One malicious instruction planted in that text can be enough to make an agent send a deploy token somewhere it shouldn’t. On a machine-wide VPN, that request leaves the same way as everything else, and afterwards nobody can say which program sent it.

Cloudflare shipped Kitesurf on August 6, a web browser it wrote from scratch for AI agents. It runs entirely inside Workers. No Chromium underneath, no container, no headless Chrome process idling in a warm pool waiting for something to do.

The problem it targets is a billing problem. Agents need browsers to do real work, and Chromium is the only serious option, but Chromium was built for a person sitting in front of a screen. Tabs, extensions, device sync, sixty frames a second of smooth scrolling. An agent does not care about any of that. What it cares about is token count, context window, and what the session costs. Handing every agent its own Chromium instance prices most agentic applications out of the web entirely, and leaves browsing to the expensive models that can afford it.

DigitalOcean has announced the DigitalOcean AI-Native Cloud, positioning itself as the first cloud platform built end-to-end for the inference and agentic era. The launch took place at Deploy 2026, the company’s annual conference for builders, and the platform is available to customers today.

The Problem It’s Solving

AI developers have long been squeezed between two imperfect options: hyperscalers like AWS with enterprise-grade complexity and unpredictable costs, or newer GPU clouds that hand you bare metal and tokens but leave you to wire everything else together yourself. DigitalOcean is pitching its AI-Native Cloud as the third path — a fully integrated stack that handles infrastructure through agents, without the assembly tax.

Verdent has updated its AI-native software platform to operate across the full build cycle — planning, execution, validation, and delivery — rather than stopping at code generation. The update positions Verdent less as a coding assistant and more as a substitute for an engineering team, handling the sequence of decisions and handoffs that typically require multiple people to coordinate.

The gap between a software idea and a shipped product is not usually an ideas problem. It is a labor and coordination problem. Crossing it has historically required hiring engineers, managing sprints, and absorbing the context loss that comes with every handoff. Verdent’s design premise is that AI can now carry that load end-to-end: breaking a goal into tasks, selecting appropriate tooling, writing and testing code, and continuing work asynchronously through Slack or Telegram integrations even when the user is away. Context is retained across sessions, including stack decisions, prior build choices, and current state, so work does not reset between conversations.