Should the type of dependency between two tasks — handoff, shared resource, or waiting in line — determine how you design the system around them?

This explores whether naming the kinds of dependencies between pieces of work should drive how a system is built. The clearest anchor in the collection is Malone and Crowston's coordination theory from 1994. It defines coordination as managing dependencies between activities, and argues that once you know which type of dependency you're dealing with (a shared resource, a producer handing off to a consumer, a task that has to wait for another), you can choose a coordination process that fits it instead of improvising one Can we match dependency types to coordination processes?. The surprising part is how broad the claim is. The same reasoning is meant to apply to organizations, software, and biological systems, so architecture becomes a matter of reading the dependencies before choosing the structure.

The collection doesn't have work that applies this classification to LLM systems directly. Several notes still reach the same idea from the AI side without using its vocabulary. The plainest case is splitting multi-step reasoning into a separate 'decomposer' model and a 'solver' model. Doing this beats a single model that does both, partly because planning and execution stop interfering with each other. Better still, the planning skill transfers across domains while the solving skill does not Does separating planning from execution improve reasoning accuracy?. In coordination terms, that's a producer–consumer dependency made visible and given its own seam in the architecture. Once the seam exists, you can see which side generalizes.

The same reasoning shows up in decisions about cost. The argument for small language models in agents rests on sorting subtasks first: most agent work is repetitive, well-defined language work, so the sensible design sends that to cheap small models by default and calls a large model only when needed Can small language models handle most agent tasks?. A related note shows that small models trained with DPO can handle function calling, one of those well-defined subtasks Can small models match large models on function calling?. Here the classification is about task type rather than dependency type, but the move is the same: describe the structure of the work, then assign parts.

There's also a version of the idea inside a single model. One note argues that chain-of-thought exists because transformers have no built-in way to carry evolving state from one step to the next. Each step depends on the one before it, and a feedforward architecture can only handle that by pushing the state into deeper layers until it runs out of depth. Writing reasoning out as tokens is a costly patch for that mismatch Why do transformers need explicit chain-of-thought reasoning?. Recommender research teaches a parallel lesson: building in assumptions that match the problem beats adding depth or capacity What architectural choices actually improve recommender system performance?. Taken together, these notes suggest that when the architecture doesn't match the dependency structure of the work, you pay for it in workarounds.

The collection doesn't yet test Malone and Crowston's taxonomy against modern multi-agent designs, for example by checking whether 'shared resource' dependencies call for different agent topologies than 'sequential handoff' ones. That link is inferred here, not shown. Still, it's a useful lens to bring with you: when you read about a new agent architecture, ask which dependency it was designed to manage.