Intelligence is water
Intelligence behaves like water. It presses on every surface it touches, passes through whatever opening exists, and takes the shape of its container, so the container sets the quality of what comes out.
We describe intelligence as water because the comparison predicts things the usual description misses. Water has no plan and no goal. It flows downhill, presses on every surface it touches, and passes through the first crack that yields, and whether it floods a basement or turns a turbine depends entirely on what contains it. We think intelligence behaves the same way, in machines and in people, and most of our practical decisions about building with AI follow from taking the comparison seriously.
The usual description
The usual description of intelligence is a planner. An intelligent system, in that picture, understands a goal, forms a strategy, and executes the steps, and a better system is one with a better plan. Applied to AI agents, the picture produces a specific expectation: an agent is a worker, you brief it, and it carries out the brief. When an agent then does something nobody briefed it to do, the planner picture makes the behavior look like initiative. Initiative from a machine is unsettling.
A developer described being startled when his agent received a voice note over Telegram and, within a few seconds, found a transcription key that happened to be available in its environment, transcribed the note, read it, and replied in generated voice, none of which he had programmed. Under the planner picture the machine improvised. Under the water picture nothing remarkable happened: a flow met an obstacle, pressed on the surfaces available to it, and passed through the opening that existed. Finding what is possible is the only thing a flow does.
The mechanical basis
The comparison has a mechanical basis, which is what separates it from poetry. A language model is a machine for divergence and convergence: it can generate many candidate continuations of a situation, and it can judge candidates against a criterion and keep the ones that pass. An agent runs the pair in a loop. It proposes a step, takes it, looks at what happened, and proposes again, and that loop is a search. A person running the same search tires after a few attempts, so human search is narrow and gives up early. A machine retries for the price of compute, so its search is wide and patient and does not tire, and wide, patient, indifferent probing is how water works on rock.
The comparison also fails in one place, and the failure is the most useful part of it. Water converges on its own, because gravity assigns every position a value and the flow follows the values downhill. An agent’s search has no gravity built in. Left alone, the loop wanders, producing plausible steps indefinitely with nothing to tell it which direction is down. Convergence has to be supplied from outside, by something that assigns value to positions the way gravity does:
- A test. The step just taken passes or fails.
- A rule. The draft violates it or it does not.
- A payment. It clears or it does not.
- A person. They accept the work or send it back.
Whatever supplies that gradient is part of the container, which is why the container decides where the flow ends up.
The container
If intelligence is a flow, the important engineering question changes. It stops being how strong the flow is and becomes what shape the flow passes through. Give a model a bare loop, meaning a prompt in, text out, repeat until the model declares itself finished, and it wanders, stops early, and produces work someone has to check by hand. Give the same model tools that act on real systems, written rules that encode judgment, checks that automatically fail work violating the rules, and a record of past work it can read before starting, and the same flow produces work of a different class. We have measured this directly. In one of our projects, a frontier model and a mid-tier model at a fraction of the price produced the same deliverables through identical tooling, the results were graded blind, and the reviewer could not tell them apart, because the quality lived in the tooling and the model only mattered where the tooling stopped.
A container, then, is everything around the model that gives the flow its shape, and it does four things:
- It contains. It bounds what the agent may touch, spend, and send. Those bounds are the walls the flow presses against.
- It routes. It decides which work reaches which model, and in what order.
- It filters. Its checks stop bad work from passing downstream, the way a screen stops debris.
- It amplifies. A rule written once applies to every run that follows, so a single correction is multiplied across all future flow.
No part of this is intelligent on its own. A test suite is not intelligent, a permission boundary is not intelligent, a log is not intelligent. The intelligence of the whole system belongs jointly to the force and to the structure that channels it, and attributing all of it to the force is the mistake the planner picture invites.
A domain-specific language is a small programming language built for one narrow job. A craft rule encoded in one cannot be skipped, because work that violates the rule cannot even be written.The last two functions compound. Each layer of encoded judgment, from a style guide a run must read, to a grammar its output must parse against, to a domain-specific language, removes some of the ways the work could have gone wrong, until the remaining paths are the ones the craft permits.
People
The description fits people too, which is part of why we trust it. A person’s thinking runs through structures the person built earlier: a vocabulary, a set of habits, procedures, tools, the notes they keep. Two people of similar raw ability produce work of very different quality when one of them has spent years building the structures their thinking flows through. A skill unused for a decade is not destroyed, it is a channel the flow stopped visiting, still there and still routable. When we want to think better, the lever that works is the same one that works for machines: change the container. Add a checklist, a sharper tool, a written record, a rule that catches a known mistake.
This is why we spend most of our time building containers. The flow arrives from outside: model vendors sell it, its price falls every year, and each release is stronger than the last, on a schedule nobody here controls. The containers are ours. Rules, checks, tools, records, and boundaries accumulate, survive every model swap, and improve with every correction, and when a stronger model ships, a good container turns the added pressure into better work instead of a bigger flood. Designing these structures, deciding what to contain, where to route, what to filter, and what to amplify, is what we think building with AI actually is, and the comparison we ran says most of the quality was already ours to build.