Pace Layering

Here are the seven stages of the product development lifecycle, sorted by how often each one usually changes. The timings are illustrative, and every company's will differ a little:

FAST   Build            hours to days     what the code does
 │     Specification    days              how this feature works
 │     Refinement       weeks             what we've agreed to, and why
 │     Go to market     weeks to months   how we sell and support it
 │     Roadmap          a quarter         what we build next
 │     Goals            a quarter or more where we need to be
SLOW   Organization     years             who buys, and why

Coding agents pulled the top row toward hours. Nothing pulled the bottom rows. The distance between the fastest layer and the slowest one has widened, and much of what product teams feel as friction lives in that gap.

Stewart Brand had a name for this kind of stack. Pace layering is his idea that durable systems are made of layers that change at different speeds, with the fast layers trying new things and the slow layers keeping what works, and that the system stays healthy as long as each layer is allowed to move at its own pace and to listen to the layers next to it.

Fast learns, slow remembers

Brand, who created the Whole Earth Catalog, first drew the diagram with the musician Brian Eno in Eno's London studio in 1996. He published the idea as a chapter of his 1999 book The Clock of the Long Now, and in 2018 an edited version appeared in MIT's open-access Journal of Design and Science as "Pace Layering: How Complex Systems Learn and Keep Learning." It started from buildings. In his 1994 book How Buildings Learn, Brand had expanded the architect Frank Duffy's layers of a building into six, from the site to the furniture, each lasting a different length of time.

The civilization version has six layers too. From fast to slow, they are fashion and art, commerce, infrastructure, governance, culture, and nature. Then Brand describes how they relate, in the passage the idea is known for:

"Fast learns, slow remembers. Fast proposes, slow disposes. Fast is discontinuous, slow is continuous. Fast and small instructs slow and big by accrued innovation and by occasional revolution. Slow and big controls small and fast by constraint and constancy. Fast gets all our attention, slow has all the power."

His claim reaches well past civilizations. "All durable dynamic systems have this sort of structure. It is what makes them adaptable and robust." A forest, he points out, works the same way: needles change within a year, the forest over a thousand.

"That's their job"

The easiest misreading of the stack at the top of this post is that the slow rows are the problem. If Build takes hours, why does the roadmap take a quarter? Brand anticipated the complaint. "We don't have to deplore technology and business changing rapidly while government controls, cultural mores, and 'wisdom' change slowly," he wrote. "That's their job."

The product version is the same. A company's idea of who buys and why should not change because an agent shipped a prototype on Tuesday. Goals that moved at Build speed wouldn't be goals; they'd be moods. The slow layers are slow because their job is to hold the fast layers steady while the fast layers experiment. A team that speeds every stage up to agent pace removes the memory along with the friction.

Where the layers tear

The danger is a layer that ignores the pace of the others. "Each layer must respect the different pace of the others," Brand wrote, and his examples run in both directions. Commerce pushing nature "at a commercial pace" loses the forests and fisheries. Governance forcing its pace on everything above it, as the Soviet Union did with five-year plans, cuts itself off from innovation.

Product organizations tear in both directions too.

Fast overrides slow. Coding agents can now produce a change that quietly answers a slow-layer question. A merge request that implements per-seat pricing settles a pricing decision, whatever the decision record says. A prototype that serves a new kind of customer redraws the ideal customer, whether or not anyone in Organization agreed. Each is the fast layer setting slow-layer policy at fast-layer speed, which is the move Brand warns about.

Slow throttles fast. The opposite failure is a slow layer that insists everything route through its cadence. If every change waits for the quarterly review, the fast layer stops learning, which is the only thing it's for. This is what our essay on the modern PDLC describes from the inside: "Coding agents sped up one stage. The other six still run on meetings." The meetings are the slow layers trying to keep up the only way they know how.

Fast proposes, slow disposes

Brand's answer is in the middle of his famous passage. The layers are meant to talk to each other. "Slow and big controls small and fast by constraint and constancy": the slow layer sets the boundaries, and doesn't redo them every week. "Fast and small instructs slow and big by accrued innovation": the fast layer feeds back what it learned, and the slow layer absorbs it on its own schedule. The essay's last line puts the result plainly: "It is precisely in the apparent contradictions between the pace layers that civilization finds its surest health."

For a product organization, that relationship needs two channels. The slow layers' constraints have to be readable at fast-layer speed, so an agent working at hour-scale can see the quarter-scale and year-scale decisions before it acts. And the fast layer needs a way to propose upward, so what Build learns reaches the slower layers as a proposal they can accept or reject before it ships.

Where Brief fits: the channel between layers

Brief is the product strategy agent, and in Brand's terms it works on the boundaries between layers. As the homepage puts it, Brief "works across all product stages, not just Build. It captures decisions where they happen, connects them into one graph, and acts on them." The homepage traces one example through all seven stages: positioning (DOC-118, in Confluence) frames a quarterly goal (OKR-Q4, in Slack), which sets up a roadmap item (RM-3, in Jira), which depends on a pricing decision (D-241, in Slack), which shapes a spec (CHK-412, in Jira), which becomes a merge request (!1182, in GitLab), which feeds a launch (DOC-131, in Confluence). That chain is a pace-layer stack, running from years at positioning down to hours at Build, and Brief holds it as one graph. Here is what that does at each boundary.

Slow is readable at fast speed. Brief's agent setup has coding agents call brief_get_onboarding_context at the start of every session, which loads the team's recent decisions, personas, velocity, recent work and customer insights. Before writing code, agents connected over MCP ask Brief with brief_ask. In the homepage example, an agent asked to add per-seat pricing learns that D-241 is still pending, holds the change, and flags a related security review. That's "constraint and constancy" delivered at hour-scale: the slow layer didn't have to speed up for the fast layer to respect it.

Fast can check before it overrides. When an agent or an engineer wants to make a change that might touch a slower layer, brief ask --mode check checks it against existing decisions and flags conflicts. The merge request that would quietly settle a pricing question gets caught as a pricing question.

Fast proposes, and slow disposes, literally. Brief keeps proposed decisions separate from recorded ones. A coding agent can submit a decision with brief_record_decision and a pending status, which proposes it for later confirmation, and the person reviewing it approves, edits or rejects it before anything is recorded. In Slack, /propose turns an open question into a proposal, and Brief may propose a structured decision from a conversation when you mention @Brief. What Build learned arrives at the slower layer as a proposal, on the slower layer's terms.

Slow knows when it's time to move. A slow layer still has to change eventually, and Brand's whole point is that it should change when accumulated learning says so. A decision in Brief can carry a Re-evaluate when condition, its own statement of when it should be reopened. With Proactive Brief turned on, Brief can send notices about decisions that may need reconfirming, possible contradictions with existing decisions, and surges in customer research related to an important decision, capped at two interruptions a week. The Weekly Strategic Brief sends a weekly analysis by email, with a Discuss with Brief link to work through it in chat. That's "accrued innovation" reaching the layer that can act on it, at a pace the slow layer can absorb.

Brief doesn't decide which layer a question belongs to, and it can't make a slow layer decide faster than its people can. Someone still has to own the pricing call and the positioning. What changes is the boundary between the layers: the fast layer can see what the slow layers have settled, and the slow layers can see what the fast layer has learned, without either one being forced to run at the other's speed.

Which of your layers is moving at another layer's pace right now, and which way is it tearing?

Objections