Responsibility Partitioning

Context

When several agents pursue a shared goal inside one system, unclear roles and boundaries produce duplicated work, gray zones no one owns, and incidents that cannot be attributed to a single agent. As the system grows, the question "who is responsible for what" becomes unanswerable.

Problem

If you keep adding capability without separating roles, agents start to overlap and gray zones appear where no one is accountable. When something fails you cannot trace it to a specific agent, and there is no clear lever for improvement. The system as a whole becomes an unexplainable black box.

Forces

• Independent agents reduce coordination cost, but partitioning too finely raises orchestration overhead.
• Clear boundaries make agents testable and replaceable, but the wrong cut produces unnecessary handoffs.
• Designing the perfect partition up front leads to analysis paralysis; skipping partitioning altogether produces a refactoring bill that explodes later.

Solution

Decompose the system's final goal into sub-responsibilities and assign each to exactly one agent. The criterion for the cut is "what can this agent explain about its work." Each agent decides and acts within its boundary; anything outside is delegated through an explicit handoff. Once partitioned, give each boundary a Module Contract so collaboration runs on contract, not custom.

Application scenario

Illustrative scenario — figures and company names in this page are hypothetical for explaining the pattern, not measured data.

An early customer-support system ran intake classification, response generation, escalation, and quality review inside a single agent. It worked at low volume. As traffic grew, the cracks appeared: when response quality dropped you could not tell whether the cause was misclassification or generation; tightening the escalation rule changed the response tone. After splitting into Intake, Response, Escalation, and QA agents, each could be evaluated and improved on its own, and incident attribution became immediate.

How it breaks

Squeezing every capability into one agent and "separating roles by prompt" produces interference between roles. Tuning the classification prompt changes the response tone; tightening escalation blocks normal responses. Every change has unpredictable side effects.

Academic References

• Architecting Agentic Communities using Design Patterns — arXiv 2601.03624
• ATAM: Method for Architecture Evaluation — Carnegie Mellon SEI