Avoid Agent Sprawl: When to Use a Task, Board, Skill, or Profile

Do not turn every request into an agent. Use five questions to choose a Task, Board, workspace, Skill, or Profile and understand each boundary.

# Avoid Agent Sprawl: When to Use a Task, Board, Skill, or Profile

If every new request becomes a new AI agent, the system rarely becomes clearer. It usually accumulates roles with overlapping names, unclear permissions, and memory that is difficult to maintain. Start with a different question: what degree of persistence does this work actually need? Create a Profile only when responsibility, memory, tools, or operating cadence truly need a long-lived boundary.

Scope note: This article uses documented Hermes concepts to propose an operating framework. It is not an official Hermes rule, and its effectiveness should be tested through real work.

The problem is not the number of agents; it is the persistence boundary

A research topic, a marketing project, a customer question, and a personal errand can each sound like a job for a separate agent. But a different topic is not automatically a reason to create a new identity. Over time, an agent-per-topic approach makes it hard to answer basic questions: who owns this work, where is the relevant memory, which credentials can be used, and does this agent still have a reason to exist after the task ends?

Hermes describes a Profile as independent Hermes state: each has its own configuration, environment, SOUL, memory, sessions, skills, cron jobs, gateway state, and database. Its documentation also distinguishes a Profile from a workspace and from a sandbox. A Profile is therefore more than a prompt label; it is a persistent boundary that needs governance. [Profiles documentation](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/profiles.md)

Choose the smallest unit that can carry the work

The following is one practical decision ladder, not an official Hermes rule:

1. Use a Task for a one-off deliverable with a clear definition of done.
2. Use a Board for related tasks that need an ongoing queue, cadence, or tracking.
3. Assign a workspace when the work needs files, code, or research materials.
4. Extract a Skill when a method repeats and can be taught as a reliable sequence.
5. Create a Profile only when responsibility, memory, tools or credentials, scheduling, or lifecycle must remain separate over time.

| Question | If yes | Default unit | | --- | --- | --- | | Is this a finishable deliverable? | It has a clear completion condition | Task | | Is there a stream of related work? | It needs tracking or a shared cadence | Board | | Does the work need an operating environment? | It needs files, code, or materials | Workspace | | Is the method recurring and teachable? | You want to reuse it reliably | Skill | | Must identity, memory, permissions, or ownership stay separate? | Combining it creates a durable risk | Profile |

Hermes Kanban documents Boards and Tasks as durable work-management primitives. Its Skills guidance describes loading task-specific instructions only when needed. That is different from putting every new task into a long memory block: memory carries context that must persist, while a repeatable method is a candidate for a Skill. [Kanban documentation](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/kanban.md) [Working with Skills](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/guides/work-with-skills.md)

Example: starting research does not require a research Profile

For the first week of a research project, a Task to define the question and collect initial sources may be enough. When the work develops several milestones, create a Board and a dedicated workspace. If the same literature-screening and evidence-table process repeats each week, turn that method into a Skill. A dedicated research Profile is only justified when the work needs separate sensitive data, long-lived independent memory, or a fixed autonomous operating cycle.

A Profile is not a security boundary

Profiles separate Hermes state; they do not automatically restrict local filesystem access. Hermes explicitly separates profiles, workspaces, and sandboxes. If roles share a runtime or mounted directories, access control, credentials, and file boundaries still require separate design. Role instructions should not be treated as a security boundary.

Three questions before creating another agent

Write down: “What is the completion condition? Will this work repeat? Why can an existing role not handle it?” If the final question cannot identify a lasting boundary of responsibility, memory, or permissions, start with a Task, Board, workspace, or Skill. Making Profiles the last option keeps the system easier to understand, test, and evolve.

Limits

This ladder prevents conceptual sprawl; it does not guarantee better work. After adopting it, track token cost, misrouting, maintenance burden, and human correction. Test it through small, reversible work before treating it as an operating standard.