Build agents like Unix pipelines, not org charts

The most common advice for multi-agent systems: start with a team. CEO agent, CTO agent, sales agent, marketing agent. Looks great in diagrams. Here's why it usually fails, and a better mental model. The Org Chart Problem When you build a "team" first, you end up with agents that have overlapping responsibilities, unclear handoffs, and no good answer to: "who actually does this?" The CEO agent defers to the CTO agent. The CTO agent delegates back to the CEO. Both write status updates nobody reads. The sales agent and marketing agent both think they own "outreach." You have 5 agents producing 1 meeting's worth of real output. It looks like an organisation but it works like a committee. The Unix Pipeline Model Unix got it right in the 70s: small tools that do one thing well, connected through explicit interfaces. Instead of "sales agent" (vague), build: One agent that finds contacts matching a profile One agent that writes personalised outreach emails One agent that tracks response statu