Part Five: Building for agents

Research commentary from Skycatcher, LLC, an exempt reporting adviser; not an offer, solicitation, recommendation or investment advice. The private-company valuations in this part are the companies’ own announced round prices, not our estimates of value. Skycatcher is an investor in Clockwork Labs, the company behind Spacetime (SpacetimeDB), discussed below, and this site runs on its Maincloud service. Skycatcher, its affiliates, principals and clients may hold positions in any company named here and may trade them without notice. Appendix D3 carries the full disclosures.

Building for agents

Agents are becoming builders and users of software. They can choose a database, deploy an application and keep it running. The infrastructure beneath them has to become easier to use and dependable enough to carry the work.

We see a broad opportunity here. Established clouds, open-source projects and new companies are approaching the same problem from different directions. Some will sell individual services. Others will bring more of the system together. The architecture that serves machine work may look different from the one built around human developers.

Where new companies are forming

Our private-company map follows twenty-eight businesses across four groups: services that run agents, clouds that serve models, tools that control and monitor activity, and systems that store data and memory.

Temporal, Modal and Browserbase help run work. Fireworks, Baseten and Together serve models. Grafana, Braintrust and WorkOS help monitor or control activity. Databricks, Supabase, Convex and Spacetime supply data or application infrastructure. Their products overlap, but each gives us a different view of what agents need.

The first signs appear in creation. Vercel reported on June 17, 2026 that coding agents trigger more than half of its deployments. Databricks, which owns Neon, reported in January 2026 that agents create 80% of the databases on Neon. Supabase reported in June 2026 that AI tools launched more than 60% of its new databases, and in October 2026 that the share had reached 70%.

Those disclosures count different things over different periods. A database may last seconds. A deployment may never attract a user. We want to know how many of these applications remain useful, active and paid for 90 days after creation. Creation tells us where agents are arriving. Retention tells us whether the work lasts.

Figure 5.1. The private backend landscape

Twenty-eight private companies show the range of products and architectures being built. Funding and valuation entries use the latest cited transactions or disclosures, with dates. A last-round valuation is a historical transaction reference, not a live market value or proof of operating performance. Cursor left the map when SpaceX’s acquisition closed (8-K filed August 14, 2026). Sources and method: Appendix C3, which carries each company’s dated source.

Figure 5.2. What adoption disclosures actually count

Developer registrations, database creation, projects, deployments and revenue measure different things. Each disclosure carries the company’s original definition, date and population. Product creation can be an early signal; paid retention and repeat production use provide stronger evidence of a lasting business.

Funding the backend build-out

The companies in our map raised much more capital from 2024 to 2026 than in the two years before. We record primary equity separately from debt and secondary share sales. Announced round prices show what investors paid at a point in time.

Funding can pay for capacity and distribution. The business still has to earn repeat use. We expect demand to grow for agent memory, identity, permissions, monitoring and application hosting. Some of that spending will reach new providers; some will be included in products customers already buy.

Acquisitions show the same convergence. Data platforms are adding tools to observe and control agents. Execution platforms are adding storage and identity. The boundaries in our map will move as providers compete to serve more of the work.

Figure 5.3. Funding the companies building the backend

The comparison includes disclosed primary equity rounds through October 5, 2026, on the stated category definitions. Debt and secondary transactions are excluded. Financing measures capital supplied to companies, not demand for their products.

Fewer systems to connect

Building an application often means connecting separate services for data, authentication, execution and live updates. Every connection adds setup, testing and maintenance. An agent can write the code quickly and still struggle to make the whole system work.

Supabase packages services around Postgres, a widely used open-source database. Convex brings data and application functions into a managed backend. Spacetime runs application logic inside the database and streams changes to connected clients. Each reduces a different part of the work developers have to assemble themselves.

These designs put application logic and data in different places. Each reduces some work and leaves different limits. Figure 5.4 follows an update through each system, separating processing, storage and networking. A read replica is a read-only copy; WAL means the database change log. More connected users, more stored data and more writes per second are different measures of scale. The figure describes the products on the stated date, with planned features shown separately.

Figure 5.4. Different architectures move work to different places

What adoption can establish

Supabase’s disclosed developer base rose from about one million in October 2024 to nearly ten million in June 2026. Convex has also reported substantial growth in developers and applications. These figures show distribution and interest. They do not yet give us comparable measures of paid retention or the share of agent-built applications that work correctly.

We ask the same questions of every architecture. Can an agent build a correct application with fewer repairs? Can the system handle the resulting workload? What does it cost to operate? Do customers keep using it?

Different applications may need different answers. A large analytical workload and a small collaborative app need not run on the same design. The opportunity can support several approaches.

Figure 5.5. Supabase’s developer count has grown rapidly

Supabase reported about one million developers in October 2024 and nearly ten million in June 2026. The chart preserves the company’s definition. Registered developers are not the same as active production customers or paying accounts.

From assembling services to running software

Andrej Karpathy described the problem in March 2025: building a web application still requires a developer to assemble and configure many separate services. His post captures a constraint we have met in our own work. Generating more code does not by itself remove the work of connecting it to a reliable system.

Figure 5.6. A developer’s view of the remaining complexity

Practitioner observation. Karpathy’s post describes the work of assembling web services. It gives context for the architecture question; it is not a benchmark or a measure of market-wide adoption.

Figure 5.7 shows one proposed solution. Clockwork Labs’ diagram brings application logic, data and live updates together in Spacetime. The idea is the same application with fewer systems to connect—and less connection code to write and maintain.

Figure 5.7. A proposed solution to the missing infrastructure piece

The next diagram separates two jobs. One layer runs the models. Another runs the code they write. Both are needed when an answer becomes an application that people depend on. The second layer has to keep working after the conversation ends.

Figure 5.8. Running models and running the code they write

What we have learned by building

Machine Hour runs on Spacetime. Skycatcher is an investor in Clockwork Labs, the company behind it. That relationship informs our access and our interest; it also makes clear disclosure and independent testing important.

Using the product gave us a direct view of the architectural idea. Application logic and data sit together, and connected clients receive changes through subscriptions. An agent has fewer separate services to configure. Our experience shows that this approach can serve this site. Larger and more demanding applications need their own evidence.

Clockwork Labs has published tests of transaction throughput and application building. The first measures a specific workload. The second asks the same agent to build a twelve-feature chat application on two backends. The figures below show the results and the limits of each test.

Independent replication, comparable configurations and paid applications running reliably over time would strengthen this evidence.

Figure 5.9. A vendor benchmark on one workload

Vendor benchmark. Clockwork Labs reports roughly 304,000 transactions per second for Spacetime Standalone; its selected alternatives range from about 130 to 3,200. Hardware, workload and durability settings affect the result. The test is not independently verified and does not establish a general performance advantage. Skycatcher is an investor in Clockwork Labs. Method and source: Clockwork Labs benchmark post.

Figure 5.10. A small test of building with agents

Vendor benchmark. Two runs per backend, using Claude Sonnet 4.6 and manual grading against twelve requested features. This sample cannot establish a stable success rate or general architecture advantage. Disclosed prompts, repeated trials and independent grading are needed. Skycatcher is an investor in Clockwork Labs. Method and source: Clockwork Labs benchmark page.

An operating layer for the machine economy

Imagine describing a service you want to exist, and having agents build it, launch it and keep it running across clouds and devices. You set the goal, budget and decisions that need approval. A shared operating layer preserves the data, permissions and history so another agent can carry on when one stops.

That layer needs four capabilities: place work on suitable, authorized hardware; preserve information between tasks; recover from failures; and enforce people’s permissions, budgets and approval rules. It could connect several platforms through shared standards.

Figure 5.11. One goal, many machines

Illustrative vision, not a product or a measurement. A possible architecture: agents coordinate work across authorized computing resources, while people set goals and limits, and results and approval requests return to the person.

In April 2026, we asked ChatGPT to imagine the scale of such a platform. The exchange below is a thought experiment. Its useful question is how much computing could pass through a common operating layer.

Figure 5.12. The blue-sky scenario: a common operating layer

Thought experiment. This April 2026 ChatGPT exchange considers a distributed system across cloud hardware. Its valuation figures are speculative model output, not an independent valuation, a price target or evidence of demand.

The lasting value would come from useful systems that keep operating. Agents build and launch a service, maintain its information and propose improvements. People approve consequential decisions. If a task is interrupted, another agent can resume from the saved data and history.

Figure 5.13. The work continues after the conversation ends

Illustrative vision. One application through four stages, create, operate, adapt and continue, on a backend that preserves the application, its data, its permissions and the record of work. The lasting value comes from useful systems that keep operating; each task can build on what came before.

What would make that vision real

The hard part is making these systems work together reliably: moving data, isolating customers, recovering from failures and controlling cost and permissions across machines. Portability must work in production. No single company has established this outcome.

Our machine-hours thesis does not require this full vision to arrive. It describes what sustained growth in machine work could make possible.

We believe people will increasingly direct work that agents carry out and maintain. The backend would become the foundation for that work: keeping applications running, preserving what has been learned and allowing the next task to build on the last. The larger possibility is a world where far more people can turn an idea into something that works, and keeps working.