Agent Roles and Responsibilities

A working multi-agent system needs clear roles. Each agent needs to know what its job is, where its boundaries are, and who to escalate to when things go wrong — just like a human team.

The Minimum Viable Team

For most use cases, you need at least these three roles:

Why Agents Need Tool Restrictions

Why not just give every agent access to every tool? The answer is security. You would not give your intern the keys to the production server. Restricting access is not about mistrust — it is about preventing accidents.

A Researcher agent is a perfect example: Its job is to investigate and analyze. It reads files, searches for information, and compiles reports. But it cannot write files or execute system commands. A research task should never accidentally overwrite an important file. The restriction makes the agent safer without making it less useful for its actual job.

Context Loading: Why Each Agent Reads Different Files

When an agent is activated, it does not load every file in the system. It loads only the files relevant to its role. The Shop Manager loads the product catalog and pricing information. The Content Writer loads the brand voice guide and the editorial calendar.

This selective context loading serves two purposes: First, it keeps the agent focused — an agent with less but more relevant context delivers better results. Second, it saves token usage, meaning faster responses and lower API costs.

Extended Roles

For more complex setups, these roles can be added:

Our Team as Reference

Responsibility Chains (RACI)

For every task, it should be clear who does what. We use RACI:

Agent Collaboration and Handoffs

Sometimes a task requires more than one agent. For example: "Research our top competitor and then write a blog post comparing our product with theirs." This involves the Researcher agent gathering information and the Content Writer agent creating the blog post.

The system handles this through handoffs: The first agent completes its part of the work and stores the result. The second agent picks up that result as input and continues. Each agent works within its own boundaries, but the outcome is seamless collaboration — the security benefits of restricted specialists combined with the flexibility of multi-agent cooperation.

Defining Boundaries

Every agent needs to know what it should NOT do:

• No credential changes without approval
• No destructive commands (rm -rf, etc.) without explicit approval
• No external API calls without context
• No outputs over 10,000 tokens without chunking
• No production changes without tests passing

Escalation Paths

When something goes wrong, there are clear escalation levels:

1. Worker detects problem → tries fix (2 attempts)
   ↓
2. Fix doesn't work → posts error + context in channel
   ↓
3. Manager (Manager-Agent) takes over → either:
   a) Solve it themselves
   b) Delegate to another worker
   ↓
4. Manager can't solve → escalates to CEO (CEO)
   ↓
5. CEO decides → continue / discard / get external help