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 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.

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.

Mode-Lock

Mode-lock is Will's name for his own attentional lock-in: once an activity captures the mode, the mode holds itself in place for hours. It is bidirectional — the same mechanism that produces 8-hour deep-work days produces YouTube spirals ("it's just thirty minutes. It's just an hour... sooner or later it's two and a half hours passing").

"What I have discovered about myself is I am very sensitive to mode-lock — I need to be in a certain mode... This is not a deficiency, this is actually a superpower. Things can be a superpower if you're able to design systems around them that exploit their natural benefits."

The mode is not just attention; it is a voting bloc. When "I'm on a diet" is the active mode, every food choice gets a vote cast against it. Remove the container that sustains the mode and the votes stop:

"A huge part of why I'm not eating healthily is the mode lock. If you take away the gym, then the one thing casting votes about me being on a journey to be in shape is lost."

And environments can silently swap the mode out from under you:

"It is interesting: the mode-lock effect. When I am in LA I feel like I am on vacation, so I do not mind eating donuts... But now that I am back — now calories matter again. Now timing matters again."

Same person, same knowledge, different loaded mode. Two design consequences:

Frame the mode as existential, not functional. "If I see it as functional, I do not stay with it; if I see it as existential — like it is a mode of being — I naturally stay in that mode." A 9-hour walk framed as exercise creates exhaustion and rebound; framed as "exploring a specific area of SF because I wonder what it feels like," it sustains itself. The mode must be an identity-state, not a chore with a duration.

Engineer the lock deliberately. Since the lock-in fires regardless, the leverage is in what it fires on:

"You can engineer that — you can engineer what makes you get stuck in a certain stage... if you understand what programs you."

A container is, among other things, a mode-lock initializer: entering the boundary loads the mode, 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.

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.

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
• 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. 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.