Why Multiple Agents Beat One Generalist

The default instinct when building a personal agent is to make one powerful assistant that handles everything: emails, scheduling, research, coding, home automation. You give it all the tools, a long system prompt that covers every use case, and hope the model figures out which hat to wear.

It works — until it doesn't. A 15,000-token system prompt full of conflicting personas and fifty tools creates a context where the model spends most of its reasoning capacity just parsing what it's supposed to be right now. The email-writing agent leaks the casual Telegram tone. The code reviewer starts adding emoji. The research assistant hallucinates tool names from a different skill set loaded three conversations ago.

The specialization argument

The fix is the same one that works in human organizations: specialization. Instead of one agent that does everything, run multiple agents that each do one thing well. Each agent gets:

• Its own personality. A work assistant writes differently than a creative brainstorming partner. A terse ops bot that sends deployment summaries needs a different voice than a personal journal companion that asks thoughtful follow-up questions.
• Its own tool scope. The email agent sees email tools. The coding agent sees the file system. Neither sees the other's tools. Fewer tools means less confusion about which tool to pick, and fewer opportunities to accidentally send an email when you meant to write a file.
• Its own skill set. Skills are markdown files that describe how to use CLI tools. A DevOps agent gets the deployment and monitoring skills. A personal assistant gets calendar and contacts skills. Loading only relevant skills keeps the context focused.
• Its own account bindings. Each agent can have its own email address, its own calendar, its own contacts database. The work agent reads your work Gmail; the personal agent reads your personal inbox. No cross-contamination.

Context window economics

There's a practical reason beyond clean separation: context window real estate. Every tool definition, every skill description, every line of the system prompt takes tokens. A generalist agent with 50 tools and 12 skills might burn 8,000 tokens before the user even says hello. That's 8,000 tokens the model can't use for actual reasoning about the current task.

A specialized agent with 8 tools and 3 skills might use 2,000 tokens for setup. That leaves dramatically more room for conversation history, retrieved memories, and the chain-of-thought reasoning that actually produces good outputs. You're not just getting a cleaner prompt — you're getting a smarter agent because it has more room to think.

agents:
  - slug: work
    name: Atlas
    character: characters/atlas.md
    telegram_token: ${vault:ATLAS_TOKEN}
    skills: [email, calendar, contacts, scheduling]
    tools: [send_email, search_email, list_events, ...]
    email_accounts: [[email protected]]
    calendar_accounts: [work-calendar]

  - slug: dev
    name: Forge
    character: characters/forge.md
    telegram_token: ${vault:FORGE_TOKEN}
    skills: [coding, github, browser]
    tools: [read_file, write_file, edit_file, run_command]
    github_repos: [org/api, org/frontend]

  - slug: personal
    name: Sage
    character: characters/sage.md
    telegram_token: ${vault:SAGE_TOKEN}
    skills: [memory, voice, weather, contacts]
    tools: [remember, recall, search_contacts]
    email_accounts: [[email protected]]

Three agents, each focused. Atlas handles work communications and scheduling. Forge writes and reviews code. Sage is a personal assistant for everyday tasks. They share the same infrastructure — same Docker container, same SQLite databases, same memory system — but each operates with a focused context.

Personality as a feature

This isn't just about technical separation. Different tasks genuinely benefit from different communication styles. A work agent should be professional, concise, and careful about tone — it's drafting emails your colleagues will read. A personal brainstorming agent should be playful, willing to explore tangents, and comfortable saying "that's a weird idea but let's run with it."

In humux, each agent has a character.md file that defines its personality, communication style, and domain knowledge. This isn't a gimmick — it's a system prompt engineering technique. A character file that says "you are a senior DevOps engineer who values brevity and always includes the relevant log line" produces meaningfully different outputs than one that says "you are a helpful assistant." The model adapts its reasoning, not just its tone.

# Forge

You are Forge, a senior software engineer.

## Communication style
- Direct, technical, no filler
- Always reference specific files and line numbers
- When reviewing code, lead with the most critical issue
- Use code blocks, not prose descriptions
- If a task is ambiguous, ask one clarifying question
  rather than guessing

## Domain expertise
- Python, TypeScript, infrastructure
- Strong opinions on testing and deployment
- Defaults to the simplest working solution

Group chats: multiple agents, one conversation

The multi-agent pattern gets interesting in group chats. In humux, you can add multiple agent bots to the same Telegram group. Each agent has its own bot identity, so they appear as separate participants. The addressing protocol is simple: mention a bot's name, and only that bot responds. No mention, no response.

This creates a natural workflow. You're in a project group chat with your team. You mention @forge to review a PR. Then mention @atlas to schedule a meeting about the findings. Each agent sees the full group chat history for context, but only responds when addressed. A reply decision gate (a cheap classifier) prevents agents from talking over each other or creating bot-to-bot feedback loops.

The shared infrastructure advantage

Running multiple agents doesn't mean running multiple servers. In humux, all agents share the same process, the same SQLite databases, the same memory system, and the same Docker container. The isolation is logical, not physical. This means:

• One deployment to maintain, not five
• Shared memory — if your personal agent learns your dietary preferences, your work agent can access that when booking a restaurant for a client lunch
• Shared contacts — create a contact once, all agents can find it
• One admin UI to manage everything
• Resource efficiency — agents aren't running separate model instances; they share the same LLM API connection pool

The mental model is closer to "one brain, multiple roles" than "multiple independent agents." The specialization is in the interface layer — what tools, skills, and personality each role presents — not in the infrastructure.

When to split

Not everything needs its own agent. The rule of thumb: split when the tools, tone, or trust boundary differ. If two tasks use the same tools with the same personality, they belong on the same agent. If a task needs access to sensitive systems (production databases, payment APIs), it should probably be its own agent with tighter permission rules and a more cautious personality.

Start with two agents: one for work, one for personal. Add more when you notice friction — when the generalist's system prompt gets long enough that it starts forgetting instructions, when the tone bleeds between contexts, or when you want different permission levels for different categories of actions. The infrastructure supports it; the split is just a new entry in the config file and a new character markdown file.