We recently built a small tool called MachineView. It takes any website and scores how readable it is to an AI agent, from 0 to 100.
The test is simple: strip away the pixels and check whether an agent can access the site, retrieve its content, parse its structure, understand its meaning, and navigate through it. The project was partly inspired by Parallel’s website, which lets you toggle between a human view and a machine view. Once you see the difference, it’s hard to unsee.
We ran 20 leading venture capital websites through it. The median score was 69 out of 100, and only two published a valid llms.txt. Frontier labs and leading AI companies did better - a median of 77 - but the spread was still surprisingly wide.
https://machineview.vercel.app/leaderboard
The web was not designed for agents
Websites were built for humans, then optimized for search engines. Neither works optimally for agents. They get stuck on aspects of both: JavaScript-heavy pages, bot walls, information trapped in images and PDFs, buttons whose meaning is obvious to the eye and invisible to a program. Browser-use models are improving fast, but asking a model to interpret pixels and click through a human interface adds a translation layer. It works, but it’s slow, expensive, and brittle.
We believe that the web will end up with two interfaces: a visual one for humans and a structured one for agents. You can already see the early scaffolding: llms.txt gives machines a cleaner map of a site, and Chrome’s WebMCP lets a website expose its functionality to agents as structured tools instead of making them guess which button submits a form.
Websites are just one example of this mismatch. The same tension runs through the entire software stack: nearly all of it was designed around a human sitting in front of a screen, and agents are about to become its heaviest users.
Two tests for the agentic stack
When we evaluate any existing software system, we apply two tests to understand where the need for change is most urgent.
The first is the agent-accessibility gap: the mismatch between the existing system and what agents need. A database has a small gap: it was built from day one to be queried by software. A workflow that requires clicking through five screens, interpreting ambiguous controls, and approving each step has a huge one.
The second is agent-driven usage: how much more often agents will use the system than humans did. An agent might run hundreds of searches, generate thousands of intermediate artifacts, and test dozens of implementations in the time a human completes one pass.
Where both are high, the pressure to reinvent is greatest.
The systems on this chart are examples, not an exhaustive map. What matters is where each one falls on the plot: the farther toward the upper right, the greater the mismatch with what agents need, and the larger the expected increase in agent-driven usage. These are the systems that will come under pressure first.
From there, the next question is how radically the system itself needs to change.
At the low end, the existing abstraction works and incumbents will extend it themselves. Search, databases, and APIs mostly need to absorb more agent traffic.
In the middle, the system survives but agents need a new layer through which to use it. That creates room for startups wherever that layer spans products no single incumbent owns.
At the high end, agents break the original design assumptions and the . Here incumbents largely can’t follow, because the rebuild cannibalizes the seats, screens, and workflows they monetize: the classic innovator’s dilemma.
This is where the unmet need is greatest, and where some of the biggest opportunities for early-stage builders lie.
Three opportunities in the agentic stack stand out to us today.
1. Execution environments: from sandboxes to branchable software worlds
An execution environment is the computer and setup an agent works in: the codebase, operating system, dependencies, databases, and services the application relies on. Basic compute sandboxes are already a commodity. As agents make writing code nearly free, the bottleneck moves downstream: not “can the agent make the change,” but “can anyone verify the change actually works.”
That’s why we think the winning product here is Git for complete software environments, not just Git for source code. If an agent modifies a billing workflow, testing in a clean Linux container proves nothing: the change depends on database state, a sequence of Stripe webhooks, a feature flag, a token that expires tomorrow. The agent needs to fork that entire surrounding world as easily as it forks the code -snapshot, branch, test, then merge or discard - without touching production or colliding with the hundred other agents working in parallel.
The opportunities we’re most excited about here:
- Full-stack environments that branch from a known state in seconds
- High-fidelity simulations of the third-party services agents build against - payments, CRMs, cloud APIs - that stay in sync as those products evolve
- Synthetic datasets that keep the hard edge cases of production data without the PII or PHI
- Deterministic simulation that can advance the clock, replay events, recreate the exact conditions of a bug
Our prediction: these environments won’t just be where agents run. They’ll become the review, testing, and release infrastructure for everything agents produce. That’s a powerful position: when agents write most of the code, every change has to pass a validation check before it ships, and the product performing that check becomes the gatekeeper to production.
2. Shared artifact systems: from passive storage to shared memory
Humans coordinate work through file names, folders, and a shared memory of which document is the “real” one. That informal system collapses when hundreds of agents create and modify the same state in parallel: one renames a doc, another copies a stale version, a third builds an analysis on a source that has since been corrected. File systems store bytes and databases store records, but neither knows what an artifact means, where it came from, or whether it can be trusted.
We don’t think the opportunity is another storage engine. It’s a shared artifact layer above the ones we have, where every artifact carries a persistent identity, its lineage, its permissions, and its status wherever it moves.
Take a simple example:
Artifact ID: 7f83d2...
Current name: valuation-final.md
Previous name: valuation.md
Current location: /research/meta/
Created by: Research Agent 12
Derived from: DCF_v1.md
Status: Approved / authoritative
Approved by: Leo
To a traditional file system, these look like disconnected paths and files. To an agent, they describe one evolving artifact. Agents should retrieve work by meaning and authority, branch and merge the same artifact without overwriting each other, and know exactly which version is scratch and which is the record.
Our prediction: this layer becomes the shared memory of the agentic enterprise: the system that decides what agents can trust and what context they receive. That’s a more powerful position than storage alone. Storage is passive. An artifact layer that holds the authoritative version of the work within a business can actively coordinate that work itself.
3. Business process systems: from recording outcomes to capturing decisions
Business process systems are the operational backbones of entire industries: ERPs in the enterprise, EHRs in healthcare, TMS and WMS in supply chain. They do two things: hold the canonical records, and hardcode the workflow around those records as screens, forms, and approval queues designed for human operators.
Both parts break in the agentic era. The workflows were shaped by human constraints - attention is scarce, so work gets batched, queued, and escalated - and an agent forced through the same screens just inherits bottlenecks that no longer need to exist.
But the deeper flaw is what these systems never stored. They record outcomes, not reasoning. The ERP knows the discount was approved; it has no idea who approved the exception, what precedent justified it, or why this customer was treated differently. That judgment lives in Slack threads, meetings, and people’s heads - and it evaporates.
This is why bolting an AI feature onto an ERP or EHR doesn’t work. A copilot reading the same records can summarize faster, but it can’t act autonomously, because the layer it needs - the decision history - was never captured in the first place. And the incumbents are structurally stuck: their revenue is seats and per-user workflows, which is exactly what agent-operated systems eliminate.
The reinvented version treats agents as the primary operators and captures decision traces as a byproduct of the work itself, creating what we’ve called context graphs: systems of record for decisions, not just objects. Salesforce, Workday, and SAP became trillion-dollar companies by owning what happened. Our prediction is that the next generation of business process systems gets built by owning why it happened, and the first movers will be in verticals where exceptions, not rules, dominate the work.
Four questions before you build
Whichever of these systems you’re building - or any other layer of the agentic stack - the same four questions apply, and they’re new to this era.
Who is this agent acting for? Every agent needs an identity and a precise record of what authority was delegated, for which task, for how long.
What is it allowed to do? Policies on data, tools, spend, and human approval have to be enforced by infrastructure outside the agent, not by the prompt.
Can we understand what happened afterward? Every action should be traceable from instruction to outcome, so failures are reproducible and work is auditable.
How much does it cost for agents to do real work? Spend is authority too. Every action burns tokens, compute, and paid API calls, and at scale those costs compound fast. Budgets need to be metered and enforced as hard limits in the infrastructure, the same way permissions are.
Some of these controls will be built into individual systems, some will become shared infrastructure. But any product that gives agents real autonomy needs all four.
The last platform shift rewarded whoever made software easiest for humans to use. This one will reward whoever makes work possible for agents to do. If you’re building one of these primitives, or think we’re wrong about which layers need to be rebuilt, we’d love to talk.
Special thanks to Savin Goyal for his feedback and comments on multiple versions of this essay.