Information Flow

An engineering team spends forty minutes in a design review deciding not to introduce a new caching layer in front of a slow endpoint — the last cache they added there caused a stale-read incident, and the room agreed, out loud, in a meeting nobody transcribed, to fix the underlying query instead. Two weeks later, a different engineer opens a session with an AI agent and asks it to speed up that same endpoint. The agent has never heard of the meeting. It reads the code, finds the slow query, and reaches for the obvious, well-supported answer: add a cache. The tests pass. The change merges. Three weeks after that, the same stale-read failure resurfaces, and the postmortem discovers the team paid, in production, to relearn a lesson it already owned.

Nothing about the agent malfunctioned. It followed instructions, applied sound engineering judgment given what it could see, and produced code that passed every check available to it. What failed was not the model, and not even, precisely, the agent’s judgment. What failed was the wiring: the decision existed, but no channel carried it from the room where it was made to the session where it was needed. That is not a new kind of failure. Engineering organizations have been losing decisions between rooms for as long as there have been rooms. It is simply happening at a new speed now, on a team that has quietly acquired a new kind of member — one that reads only what is placed in front of it, once, at the start of each sitting, and has no way of knowing what it was never shown.

What Conway actually said

In April 1968, a computer scientist named Melvin Conway published a paper in Datamation — the trade magazine of the era, after Harvard Business Review had turned it down — titled “How Do Committees Invent?” Its central claim, in Conway’s own words, is a precise sentence, not the loose paraphrase it is usually reduced to: organizations which design systems are constrained to produce designs which are copies of the communication structures of those organizations. Conway was not writing primarily about software; he was describing a constraint on any group designing anything. The observation got its now-famous name later that same year, when participants at the National Symposium on Modular Programming judged it durable and general enough to deserve one.

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Melvin Conway, “How Do Committees Invent?”, Datamation, April 1968

Software teams have spent decades acting on the practical half of that observation, often without citing the paper it came from. Restructuring teams deliberately around the system architecture an organization wants, rather than accepting whatever architecture falls out of an existing reporting chart, is common enough in the industry to have its own name: the Inverse Conway Maneuver. A set of small, cross-functional teams producing a genuinely modular system is not an accident when it happens — it is Conway’s constraint applied on purpose, sometimes before a line of code is written, because the team structure was chosen to produce that system shape in the first place.

The AI-era corollary

Conway described systems built by committees of people, decades before anyone imagined an AI agent occupying a seat in the room. The corollary worth stating carefully, without overclaiming it, is this: once an agent is a genuine node in an organization’s information flow — receiving context, producing output, sometimes making a call nobody independently reviews before it ships — the shape of the information reaching that node starts to matter in the same structural way the shape of communication between human teams always has. Not because the agent is a person, or has anything resembling the incentives and politics that make human communication structures what they are. It matters because Conway’s underlying mechanism was never really about personhood; it was about what a designing party can perceive and coordinate with. A party that only ever sees what a session hands it at the start of a conversation is operating under a communication constraint as real as a committee that never talks to the team two floors down.

That corollary is an extension of Conway’s observation, not a separately measured finding of the same rigor, and it is worth being honest about the gap: dedicated research applying Conway’s Law specifically to AI-agent information architecture is still thin on the ground. What is measured, and measured rigorously, is the amplifier effect this volume opened with — that AI’s primary organizational effect is not independent improvement but amplification of whatever a team’s existing structure already does well or badly. An organization whose decisions already reach the right people, in the right form, at the right time, amplifies that strength the moment an agent becomes a new consumer of the same information. An organization whose decisions already get lost in hallways and untranscribed meetings amplifies that weakness identically — except the losses now happen inside sessions that run faster, in parallel, and leave less residue behind than a human conversation would.

Two failure modes: latency and loss

Two distinct failures hide under the single complaint that “the agent didn’t know.” Latency is information that exists, was captured somewhere, and simply had not arrived yet: a decision made three sessions ago, sitting correctly in whatever record keeps it, that a session starting today has no route to before it begins working. This Library’s Volume II names the record built to close exactly this gap Decision Memory — decisions persisted as first-class, queryable records of what was decided, why, and what it superseded — and Volume V’s chapter on Workflow Recovery catalogs the distinct shapes a session picking up unfinished or related work can take, and what each shape needs carried across the gap to avoid this exact failure. Both chapters are doing the same structural work this one is naming directly: latency is a solvable engineering problem, because the information already exists. The only open question is whether a channel gets built to carry it to where it is needed, and how quickly it does.

Loss is the harder failure, because there is no channel to build faster — there is nothing sitting on the other end of it to deliver. Information is lost, not late, when it never gets captured anywhere queryable in the first place: context an agent read and then had compacted away as a session’s window filled, a decision made out loud in a meeting nobody wrote down, a convention that has lived correctly in one senior engineer’s head for three years and has simply never needed writing down before an agent arrived asking for it. Anthropic’s own guidance on managing a growing context window is explicit that aggressive compaction can quietly drop details whose importance only becomes clear later — a technical description of loss happening inside a single session, at the token level, that is structurally the same failure as a whole organization losing a convention nobody documented. A widely cited 2025 technical report from Chroma sharpens the same point from another angle: models do not use everything sitting in a long context window uniformly, and their performance grows measurably less reliable as the volume of input grows — meaning an agent handed a great deal of context is still not guaranteed to retain the one clause inside it that actually mattered. Loss is not fixed by faster delivery. It is fixed only by deciding, in advance, that certain categories of information get written down somewhere durable, before an agent is the one asking for them.

A framework for auditing information flow

Reading the fix column as an implementation checklist rather than a description misses the point of the table. Each fix is an organizational design decision, not a tooling purchase: someone has to decide what counts as a decision worth persisting, in what format, queried by what trigger, and someone has to decide which conventions are important enough to be mandatory to write down rather than optional to mention. A harness can make either fix easy to execute. Neither harness nor model chooses, on an organization’s behalf, what belongs in the record in the first place — that choice is still, and will remain, a human one, made about the organization’s own information, not about the agent reading it.

Where the wiring shows up first

The pattern does not require guessing which sessions are suffering from latency versus loss. It is visible, once someone asks the right question of the record almost every AI-assisted team already keeps: of a session’s first several tool calls, how many are spent rediscovering something the organization, in some form, already knew — reading files to reconstruct a convention that lives in a style guide nobody pointed the session at, or a design decision made in a channel the session has no access to.

What to check on Monday

1. Find one decision that has been made more than once by different sessions or different engineers — a cache added twice, a retry policy set two different ways — and trace whether the first decision was ever recorded anywhere a second session could have found it.
2. Ask what a brand-new session actually receives before its first tool call, not what the team believes it receives. The gap between those two answers is usually where the latency lives.
3. For a session handed to a different person, or resumed after a gap, check whether Decision Memory or a written handoff summary reached it, or whether it started blind and reconstructed everything from the diff alone.
4. Treat every context-compaction event as a loss event until proven otherwise, and audit what routinely gets dropped rather than assuming the summary caught what mattered.
5. Pick one category of information an agent has had to ask for more than once — why an approach was rejected, what a name means, which service owns a boundary — and give it an explicit, mandatory home before it gets asked a third time.

This chapter has been about what reaches a session and when. The next chapter turns to a related but separate question this one deliberately leaves open: once information does arrive, who actually has the standing to decide what to do with it, at what altitude, and on whose authority. Information flow and decision-making authority are frequently confused for the same problem inside an organization, and they compound each other when both are broken at once — but wiring a decision to the right session and giving the right party the authority to make it are not the same fix, and a team that only solves the first will still watch the second one fail.