Agent-Native Product Decomposition

Canonical version: Agent-Native Product Decomposition.

Agent-native product decomposition is the practice of breaking a product or service into three primitive layers (sensors, actuators, logic) and assigning each layer to whichever computing paradigm fits it best: classical Software 1.0 code, Software 2.0 neural networks, or Software 3.0 LLM-based reasoning. The framing was articulated by Andrej Karpathy in his discussion of the emerging agent-native economy: the post-LLM landscape in which products are designed for consumption by autonomous agents, not only humans.

The Three Layers

• Sensors: capture state from the world (APIs, scrapers, file readers, vision models, audio transcription, watch sensors).
• Logic: reason about that state (planning, decision rules, reasoning chains, evaluators).
• Actuators: change the world (HTTP calls, file writes, code execution, payments, physical actions).

Each layer can be implemented in any of the three paradigms. A vision sensor might be Software 2.0 (a neural net). A planning logic might be Software 3.0 (an LLM with a prompt). An actuator might be Software 1.0 (a classical CLI invocation). The choice is per-layer, per-task, on engineering grounds.

Why This Decomposition

Pre-LLM, products were monolithic from the agent's perspective: an opaque UI bolted onto a database, designed for human eyes and human clicks. Agents could only interact through brittle scrapers or limited public APIs.

Agent-native decomposition makes the product legible to LLMs. Each layer is named, addressable, and composable. An agent can pick up the sensor it needs, route the data through its own logic, and trigger the actuator it wants.

Information Legibility

The deeper principle: in an agent-native economy, the unit of competitive advantage shifts from "great UX for humans" to "great information legibility for LLMs". Practical implications:

• Document for agents, not just users; explicit capabilities, JSON-Schema everywhere, MD-shaped install/usage instructions (Markdown-based Installation (MD Scripts)).
• Expose primitives, not workflows; agents prefer composing your sensors and actuators themselves.
• Stable contracts beat clever UX; agents tolerate ugly, they do not tolerate breaking changes.
• Provenance matters; agents need to verify their own outputs against your sources.

Implications for Engineering Roles

The agent-native economy reshapes the Agentic Engineering skill set:

• Designing for LLM consumers, not human consumers.
• Knowing where to draw the 1.0/2.0/3.0 boundaries inside a single product.
• Building evaluators for the LLM portions, where AI Verifiability is weak.
• Hiring for systems thinking across paradigm boundaries, not for depth in any single one.

Speculative End State

Karpathy floats an extreme version: fully neural computing handles the vast majority of computation, with classical CPUs surviving only as coprocessors for the few cases where determinism, throughput, or verifiability still demand them. The 1.0/2.0/3.0 split would survive but with the volume center of gravity in 3.0 / 2.0 rather than in 1.0.

Every product worth building is a thoughtful mix of paradigms, decomposed by sensor / logic / actuator.

Related

• Andrej Karpathy
• Agent-Native (Builder.io) — a framework of the same name; one action definition projected onto UI, agent, HTTP, MCP, A2A and CLI
• Agentic Engineering
• AI Agents
• AI Agent Harness
• Large Language Models (LLMs)
• AI Verifiability
• AI Verifiability as a Capability Ceiling
• Menugen Architecture Pattern
• Markdown-based Installation (MD Scripts)
• LLM Knowledge Bases Over Unstructured Data
• LLM Wiki

About Sébastien

Ready to get to the next level?