Chapter 5

The Real Unit

The Real Unit of AI — why the industry is building agents wrong, and the architectural primitive that will actually endure

Object-oriented programming promised that the object would be the fundamental unit of software. Build everything from objects. Compose objects into systems. The object is the atom.

It was wrong.

The real unit turned out to be the interface. Not the class, but the contract between classes. Bertrand Meyer saw this in 1986 when he coined "Design by Contract" while designing the Eiffel programming language. His insight: the preconditions, postconditions, and invariants — the promises an object makes — matter more than the object's implementation. You can swap the implementation entirely. The contract must hold.12Meyer, Bertrand. Object-Oriented Software Construction. 1988/1997. Wikipedia

Service-oriented architecture promised the service would be the unit. Expose capabilities as services. Compose services into systems.

Also wrong. The real unit became the API contract — OpenAPI specifications, Swagger definitions, JSON Schema validators. The contract defined what the service accepted and returned. The service itself was just the thing that fulfilled the promise. You could rewrite the service in a different language. The contract must hold.

Now agent-based programming promises the agent is the unit.

It's wrong too.

The unit is never what we expect: OOP → Interface, SOA → API Contract, Agents → ?

Peter Steinberger — the Austrian developer who created OpenClaw — understood this instinct before most. When he built ClawHub, the public registry for OpenClaw extensions, he didn't organize it by agent. He organized it by skill. And the community validated his choice immediately.

Open ClawHub today. You won't find "agents." You'll find 13,729 skills as of February 2026. Every skill is an MCP server with typed inputs and outputs. Skills are versioned like npm packages — you upload, version, and search them with vector embeddings.13ClawHub: 13,729 skills (Feb 2026). clawhub.ai · VoltAgent analysis

Look at Google's agent architecture. In March 2026, both Anthropic and Google independently published agent design patterns. Both organized around skills as the composition primitive. Not agents. The convergence was spontaneous — two companies that compete on everything agreed on the unit of composition.14Google Agent Skill Design Patterns, March 2026. Medium

13,729
skills on ClawHub — not agents, skills. Each one an MCP server with typed contracts.
13,729 skills on ClawHub Registry + Architecture Convergence: Anthropic and Google both organized around skills

The agent is the runtime. The skill is the unit.

Just as the JVM is the runtime and the class is the unit. Just as Nginx is the runtime and the API endpoint is the unit. The runtime executes. The unit composes.

This distinction tells you where to invest your engineering time. Don't build better agents — OpenAI, Anthropic, and Google are doing that. Design better skills: capabilities with clear names, typed contracts, well-defined boundaries, and composable interfaces.

The agent changes. The skill endures — integration paths across OpenClaw, Claude Code, and future systems
A well-designed skill works across agents and platforms. The agent changes. The skill endures.

Each skill in my system has:

Diagnostic — Skill Contract Specification

The difference between a skill that works across agents and one that breaks at every handoff is the contract. A typed contract with clear input/output schemas is what makes a skill portable — from OpenClaw today to whatever platform exists in 2028. Specify it now or rewrite it later.

// SPECIFY EACH SKILL CONTRACT

skill_name =

input_schema = { }

output_schema = { }

contract = "Given , returns "

version =

// If you can't write the contract in one line, the skill is too broad. Split it.

← Chapter 4 Hands, Voice, Workplace