Information Cascades

Try this. You work at an invented company, and you have been asked to add a seat limit to the new team plan. You haven't worked in billing before. You do have a hunch: last month you sat in on a sales call where a customer said they would rather pay for extra seats than have invites fail, so you suspect the team plan should allow overages and bill for them.

You open the code. Five plans already enforce seat limits, and all five block hard: when the limit is reached, the invite fails with an error. The pull requests that added them were approved by two different reviewers. Nothing you can find says why.

What do you do?

Most people follow the five. It is a reasonable choice. Five plans and two reviewers seem to outweigh one remark on one call. So you write a hard block, or your coding agent does, and it passes review because it matches everything around it.

Here is what you couldn't see. The first hard block was written by an engineer in a hurry, who never asked anyone. The next four were written by coding agents that found the first one and followed it. Nobody ever decided that plans should block at the limit. And the customer on your sales call was not alone. Your hunch was the only new information in the whole sequence, and it went nowhere, because you did what the five before you had done.

Three economists described this pattern in 1992. They called it an informational cascade.

Following the people ahead of you

Sushil Bikhchandani, David Hirshleifer and Ivo Welch, all then at UCLA, published "A Theory of Fads, Fashion, Custom, and Cultural Change as Informational Cascades" in the Journal of Political Economy. Its definition is one sentence: "An informational cascade occurs when it is optimal for an individual, having observed the actions of those ahead of him, to follow the behavior of the preceding individual without regard to his own information."

Their example is a paper being submitted to journals. A referee at the second journal learns that the first journal rejected it. Since a referee can't judge a paper perfectly, the earlier rejection should tilt him toward rejecting it too. By the third journal, the referee knows of two rejections, which "further raises the chance of rejection."

The model asks what happens when each person sees only what the people ahead of them did, not what they knew. The authors chose that case on purpose: "Since 'actions speak louder than words,' the information conveyed by actions may also be the most credible." What they found is that people "rapidly converge on one action on the basis of some but very little information." Once someone is following the crowd instead of their own information, "his decision is uninformative to others." Everyone after them faces the same choice and makes the same move.

That is the cost. "The problem with cascades is that they prevent the aggregation of information of numerous individuals." Many people each know something, and almost none of it reaches the group, because every action after the first few just repeats the ones before it. The paper shows that cascades will eventually start, and that they are often wrong: even when people's private information is good, "the probability of the wrong cascade is remarkably high."

Why a cascade is brittle

The paper's most useful result is the next one. A cascade built from hundreds of identical actions looks solid. It isn't. Hundreds of people agreeing would normally be strong evidence, but in a cascade, "once a cascade has started, further adoptions are uninformative." The whole thing rests on the first few choices.

"Thus conformity is brittle," the authors write. "The arrival of a little information or the mere possibility of a value change (even if the change does not actually occur) can shatter an informational cascade." Their third formal result says it directly: "The release of a small amount of public information can shatter a long-lasting cascade." The reason is that "cascades aggregate the information of only a few early individuals' actions," so new public information only has to outweigh those few, not everyone who copied them. Their example is smoking: "the fact that a vast segment of society already smokes need not discourage investigation of the effects of smoking."

The paper also compares two settings. In one, people see only the earlier actions. In the other, they see the information behind those actions. In their simple model, with only actions to go on and no new information arriving, a cascade, once started, is never reversed. When the information is visible, the authors write, "even if an individual does not follow his private signal, it joins the common pool of knowledge," and a long enough run of contrary evidence can turn people around.

Codebases are cascade machines

A codebase is the first setting. It records actions, not information. Code shows what was done, almost never what the person who did it knew or whether anyone decided it.

Coding agents are built to read that record and follow it. Matching the patterns already in the code is usually what you want from an agent. Strictly, an agent isn't in a cascade: the paper's cascade needs a private signal that gets set aside, and an agent that finds five hard blocks never had one. But each copy it writes works like a move in the paper's sequence: one more action, no new information. Its pull request then becomes one more action for the next agent to follow. The person in the opening is the paper's case, someone with a hunch who followed the five anyway. Reviewers are often in that position too. "It matches the existing pattern" is a reason to approve, and it carries no more information than the first copy did.

Our essay on the modern product development lifecycle says that "Now we are in the context era, where agents are expected to work on larger swaths of product, given appropriate specs, tools, MCPs, CLIs, loops, and graphs." The larger the swath, the more of it an agent learns by copying, and the faster an early guess spreads. We've written about how an agent's day-one default gets built on until it is too expensive to change. A cascade is how that default gets its copies, each one making the next look more like a decision.

The paper's brittleness result is the hopeful part. Five copies of a guess are only as strong as the guess. If what the team actually knows is put where the next agent will see it, a small amount of information can stop the run.

Where Brief fits: public information that breaks the cascade

Brief is the product strategy agent. The homepage says it "captures decisions where they happen, connects them into one graph, and acts on them." In the paper's terms, it moves a team from the first setting to the second: the choice is recorded along with the reasoning behind it, where the people and agents that come next can see it.

The reason gets recorded with the choice. In the Brief app, recording a decision requires both What was decided? and Why? before Record Decision will save it, and a decision can also carry Tags and a Re-evaluate when condition. "Team plans allow seat overages and bill for them, because customers told sales they would rather pay than have invites fail" is the private signal from the sales call, entered into what the paper calls "the common pool of knowledge."

Decisions are read from where they are made. The homepage says Brief "reads decisions from Slack, Jira, Confluence, and GitLab, self-hosted included." A choice settled in a ticket or a thread doesn't have to wait for someone to copy it into the codebase before the next agent can see it.

Agents check before they copy. Coding agents set up with Brief search the recorded decisions before they start work, and ask Brief to check significant changes with brief_ask in check mode, which compares a planned change against existing decisions and flags conflicts. An agent about to write a sixth hard block can find the overage decision first, and follow the decision over the five copies. People can run the same check with brief ask --mode check.

A hunch becomes a question. In the opening, the hunch had nowhere to go. In the app, Propose turns an open question into a pending decision and can name Who should decide?. With the user's approval, an agent can record one too, and agents can call brief_list_pending_decisions to see what is waiting. When a decision is pending, an agent can hold. The homepage shows an agent asked to add per-seat pricing to the checkout API learning that D-241, the seat-based pricing decision, is pending, and replying: "Holding the pricing change until D-241 is decided."

One release outweighs the copies. The paper's third result is the case for recording even one decision late. Once the seat-limit decision is recorded, it doesn't have to outvote five plans. It only has to be found, and every later agent and person who checks will find it. If the decision changes, its History shows the status changes, and its Re-evaluate when condition says in advance what would justify a new look.

None of this stops a team from copying. The paper has a warning here too: an early release of noisy public information can leave some people worse off. In the authors' words, "Sketchy disclosures of advantages of oat bran and fish oil, by triggering fads, may do more harm than good." A recorded decision with a vague Why? can start a cascade of its own. And a decision nobody records leaves agents with nothing but the code. When nothing has been decided, check mode has nothing to conflict with, and the agent follows the pattern. What Brief changes is what the next agent can see. The reason travels with the choice, so the run of copies can stop at the first agent that checks.

The paper's lesson is that a crowd of identical choices can rest on almost nothing. In your codebase, which pattern has the most copies, and does anyone know who decided it?

Objections