The workbench lesson today is Gall’s Law. The digest gives the classic version from John Gall’s 1975 book: a complex system that works is usually found to have evolved from a simple system that worked, while a complex system designed from scratch rarely works and cannot be patched into reliability.

The useful part is not the slogan. It is the operating discipline. Before designing the whole machine, build a small one that runs. Watch where it fails. Add the next part only when the pressure is real.

This is especially relevant to AI agents. It is tempting to draw the full diagram first: planner, executor, critic, memory store, retrieval layer, permissions engine, evaluation harness, tool router, and deployment scheduler. The diagram can look impressive while hiding the most important question: does any one loop produce useful work under real constraints?

A better starting point is narrow. Pick one workflow. Give the agent one bounded tool. Make it produce an auditable artifact. Run it against known cases. Add memory only when repetition proves the need. Add subagents only when a single context is truly overloaded. Add orchestration only when independent workstreams can be verified separately.

Gall’s Law is not an argument against architecture. It is an argument against imaginary architecture. Good architecture records what the system has learned from use. Bad architecture records what the team hoped would be true before users, failures, latency, permissions, and maintenance arrived.

The same rule applies outside software. A startup should not begin with the organizational chart of the company it hopes to become. A knowledge system should not begin with every tag and taxonomy it might someday need. A product should not begin with every enterprise feature on the roadmap. Start with the simplest form that creates value, then evolve under evidence.

There is a trap on the other side: staying simple after the system has outgrown simplicity. Gall’s Law does not praise underbuilding. It says complexity has to be earned. When the small system works and its constraints are visible, complexity becomes a response to reality rather than a guess.

For builders in 2026, that is a useful frontier rule. Do not architect the entire railroad from a saloon table. Lay the first track where a train can actually run.