← erik list

Specifications for a superproductive company

v0.2 · 25 July 2026

Superintelligent AI forces us to fundamentally rethink how organizations are structured to produce goods & services.

The thesis: radically different organizations will emerge. These companies will be superproductive, and they will transform the economy & society.

This document specifies the principles behind such a company, and the company that results from them.

The organization is rebuilt around a given product from the ground up

The core principle is to rebuild the organization around a given product from the ground up. A value chain structured around superproductive AI agents should produce any product at significantly lower cost and with far higher capacity.

Timeline & applicability vary across products, but the principles stay the same.

The company is built like a software application

The clearest way to think about this company is as a software application. Its actors are agents that start on events, run, and stop, like processes. Its state is one shared memory every agent can read. Its outputs are files in git. Its access control is a permissions file. Watching the company means reading its records; steering it means writing into them. The shared memory, git history, gate results, and purchase records together are a full account of what the company did.

An agent is a Claude Code instance with identity, permissions, and its own computer

Principle. An agent runs on a strong model and harness, has its own computer with broad freedom (files, shell, browser), and acts on its own. It uses a programmatic path where one exists and the browser as the fallback when one does not. Each agent has an identity, can read the shared memory, and is limited by a permissions file. Its identity (who it is, what it may access) is stored in memory but write-protected: only the control app can change it.

Minimum now. A Claude Code instance with a role description, a permissions file, read access to the shared memory, a git checkout, and a scoped payment card when it needs to buy something. Claude Code is the only harness for now.

One shared memory holds everything, and every agent can read it

Principle. One log holds every event, message, action, and output. Every agent can read all of it. A simple index sits on top for fast lookup. Identity and permissions live in memory as write-protected entries. Git history is the record for code and outputs.

Minimum now. An append-only log that agents write to and read from, plus a basic index. Better retrieval and summaries come later.

Agents communicate by reading and writing, not through a protocol

Principle. Agents talk by reading and writing, not through a separate protocol. Reading means following another agent's stream, its files, or the shared log. Writing means adding to the log, editing files, or putting a message into another agent's stream. An agent that receives a message decides for itself how to act on it, the same way a person steering a Claude Code session inserts a message and the agent decides what to do. A permissions file scopes what each agent may read and write.

Attention is open. Agents choose which streams and files to follow. We do not decide this for them now.

Outside the company. To deal with agents or services that are not ours, use whatever they offer (a website through the browser, or a public agent standard). Inside the company, it is only read and write.

Events start agents; continuity lives in memory, not in running processes

Principle. Agents are started by events, not left running idle. An agent can start other agents. A role says what an agent is responsible for and what it may touch, not a character that runs forever. Continuity comes from memory, not from keeping a process alive.

Minimum now. An event starts an agent; it does its work, writes results to memory and git, and stops. It can start child agents, each with its own identity, memory access, and permissions. We define a small set of roles, just enough for the first product. Starting and stopping agents are permissioned writes.

Every output is code in git and ships through a gate

Principle. Every output is code in git. Nothing ships to a customer or merges into the company's own code without passing a gate.

Minimum now. Git repos and pull requests. The gate starts as automatic checks (build, tests, lint, format, schema). It grows later to include review by another agent and human sign-off for risky changes. Concurrent writing uses git branches and merges. Every gate result is recorded.

Agents track their work in a project management layer on top of git

Agents track work in a Linear-style layer on top of git: initiatives hold projects, projects hold issues, issues hold sub-issues. Agents create work at every level and decide what deserves an issue. Statuses (backlog, in progress, in review, done, cancelled) and written project updates show humans where things stand. Links to branches and pull requests are voluntary; where they exist, status follows git. Where the structure lives is left open; it must be readable and writable by both agents and humans.

Agents buy the way people do, with spend controlled by scoped cards

Principle. Agents buy the way people do, through a website or app with a card, because almost no service offers agent-native payment yet. The browser drives the checkout. Spend is controlled by the card, not the website: each agent gets a scoped virtual card with limits set when it is issued. Where a service does offer agent-native payment, use it.

Limits now. 10 EUR per agent per month and 200 EUR for the company per month. Anything above needs human approval. Every purchase is written to memory.

The control app is where humans watch, steer, and stop the company

Principle. People use the control app to watch the company, steer it, set policy, approve spend above the limit, approve changes to the company's own code, and stop it at once.

Minimum now. The projects and issues view from the project management layer as the primary view of where work stands; a view over the shared memory at company, product, agent, and run level; a way to write a steering message into any agent's stream; an editor for policy and permissions; a queue for spend above the limit; an approval step for pull requests that change the company's own code; and a kill switch that stops new actions. The app does not promise to undo past actions; it supports compensation and stops new ones.

Changes to the company itself need human approval

Principle. The company can improve its own code, but a change to its own code, policy, or identity is a pull request a human approves. Work on products follows the normal gate; changes to the company itself need human sign-off.

Human involvement is reduced to a small, fixed floor

The only work that stays with a human:

Everything else is built to run without a human, and we measure how close we get.

How the company sells and advertises emerges from the agents

Principle. How the company sells, brands, and advertises is not fixed in advance. It emerges from the agents working on it, within budget and policy. The control app gives people a way to bias and watch this, not a set of fixed numbers.

The legal structure is the simplest entity with one human signing

Principle. The simplest limited-liability entity with the least complexity and an adequate, not optimized, tax setup. One human signs. Details come later; this is not an engineering concern for v1.

The rest is deliberately left to emerge

We deliberately do not fix these now: