What's this about?
Applying domain-driven design — specifically bounded contexts — to how you carve up agent responsibilities, rather than splitting agents by task or by tool.
What is a "bounded context"?
DDD's core idea: a region of a system inside which words mean one specific thing. "Customer" means something different to billing than to support, and pretending otherwise produces a model that serves neither. The boundary is drawn where the vocabulary changes. Applied to agents, it says don't build a "research agent" and a "writing agent" — build agents around the domains where the concepts and constraints are internally consistent, and make the handoffs between them explicit translations.
Why does this matter to you?
HN 93 points, 21 comments
- It is the same instinct as dotey's module-boundary rule this week: split by what varies, not by sequence.
- It gives a principled answer to "how many agents and what should each one own", which is currently mostly folklore.
- Old software-design ideas transferring cleanly is a good sign; most of the agent-architecture discourse is reinventing them badly.