Org Chart as Context Decomposition
If you can draw an org chart, you can design your agentic architecture.
Org Chart as Context Decomposition
If you can draw an org chart, you can design your agentic architecture.
Why does your org have departments? For context management.
Every department is a scope boundary. Every reporting line is a context channel. Your org chart is a context decomposition diagram. You just never called it that.
Same thing with agents. My COO doesn’t see health data. My Life Manager doesn’t see the sponsor pipeline. Not because they can’t. Because they shouldn’t. Scoping what each actor needs to know is the whole job of organizational design. It always has been.
If you’ve ever dealt with the “stupid zone” - that moment when a model has consumed so much context that it starts acting like an intern who pulled two all-nighters on Adderall - you know this instinctively. The fix isn’t a bigger context window. It’s a tighter scope. Decompose the problem. Give each agent less to think about. That’s what departments do for humans.
Adding a new agent is hiring. You define the scope, set up relationships with other agents, decide what information they need access to, and write an onboarding doc. The onboarding doc IS the system prompt. The process is identical to what you’d do for a human, and if you’re thoughtful about how you hire humans, you already know how to design good agent architectures.
Conway’s Law says organizations design systems that mirror their communication structures. The inverse holds too. Your agent architecture will mirror the org you’d build for humans doing the same work. So start there. Draw the org chart first. The agent architecture is the implementation.
This is a first level approximation. Agents don’t have a per identity cost, can sit idle for long periods of time, and generally perform at their best with extremely well scoped context, tasks and definitions of done. As such, you might find yourself hiring more agents than you would hire employees. I might hire an agent just to review cyclomatic complexity or do the annual reports.
On the other hand, favoring composition, I might just give a review agent skills for 4 different kinds of code reviews and spin up the same agent in four separate sessions to review code through different lenses by using different, well scoped skills.
Early days. So far I’m finding that I need to hire a new agent when I want it to have a distinct personality, back story and context to support the mission. I just hired Nate to take over GTM from Morgan and Lena to focus exclusively on building the Gather.dev community. I don’t know exactly what the right size of an agentic organization is, but it’s a fascinating journey figuring it out.
Have you experimented with hiring an agentic org? What are you learning from the experience?