Cargo Cult

Here are two decision records from two invented companies. Read them top to bottom:

For four rows, the records are identical. Same decision, same status, same date, same number of pull requests following it. A coding agent reading either codebase would copy the gateway call into its next service with the same care. The difference is entirely in the last two rows, and the last two rows are the only ones that tell you what to do when a case comes up that the decision didn't foresee: a batch job that runs inside the same machine, say, or a new customer whose contract says nothing about audit logs.

Record B is a cargo cult. A cargo cult is the practice of carefully reproducing the visible form of something that worked, in the hope of getting the same result, while missing the part that made it work.

Runways, fires and a wooden headset

The phrase most people know comes from Richard Feynman's commencement address at Caltech in 1974, later published as "Cargo Cult Science." Feynman described people in the South Seas who had watched airplanes land with supplies during the war and wanted the planes to come back. "So they've arranged to make things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas." Then they waited.

"They're doing everything right," Feynman said. "The form is perfect. It looks exactly the way it looked before. But it doesn't work. No airplanes land." His target was research that "follow[s] all the apparent precepts and forms of scientific investigation" but is "missing something essential, because the planes don't land."

Feynman's sketch of the islanders is a parable, not anthropology, and this post uses it the same way.

The useful part of the speech is his answer to what was missing. He called it "a kind of utter honesty" and "a kind of leaning over backwards": when you do an experiment, "you should report everything that you think might make it invalid," along with what you think is right about it. The form of science is the method. The substance is the habit of writing down the reasons, including the ones that might prove you wrong.

The decision process can be a cargo cult

Product teams build runways too. A decision record template with fields for context, options and consequences. An architecture decision record folder in the repo. A PRD template. A weekly meeting where calls are made and minutes are taken. Each was copied from a team where it worked, and each looks exactly the way it looked there.

Then the fields fill up with forms. Context: "See Slack." Rationale: "Strategic priority." Consequences: blank. Decisions get cited by ID in pull request descriptions, "per D-214," by people who couldn't say what D-214 was protecting. The folder grows, the meeting happens every week, and the thing a decision record exists to do never happens: a person who wasn't in the room can't use it to make a good call about a case nobody anticipated. The form is perfect, and the planes don't land.

The tell is the same one Feynman pointed to. A real decision record says why, and it says what would make it wrong. A cargo cult record says what, cites who, and stops.

Agents copy form better than anyone

Coding agents are the most capable form-copiers ever built. They learn a codebase by reading it, and what a codebase shows is form: the gateway call wrapped around every outbound request, the retry loop with its three-second pause, the feature flag around the checkout path. An agent will reproduce those patterns faithfully and at scale. What the code doesn't show is which patterns exist for a reason that still holds, which were workarounds for a bug fixed two years ago, and which were somebody's habit.

That gap is not new, and we've written before about what code can't tell you. What's new is the speed. Our essay on the modern product development lifecycle points out that coding agents sped up Build, one of the seven stages. The reasons behind most patterns were set in the other six: a contract negotiated in go to market, a risk raised in refinement, a constraint agreed in a spec review. An agent that copies the form without the reason produces cargo cult code at the rate it produces code. The pattern spreads to forty services, each one correct-looking, and nobody can say which of them actually needed it.

Where Brief fits: carrying the reason with the form

Brief is the product strategy agent, and in Feynman's terms it's built to keep the substance attached to the form. As the homepage puts it, Brief "captures decisions where they happen, connects them into one graph, and acts on them." Here is what that does for the two records at the top of this post.

The reason is part of the record. In the Brief app, recording a decision requires both What was decided? and Why? before Record Decision will save it. That rule means no decision arrives there with the reason missing. It doesn't make the reason a good one: Record B's "Per architecture review." would pass the field, and Brief has no field for whether anyone can still explain it. Brief isn't immune to cargo cult records. A Slack /decide confirmed without editing saves a stock placeholder as its rationale, which is exactly the kind of record to go back and fill in. But the default path asks for the why.

Agents get the reason along with the pattern. 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 with their reasons, along with personas, velocity, recent work and customer insights. Coding agents set up with Brief call brief_ask before they write code. On the homepage, an agent asked to add per-seat pricing learns the pricing decision it depends on is still pending, holds the change, and flags a related security review. An agent that asks before copying the gateway pattern into a batch job gets the audit-log reason, and can tell whether the batch job is the case the reason covers.

A change can be checked against the reason, not just the precedent. brief ask --mode check checks a proposed change against existing decisions and flags conflicts. "We plan to skip the gateway for internal batch jobs" gets checked against what the gateway decision was for, which is the only check that matters when the precedent and the purpose come apart.

Leaning over backwards has a field. Feynman's standard was to write down what might make you wrong. A decision in Brief can carry a Re-evaluate when condition, such as "when no customer contract requires internal audit logs," so the record states its own expiry. With Proactive Brief turned on, Brief can send notices about decisions that may need reconfirming and possible contradictions with existing decisions, capped at two interruptions a week. A recorded decision's History shows its status changes, who made them, and any reason given.

"Strategic priority" fits in a required field just as well as a real one, and Brief can't tell the difference between a reason and a ritual phrase. That part is still the discipline Feynman was describing, and it belongs to the people making the call. What Brief changes is whether the reason, once someone writes it, travels with the pattern to every person and agent who copies it, or stays behind in a meeting that only a few people attended.

If you picked five decision records at random from your team's folder, how many of them could still tell a new engineer, or a new agent, why?

Objections