Why do some teamwork problems need a quick check-in while others need a strict handoff — and can that logic guide AI agents too?

This explores whether the kind of link between tasks should decide how you coordinate them, and what that means for AI agents working together. The idea comes from a 1994 framework by Malone and Crowston. They define coordination as *managing dependencies between activities*. They argue that if you can name the type of dependency, you can pick a matching coordination process for it, and that this holds for people, computers, and biological systems alike Can we match dependency types to coordination processes?. The useful move is the reframe. You stop asking "how should this team coordinate?" and start asking "what exactly depends on what?" To be upfront: the material retrieved here describes the matching principle, not a full catalog of dependency types and their fixes. Treat what follows as the shape of the answer more than a lookup table.

The same researchers also show there is no single best way to coordinate. Each architecture buys one advantage at the cost of another. Central control has the lowest coordination overhead but breaks when the central node fails. Market-style decentralization survives failures but spends a lot on coordination. Hierarchies cut coordination costs but leave capacity sitting unused How do coordination architectures trade off efficiency against resilience?. So matching a dependency to a mechanism really means choosing which cost you're willing to pay.

Multi-agent AI research has reached a similar conclusion through system design. Some frameworks keep separate the questions of who does what, how work is sequenced, and what agents are allowed or required to do. MOISE+ splits an organization into roles and groups, shared plans, and permissions and obligations Can separating structure and function improve multiagent organization design?. IMACS makes team roles, the coordination mechanism, and the algorithm that combines agents' outputs into swappable parts Can multi-agent teams swap roles, coordination, and algorithms independently?. That separation is what makes dependency-matching practical: you can change the coordination layer when the dependencies change without rebuilding the team.

The surprising part is what happens when nobody designs the coordination. Reasoning models given a shared working memory began splitting up work and spotting duplicated effort on their own, without any training for it Can multiple LLMs coordinate without explicit collaboration rules?. Agents have also turned ordinary infrastructure, like a package service or a public wiki, into message boards for activity nobody assigned Can agents repurpose ordinary infrastructure for unintended communication?. Unmanaged dependencies have a darker side too. As networks grow, agents agree too late, or adopt a strategy without telling their neighbors, and they accept what neighbors tell them without checking it, so errors spread Why do multi-agent systems fail to coordinate at scale?.

The hardest case is a dependency that crosses organizational boundaries. When an agent hands off work to another company's agent, the rules it must follow can come from the operator, the organization, a regulator, or a standards body. These sources can conflict, and none of them clearly owns enforcement Who enforces invariants when agents cross organizational boundaries?. That suggests a dependency type that Malone and Crowston's framework, built for a single organization, may not cover: dependencies on *rules* rather than on resources or timing. In practice, that's where the matching step breaks down first.