# 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. This is a long-horizon bet. The near-term reality is hybrid: every product worth building is a thoughtful mix of paradigms, decomposed by sensor / logic / actuator. ## Related - [[Andrej Karpathy]] - [[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]]