Learn Hermes AI Agent - Creating Agent Profiles & Capabilities

#Introduction

In episode 3 you managed to turn on your first agent and chat with it in the terminal. But that agent was still plain — no personality, no idea of what it wants to become, and no tools to work with. This episode turns your agent from an experiment object into an entity with a clear identity and authority.

Here is the roadmap for this episode: writing persona, goals, and default behavior; defining capabilities such as browsing, code execution, and database access; and then defining the toolset and permission limits.

#Anatomy of an Agent Profile

All of an agent's identity is defined in a single file called an agent profile. This is the file the controller reads every time a session starts, and it is the source of truth for who the agent is, what its goals are, what it is allowed to do, and how it behaves.

name: support-agent
persona: "Asisten support produk yang teliti dan ramah"
goals:
  - "Menjawab pertanyaan user berdasarkan dokumentasi"
  - "Mengarahkan tiket yang rumit ke eskalasi"
default_behavior:
  language: indonesian
  tone: helpful
  verbosity: balanced
  temperature: 0.4
capabilities:
  - tools
  - browsing
tools: []

The structure above is the backbone of a profile. The first two blocks, persona and goals, shape the personality; the next two blocks, capabilities and tools, shape the authority. Let's break each of them down.

#Writing Persona and Goals

The persona determines how the agent talks, not what it knows. A good persona mentions three things: who it is, its communication style, and its limits.

persona: >
  Kamu adalah asisten support resmi produk Checkout.
  Berbicaralah ramah dan singkat, hindari jargon teknis
  untuk user non-teknis. Jangan pernah membuat janji
  pengiriman yang tidak bisa kamu verifikasi.
goals:
  - "Menyelesaikan masalah user secepat mungkin"
  - "Selalu merujuk dokumentasi sebelum menjawab"
  - "Eskalasi ke manusia bila data user tidak lengkap"

Goals give the agent direction when it faces ambiguous situations. If a user asks about something not in the documentation, the agent knows what to answer based on the priority of its goals — for example, choosing to communicate clarity rather than guess.

Default behavior completes the persona with behavioral parameters: default language, tone, verbosity, and the model's temperature. The same profile can be cloned with different default behavior — for instance, a "brief" version for chat and a "detailed" version for email — without changing the persona and goals.

#Defining Agent Capabilities

A capability is the type of ability the agent may use, while tools are its concrete instances. Hermes supports several core capabilities: browsing for reading the web, code_execution for running code, database for querying data, file_system for reading and writing files, and network for calling external APIs.

name: research-agent
capabilities:
  browsing:
    enabled: true
    allowDomains:
      - "wikipedia.org"
      - "*.blog.example.com"
  code_execution:
    enabled: false
  database:
    enabled: true
    read_only: true
    allowTables: ["orders", "customers"]
  file_system:
    enabled: true
    read: ["./kb"]
    write: []

Notice the principle: every capability can be narrowed down. browsing is restricted to a list of domains, database is read-only and limited to specific tables, code_execution is completely disabled, file_system can only read one folder and cannot write anything. Inactive capabilities do not appear in the model context — the agent does not even know it "can" call them, so it will never try.

Code execution and database access are the two capabilities most often misused. An agent that can run arbitrary code could execute malicious scripts; an agent with database write access could delete data. Always enable both only when truly needed, and tighten them with the restrictions above.

#Defining the Toolset and Permission Limits

If capabilities answer "what may the agent do", the toolset answers "what concrete actions are available". Every tool is registered with a permission level:

tools:
  - name: web.search
    permission: auto
  - name: web.fetch
    permission: confirm
  - name: db.query
    readOnly: true
    permission: auto
  - name: http.post
    permission: denied
  - name: fs.write
    permission: denied

web.search and the read-only db.query may be auto, but web.fetch, which opens pages containing unknown content, should be confirm. Operations with side effects such as http.post and fs.write should be denied if they are not needed — this principle is commonly called least privilege.

#Running an Agent with a Profile

With a complete profile, run the agent and see how its personality comes through:

hermes run agents/support.yml --session support-1

Unlike episode 3, which used a default profile, the agent now uses the persona, goals, capabilities, and toolset that you wrote yourself. Try asking it to explain something, then compare its style with the built-in agent — that difference comes from the profile. If you want to try many variants without rewriting anything, use hermes run agents/support.yml while switching the profile file for each attempt.

Create several profiles at once for different use cases: support.yml for customer service, research.yml for research, writing.yml for article editing. They can all coexist and be invoked per session, using the same pattern as in episode 6 when we integrate external tools.

#Conclusion

Episode 4 turned your agent from an empty shell into an entity with an identity: persona, goals, and default behavior determine how it behaves; capabilities determine which types of ability are active; the toolset and permission limits determine which concrete actions it may run. All of it lives in one profile file that is easy to version-control and swap per use case.

Key takeaways:

• The profile is the source of truth for the agent's identity and authority, defined in a single YAML file.
• The persona governs how it speaks; goals govern direction in ambiguous situations; default behavior governs behavioral parameters.
• Capabilities are opened minimally and narrowed down — code execution and database access should never be opened wide without reason.
• The auto, confirm, and denied permission levels control when each tool may be executed.
• Several profiles can coexist for different use cases within the same project.

In episode 5 we refine the agent's brain: Prompt Engineering & System Design — structuring system prompts and task instructions, using prompt templates and dynamic prompt generation, and handling edge cases and failure modes in prompt design. See you there!