Container Design

What It Is

A container is a bounded context — a gym, a timer, a walk, an OBS recording session, a work-only laptop, a job — that constrains which types of activity are possible inside it and bends the probabilities of the ones that remain. The container is the unit of behavior design. Not the goal, not the habit, not the willpower budget: the boundary. You do not decide your way into good behavior; you enter an environment inside which good behavior is what tends to happen.

In computational terms: a container sets the macrostate boundary conditions within which your behavioral microstates get sampled. If intelligence is water, the container is the riverbed applied to your own behavior — the same move as designing a DSL for an AI agent, pointed at yourself. You are the flow; the container is the terrain that decides what the flow does.

Will's definition, from the June entry where he noted "if ever I were to write a book" this would be in it:

"It's a special environment that constrains the types of activities possible and enforces rules about those activities — when, where, how often. It increases probabilities of certain activities... like enzymes interacting because of regulated temperature."

The enzyme image is the load-bearing one. A cell does not command its chemistry; it maintains a membrane and regulates temperature, and the reactions follow. "The container is like a cell. The container is the thing that creates the environment... everything is about container. It's container engineering."

Environments Are Runtimes

An environment is not a backdrop. It is a runtime: it loads scripts and executes them, mostly without consulting you.

"Home is a bad runtime that reloads YouTube / porn / drift scripts, while outdoor walking creates generative thought that feels endogenous rather than injected."

This is Will's observed mechanism, and it holds with embarrassing reliability. The urge to watch YouTube, the pull to lounge, the fap loop — these are state-dependent programs. "This environment — my home — feels suffocating... activates the YouTube state." "As soon as I enter home, it's time to go to sleep." Step outside and the same programs simply are not loaded; the addiction did not get weaker, it got unlinked from its runtime. This is the buffs and debuffs observation formalized: the environment is applying modifiers to every action's probability, whether or not you designed them.

Two corollaries. First, luxury gets redefined:

"Luxury is runtime execution — not owning the thing, but having an environment where the thing actually runs."

Owning a squat rack that sits unused is not luxury; a gym where training actually executes is. Second, the test is strictly empirical. It does not matter what should work on paper — "Even if something logically makes sense, reality has variables you are not accounting for. The real test is empirical: is it actually working? Am I actually going to the gym regularly or not?" A container is validated by execution counts, nothing else. That is reality contact applied to your own architecture.

The canonical N=1 case is the April gym switch. The home-adjacent option kept failing; the fix was not more resolve but a different runtime — Fitness SF, reached by a walk, filled with selectorized machines:

"My mental state is like a microstate within the gym environment. The macrostate is the selectorized machines, which bend the probability that I will pick something up and stay with it."

Machines as terrain. The environment increased the probability of certain actions "until those actions dominate." No script was willed; the runtime executed it.

Freedom Needs a Container

The counterintuitive half of the thesis: freedom is not the absence of structure. Freedom without a container diffuses — a gas expanding to fill whatever space it is given, doing no work.

"Every time I hear the word 'freedom' I should think 'needs container' — because freedom means desire to explore these microstates, but then we have to construct those macrostates to make sure that it converges."

"You know what I learned is freedom is bad. Total freedom is bad. It leads to YouTube."

People discount containers "because they compare to their willpower" — they imagine the free agent choosing well in open space. The observed mechanism is the opposite: the open space itself selects the low-cost attractor. The move that preserves both freedom and convergence is bounding, not commanding — Will's own framing of shaping behavior for others: "I'm not controlling, I'm shaping their environment. They still have autonomy... you unlock layers of trust." Full microstate freedom, engineered macrostate.

The distinction underneath all of this deserves its own name: enablers vs attractors. An enabler makes a state possible; an attractor pulls behavior into it. Freedom, capability, resources, runway, free time — all enablers. The chronic mistake is treating an enabling configuration as if possibility itself pulled. It does not: possibility supplies no reduced branching, no automatic next action, no pull — and in an enabler-rich, attractor-poor life, the pull gets supplied by whatever is lying around. The diagnosis was made from inside the fantasy configuration — runway, unlimited time, equipment in the house — while still leaking:

"The conditions are perfect, but they're enablers. They're not attractors. The right configuration exists, inhabiting this right configuration also exists, but it's too leaky. I need to define the right configuration or the right macro state."

Every container in this article is attractor machinery: the thing that converts an enabled state into an inhabited one.

The strongest evidence came from the most extreme container: the psychedelic session, where set and setting are everything —

"It's not just the timing — it's also about location, it's about the clothes you wear, it's about your plan."

"It felt like I could rewrite myself. It felt like, because of the container, I could rewrite myself... I feel like I am exporting that insight into all the domains of my life."

And the endgame of a good container is that it deletes effort from the accounting entirely:

"I like to do things where I don't think about it, and it just adds up. If I can construct the container, then I can just live on with my life. It doesn't have to feel like I am doing anything that adds up. That's the big idea: construct a container."

Ambient living inside the right boundary compounds without registering as work. The container pays the activation energy once, at the boundary, instead of continuously inside it.

Leakiness and the Vacuum

"Too leaky" is the precise failure word. An enabler-rich configuration without attractors does not fail dramatically; it leaks — the day drains out through a thousand unpulled moments, and where the pull goes instead is fully determined by topology: the strongest container wins by default. The declared main quest can even rank above the day job on paper — the greater goal that supposedly determines the side quest — while the job's pre-built container owns 9-to-7 and the main quest loses every evening to the feed.

A job wins the day not because it is most important but because it arrives with wake pressure, place, people, cadence — a pre-built container. Priorities are declared in the head; days are allocated by containers. Rank means nothing until containerized.

The sharpest version of the leak is the vacuum after a completed macrostate. When an emergency container ends — the deadline ships, the job ends, the crisis resolves — no replacement container automatically loads, and the open schedule is inherited by the strongest remaining attractor:

"The old emergency container disappeared and no replacement work container automatically loaded, leaving feeds as the strongest available attractor."

The failure is topological access plus an unclaimed schedule, not lack of knowledge — the person in the vacuum knows exactly what they should be doing. Container transitions are therefore a design surface of their own: the end of any container is a scheduled event, and the replacement must be built before the vacuum opens.

The same diagnostic works in reverse. The attractor-state section below requires capture systems for flow; the mirror hole is capture without ignition — a perfectly instrumented surface that nothing pulls you into. Running the same engine on two task boards localized it exactly: a burst of finished work in 48 hours proved throughput exists when a container does, while "the personal board has capture without ignition." Dead time appears because the next task is undefined and must be generated at the moment of maximum weakness — solved wherever a container exists, unsolved wherever one doesn't.

Constraint as Discovery

If enablers don't pull, they also don't teach. The counterintuitive corollary, learned from a five-figure pile of cloud credits that sat idle:

"I can't proceed from capability... I can only proceed from constraint. I need to discover it through constraint, walking through those constraints... It's almost like a principle: you can only discover what you need via the constraints."

Abundance expands the possibility space without collapsing it into action; resources are illegible until something forces contact with their absence — "the function of a resource becomes clearest at the edge of its absence." The real state variable is not resources but resources × urgency: "I had the resources but no urgency, but now I have no resources and I have urgency" — and the second state is the more productive one. The design problem is covering the floor without the safety net infecting the brain.

The constrained environment is also where priorities get discovered rather than declared:

"If I had boundless free time and endless options, I would do anything, but the constrained environment forced me to discover and decide what was actually important."

This is the deepest sense in which a container is not a cage: the boundary is the instrument that reveals what the enabled resources were even for. Freedom shows you nothing; the wall you walk along shows you the shape of what you need.

A Container Taxonomy

Containers are not only rooms. Anything that draws a boundary around activity types is one — "the AI is a container, your workflow is your container, your environment is your container." A working taxonomy:

Two properties cut across all six. First, every real container answers three questions — when, where, how often — before you have to. Second, the boundary must be perceptible from inside: a timer works not because it measures time but because "it's a container that implicitly says: I am currently in the mode of doing this." A boundary you can't feel is a boundary that isn't voting.

The Occupant Enforces the Boundary

A boundary is not enforced by the rule that declares it. It is enforced by its occupant.

"An empty boundary is a fence around nothing. It has no defender. The occupant is the enforcement mechanism."

An empty time block is indistinguishable from free time — the label does not resist YouTube. The search process that is evening behavior expands into whatever space is actually unoccupied, and a block containing nothing is unoccupied, whatever the calendar says. But once the thing is physically present in the block — the lesson loaded, the gym entered — the boundary stops being a rule to remember and becomes a state you are already in. The ledger flips: exiting an occupied block has a cost (abandoning something in progress); entering an empty one had none. Enforcement therefore costs one unit of ignition at the start of the block, not continuous willpower at every temptation.

Will derived this trying to make his day-schedule boundaries hold — mornings for the body, evenings for contract work and Korean — and explicitly rejecting both standard framings, willpower ("protect your time") and mysticism ("do or do not"): "I felt like this could be given more specificity without resorting to mysticism to seem wise." The mechanism also post-dicted every schedule he had ever drawn that decayed:

"The block existed on paper before the practice existed in reality. I was building fences first and hoping the livestock would show up. The order is backwards. Practice first; the boundary condenses around it."

The repair rule follows: a decaying boundary is an empty one, not a weakly defended one — so the fix is fill the block, never guard it harder. Guarding harder is the willpower framing sneaking back in; occupancy is the architecture. This is also the standing requirement on any dashboard or control plane over your containers: it must not just display the blocks but keep their occupants warm, because a parked thread defends nothing. A boundary is not a fence you guard. It is the shape of the thing living inside it.

Attractor-State Design

Most behavior design attacks the start: lower the cost to begin (see ignition). Attractor-state design attacks the other end: engineer activities where stopping is the expensive decision.

The discovery came from the unplanned 9-hour walks. "I explicitly said, 'I'm going to stop at three hours,' but then I just continued onward." Why?

"The reason why I continued to walk was because at one point, I would have to decide to go back. Walking is one of those things where once you start, it's hard to stop — because you have to go back. And the further you are, the harder it is to go back."

Sit at a desk and continuing costs a decision every minute. On a walk the ledger is inverted: continuing is the default; stopping requires a conscious choice, plus an uphill return or a flow-breaking taxi. Momentum is structural, not willed. And the generalization:

"That's how we need to create those attractor states for things that are naturally productive. Go out and find the things where you can continue for hours — because, just like walking, they convert into productive energy when you have the systems that convert it."

Note the second clause: the attractor only counts if capture systems exist. The walk converts into output because the Plaud is recording; hours of flow with no capture is just weather. (This is why recording infrastructure matters — see agent body for the machine version of having surfaces that persist what the flow produces.)

The design rule compresses to one line:

"If you want to do something for a long time, just make it hard to stop. Make it hard to stop and also make it fun to continue. It's just about the environment engineering."

Distance and ritual boundaries do the work — the walk to the gym, "a ritualistic boundary such that when you go there, you just want to stay there." Easy exits guarantee collapse: the home gym downstairs fails precisely because leaving costs nothing.

The physics of why the hardest pull wins is not special to behavior: it is Boltzmann selection over an energy landscape (gradients), with the thresholds priced in activation energy — an attractor state is a locally deepened well, dug on purpose.

Mode-Lock

Mode-lock — Will's extreme behavioral inertia, the bidirectional lock-in that holds a captured mode in place for hours, casts identity votes, and collapses whole behavior stacks when its anchor is removed — has its own article. What belongs here is the container's role in the mechanism: a container is a mode-lock initializer. Entering the boundary loads the mode ("as soon as I just enter the gym for like five minutes, I flip my mind to: oh, I'm a gym person"), and the boundary's exit cost keeps the mode from being preempted. This is the behavioral counterpart of attention routing — the container routes attention once, at entry, instead of re-routing it every minute; in state machine terms, the container raises the cost of the exit transition until the state is absorbing. Because the lock is valence-blind, choosing the container is choosing what the lock fires on — which is most of what "engineer the lock deliberately" means in practice.

Pressure Needs Structure

The standard performance folk-model says pressure produces output. Will's backtested result is the opposite:

"I do not work well under pressure. I work well under structure for that pressure to channel through. If I don't have the structures available to me, pressure is not going to solve it. Pressure gives you impetus to create those structures."

"I don't want pressure. I want structure. Structure is good because it still allows freedom — I need a structured schedule where my time is allocated, and then I have the freedom within it."

Deadline pressure, financial pressure, doom-content urgency — all of it degrades performance when it arrives without channels: "watching [doom content] gives me urgency without structure. Structure means: do I know what the rest of the day is going to look like?" Pressure is hydraulic. Against a turbine it is power; against an unstructured day it is just stress on the walls. The only legitimate role of pressure is as the impetus to build the channels it will flow through — and once structure exists, "you can amp up the intensity."

This reframes institutions. What do school and jobs actually sell?

"I'm wondering how much structure school actually gives you. How much structure does a company actually give you?... What is actually needed when you need to design your own structure? I would like to study what type of structures school gives you, or your job gives you."

Structure as a service. "That's one of the things that feels scary when you're out of school, out of an accelerator program, when you don't have VCs — when you don't have structure." The founder's hidden second job is being his own scaffolding department; a job's hidden compensation is pre-resolved ambiguity ("you get to see what happens when all the ambiguity is taken care of for you — the world does not need to be so scary"). And the honest N=1 read: "I feel like I am actually super successful within structures — that's why I excelled at school as a kid." The conclusion is not "go back inside institutions"; it is that the containers institutions provided must be replaced deliberately, one by one, or the freedom they leave behind diffuses.

Designing Containers for Others

Container design scales past N=1, and doing it for other people is where the ethics of the mechanism become visible. The naive alternatives are command ("do this") and laissez-faire ("you're free"). Both fail for the same reasons they fail on yourself: commands require continuous enforcement; total freedom diffuses. The container is the third option:

"I'm not controlling, I'm shaping their environment. They still have autonomy... you unlock layers of trust."

The person keeps full microstate freedom — what to do, in what order, with what style — inside a macrostate someone competent bounded for them. This is what a good manager, parent, or teacher actually produces, and Will's engineering version is explicit:

"I can help them construct the container where they can feel the most productive... a senior engineer should design a container for the other engineers to go in with AI."

Seniority as container authorship: the senior engineer's leverage is not writing more code but bounding the space — the harness, the conventions, the verifiers — inside which less-experienced engineers plus AI produce good work by default. The same role the selectorized machines play at the gym.

The obligation that comes with authorship: containers are person-relative, so a container imposed on someone it doesn't fit is just a cage with good intentions. The prison observation below is the standing check.

Failure Modes

Free time arriving before a protocol. The sharpest formulation of container failure:

"I do not really hate time itself. The problem is free time arriving before a protocol does. When unstructured time opens up without a preassigned macrostate, discretized menu, and low-friction first move, it diffuses into low-cost attractors and later registers as regret. The solution is to build containers that catch time the moment it opens."

Uncontained time is not neutral; it is pre-claimed by the lowest-energy attractor in range.

The container becomes a prison. Containers are person-relative and season-relative:

"It was interesting watching the same container that is helping me become a prison for somebody else."

The boundary that channels one person's flow cages another's. There is no universal container — only fits. Audit whether yours are still channeling or have started confining.

Weak containers get routed around. Your appetites are also water: "mind and body adapt to whatever constraints are truly enforced; addiction will route around weak constraints." A container with a known bypass is a marked crack, not a wall. Enforcement is a property of the boundary, not of your intentions about it — the prevention architecture principle.

Mode-lock on the wrong attractor. The lock-in mechanism is valence-blind: if the runtime you inhabit auto-loads YouTube, mode-lock will faithfully hold you there for two and a half hours. Bidirectional means bidirectional.

Enablers mistaken for attractors. The configuration is perfect and nothing happens. Runway, free time, equipment, and access make states possible; none of them pull. A life audit that inventories enablers and finds no attractors has found the leak.

Confusing pressure for a container. Deadlines feel like structure because both come from outside. They are not: a deadline is pressure without terrain. If a burst of urgency is your only container, expect shutdown, not output.

Building Containers

The practical loop, distilled from the April–June record:

1. Inventory your runtimes. For each recurring environment, list what it actually auto-loads (empirically — what happened last ten times, not what should). Home, desk, gym, phone-in-hand, walk.
2. Match activity to container, never to willpower. The question is never "will I do X?" but "inside which boundary does X execute?" If no such boundary exists, build one before attempting X again.
3. Set the boundary conditions, free the interior. Constrain when/where/what-type; leave the microstates open. Enzymes need regulated temperature, not choreography.
4. Engineer the exit cost. Make stopping the expensive decision — distance, ritual boundary, session framing. Declare the mode at entry (a timer "implicitly says: I am currently in the mode of doing this").
5. Wire capture systems. An attractor state only compounds if its output is recorded — dictation on walks, commits in sessions, logs in tracking.
6. Validate empirically, replace ruthlessly. Execution count is the only metric. A container that isn't executing is terrain to route around, not a resolution to renew.

Entry into a container can itself be scheduled — anchored to zeitgebers so the boundary crossing happens on external rhythm rather than daily deliberation.

A day rebuilt this way stops being a to-do list and becomes a sequence of containers, each handling its own class of work:

Nothing on that list requires a decision at execution time. The decisions were all made once, at design time — which is the entire point. Willpower is spent authoring boundaries, not enforcing them.

Integration with the Mechanistic Framework

Connection to Intelligence Is Water

The parent thesis. The container is the riverbed pointed at your own behavioral flow: constrain the terrain, and the water — you — does work instead of diffusing. Both directions hold: containers channel your generative flow, and enforced containers are the only thing your appetites cannot route around.

Connection to Macrostate Engineering

Container design is macrostate engineering's spatial instrument: the container is a macrostate with a physical boundary. Define the macrostate, enter the container, let the microstates resolve themselves.

Connection to Statistical Mechanics

The formal frame: environments shift the energy landscape so that desired behaviors sit in the low-energy basin. A container is a locally engineered Boltzmann distribution.

Connection to Forcing Functions

A forcing function is a point-event; a container is a sustained field. The strongest designs compose them: the forcing function gets you across the boundary, the container holds you inside it.

Connection to Ignition

Ignition solves the start; attractor-state design solves the middle. A complete container handles both: low entry cost at the boundary, high exit cost from the mode.

Connection to Agent Body

The same principle applied to AI agents: an agent's effective behavior is set by its constraints and surfaces — its container — more than by its raw capability. Designing an agent's body and designing your own containers are the same discipline.

See Also

• Intelligence Is Water - The container is the riverbed applied to behavior
• Macrostate Engineering - Containers as physically bounded macrostates
• Prevention Architecture - Enforced boundaries against your own crack-finding
• Buffs & Debuffs - Environmental modifiers on every action's probability
• State Machines - Containers as absorbing states with expensive exits
• Activation Energy - The boundary pays the start cost once
• Forcing Functions - Point-events that push you across the boundary
• Zeitgebers - Scheduling boundary crossings on external rhythm
• Attention Routing - Mode-lock as attention routed once, at entry
• Mode-Lock - The lock-in mechanism the container initializes
• Gradients - Boltzmann selection: why the strongest pull wins by default
• Ignition - Starting mechanics; containers handle the continuing
• Agent Body - Container design for machine agents

Core Principle: The unit of behavior design is the container: a bounded context that constrains activity types and bends the probabilities of everything inside it. Environments are runtimes that load and execute scripts whether or not you authored them — so choose runtimes, not resolutions. Enablers are not attractors: possibility pulls nothing, and an enabler-rich configuration without attractors is too leaky to inhabit — the strongest container wins the day by default. Freedom without a container diffuses into the lowest-cost attractor; pressure without structure is stress, not output. Engineer attractor states where stopping is the expensive decision, exploit mode-lock by choosing what it fires on, and validate every container by execution counts alone.

You do not rise to your intentions; you execute whatever scripts your runtime loads. Stop negotiating with yourself inside bad containers — build the boundary, then live freely inside it.