Agent-Native Infrastructure

Sources#

Andrej Karpathy: From Vibe Coding to Agentic Engineering
DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501
OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts

Summary#

Andrej Karpathy's observation that the digital world is still built for humans and must be rewritten for agents. His "favorite pet peeve": documentation written to instruct a person. "Why are people still telling me what to do? I don't want to do anything. What is the thing I should copy-paste to my agent?" The agentic-native world decomposes work into sensors over the world and actuators over the world, with everything "described to agents first." It ends in agent representation for people and organizations — "my agent talks to your agent to figure out the details of our meetings."

The copy-paste-to-agent install#

The concrete seed (shared with Software 3.0): installing OpenClaw isn't a shell script, it's a block of text you paste to your agent, which then inspects your environment and debugs in the loop. Generalize it: the unit of distribution for agent-native software is a prompt/skill, not an executable. Docs, configs, and setup flows should ship as "here's what to hand your agent," not "here are the steps you perform."

Sensors and actuators#

Karpathy reframes agent infrastructure in robotics terms: decompose any workload into sensors (legible inputs the agent can read) and actuators (actions it can take), then make the surfaces agent-legible. He pairs this with heavy investment in "data structures that are very legible to the LLMs." The design question shifts from "what UI does the human need?" to "what does the agent perceive and what can it act on?"

The deployment friction tell#

His MenuGen test for whether infrastructure has gone agent-native: the code wasn't the hard part — deploying on Vercel was (DNS, service settings, menus, stringing services together, "so annoying"). The dream: "give a prompt to an LLM, build MenuGen, and I don't have to touch anything — it's deployed on the internet." When that round-trip needs zero human GUI-clicking, infrastructure has become agent-native. (Connects to MCP and Computer Use: MCP makes services programmatically agent-legible; computer use is the fallback when they aren't.)

The endpoint: agents representing principals#

The extrapolation is agent representation for people and orgs: scheduling, negotiation, and coordination done agent-to-agent. "I'll have my agent talk to your agent to figure out the details of our meetings." This is the social-protocol layer of an agent-native world — and the surface where AI Employee Framing / Human-AI Accountability Redesign questions (who is accountable for the agent's commitments?) become live.

The inverse case: an environment that was accidentally agent-native (DHH, August 2026)#

This page's premise is that the human-built world must be rewritten for agents. DHH supplies the counter-instance and it is the most interesting thing in the corpus about this concept: desktop Linux needed no rewrite, because the properties that made it hostile to humans are the properties agents want (Lex Fridman #501, 2026-08-26, practitioner-opinion; note that he ships a Linux distribution, so this is analysis and product positioning at once).

Four properties, none designed for this:

Everything is a config file or a CLI tool. "Agents love the Unix philosophy… there is no operating system on Earth of the majors — Mac, Windows, Linux — that works as well with that mechanism as Linux. Now, that was its main drawback five minutes ago." Karpathy's sensors/actuators decomposition already exists on this platform; nobody had to build it.
Arcane error messages become an asset, not a liability. "The agent can take that very specific error message that makes no sense to a normal human and correlate it with the fact that the agent was pre-trained on 40 million lines of Linux code, so it knows exactly where to look." Specificity that was unusable without the source is usable with it.
The source of every installed component is available. "The agents know the source code of not just the Linux operating system, but every single piece of software I have on that box." An agent debugging a macOS app is reasoning about a black box; the same agent on Linux reads the crashing binary's source. He ships this as a feature — Omarchy Quattro has a crash watcher that offers to have an agent diagnose any app crash from the systemd log down to the offending source line, then file the bug report.
The whole machine is reproducible from text. His complaint about the alternative is concrete rather than ideological: macOS default key bindings and Raycast configuration cannot be automated at all — "you're clicking with a mouse like a caveman."

The generalizable claim is a selection rule this page currently lacks: an environment is agent-native to the extent that its state is text, its actions are commands, and its internals are readable. GUI-configured, closed-source, per-machine-clicked environments are the ones needing the rewrite; the ones that never made the concession to human ergonomics are already done. Whether that predicts adoption — his stronger claim, that this is why Linux finally takes the desktop — is a forecast, and he is selling the forecast.

The endpoint he draws from it belongs on this page too: if the OS is text and commands all the way down, the OS itself becomes the thing you vibe-code. Omarchy ships a set of skills telling any agent how to write plugins against the desktop, and produced 330 community plugins in three days (Open Source Under Agent Contributions). "When you can vibe code whatever app comes to your mind, you should be able to vibe code your operating system."

Connections#

Andrej Karpathy — the "docs written for humans" pet peeve
Software 3.0 — the copy-paste-to-agent install is 3.0's distribution model
MCP and Computer Use — MCP = structured agent-legibility; computer use = the GUI-driving fallback for non-agent-native services; both are the substrate this concept demands
Agent Harness Engineering — building agent-legible environments is the harness-engineering discipline at the infrastructure layer
Agent Loop Pattern — always-on agents acting via sensors/actuators are the runtime of an agent-native world
Hermes Agent — a concrete agent-native daemon (AGENTS.md context, gateway connectors) bridging chat surfaces to agent actuators
AI Employee Framing — "agents representing principals" raises the accountability questions of treating agents as actors
Living Design System — design_system.html is an example of making a codebase machine-legible (and human-legible) at once
Claude Code — the agent that consumes copy-paste skills and drives computer-use actuators
Agent Identity Management System (AIMS) — a concrete proposal for the "trust, identity, and accountability primitives" the agent-to-agent endpoint needs: workload identifiers, delegated authorization, and end-to-end audit composed from existing standards (see the open question below)
Open Source Under Agent Contributions — what an agent-legible platform does to its own contribution pipeline: skills shipped in the box, 330 plugins in three days, agents triaging the result
DHH (David Heinemeier Hansson) — the practitioner arguing desktop Linux was accidentally agent-native, and shipping the distribution that bets on it

Open Questions#

Who builds the agent-native rewrite of the long tail of human-facing services — the service owners, or a translation layer (MCP servers, computer-use agents) on top?
Agent-to-agent negotiation needs trust, identity, and accountability primitives that don't exist yet. What's the protocol layer, and who governs it? Partially answered: AIMS (IETF draft-klrc-aiagent-auth-03) proposes the protocol layer — agent-to-agent is just workload-to-workload, so WIMSE/SPIFFE identifiers, OAuth 2.0 delegation + token-exchange chaining, and OpenID Shared-Signals eventing (drawn from IETF/CNCF/OpenID) supply identity, delegated authority, and auditable accountability; a tool endpoint "may itself be implemented by another AI agent." But who governs it stays open: AIMS is an individual submission with no IETF WG consensus, profiling a stack of specs that are themselves still Internet-Drafts — the primitives are proposed, not ratified or arbitrated. Sharpened (2026-07): the who-governs-it answer is concretely plural — the identity/authentication/delegation slice is IETF-track (AIMS), while the authorization slice is OpenID-Foundation-track: its AuthZEN Working Group approved the AARP (a prerequisite/approval pattern generalizing CIBA — "not yet, here is what is required") and COAZ (MCP-tool-authorization) profiles as Working Group Drafts on 2026-06-15. So the protocol layer is being standardized across multiple bodies (IETF for who-you-are + how-authority-delegates; OpenID for whether-a-call-is-allowed + what-must-precede-it) — moving, but with no single arbiter and no ratified cross-body composition yet. (Standards-announcement, practitioner-opinion — proposed drafts, not settled specs.)

Sources#

DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501 — DHH, Lex Fridman #501 (2026-08-26, practitioner-opinion, distro-vendor COI): the accidentally-agent-native argument for Linux — config-file/CLI surface, arcane errors made legible by pretraining, source availability, text-reproducible machine state; the crash-watcher and plugin-skill implementations
Andrej Karpathy: From Vibe Coding to Agentic Engineering
OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts — OpenID Foundation, …advances authorization for the agent era with new AuthZEN Working Group Drafts, 15 June 2026, practitioner-opinion. Evidence that the agent-to-agent authorization protocol layer is being standardized (OpenID AuthZEN WG: AARP + COAZ Working Group Drafts), plural alongside IETF's identity/delegation work — the governance-plurality half of the open question above