That was one of the first things I asked Hermes.
It feels almost embarrassingly simple compared with the setup I use today.
Now I have several specialised profiles for different parts of my work. There are skills, memory, configuration files, project-level AGENTS.md files, tool assignments and SOUL.md files that define how individual profiles should behave.
The first time I came across some of this, I didn’t even know what I was supposed to put into a SOUL.md.
A role? Rules? Permissions? All of it?
And compared with some Hermes power users I’ve seen, my setup is still fairly small.
If somebody showed me the whole thing on day one and told me I had to understand it before I could start, I probably would have found it pretty overwhelming.
Fortunately, that’s not how I started.
I wouldn’t start with the obvious questions
If you’re looking at an agent system for the first time, these seem like reasonable questions:
How many agents do I need?
What profiles should I create?
Which skills should I install?
How should memory work?
They’re not bad questions. I just don’t think they’re particularly useful at the beginning.
Each one opens another branch.
Once you start designing profiles, every profile needs a role. Then rules. Then tools. Maybe its own skills. You probably want to test it before trusting it with real work. Before long, you’re doing a lot of fiddly configuration work for a system that hasn’t actually helped you with anything yet.
I think there’s an easier way in.
Don’t begin by explaining to Hermes what kind of agent system you want.
Explain what you’re working on.
Tell it where the relevant documents are. Give it the basic goal of the project. Let it look through the context and ask you about anything it doesn’t understand yet.
Then tell it what keeps annoying you.
Something repetitive. Something you keep having to remember or clean up. Something boring but important enough that you can’t simply stop doing it.
That’s a much more useful starting point than deciding whether you need three agents or seven.
I just started typing
One thing that surprised me early on was how normally I could talk to Hermes.
I wasn’t writing carefully engineered prompts. A lot of my requests were fairly rough.
Sometimes I knew exactly what I wanted. Other times I really didn’t.
In my experience, Hermes was often quite good at looking for missing context on its own or figuring out what it needed before continuing. It sometimes seemed to think around the edges of what I’d actually asked instead of treating my wording as a rigid specification.
That made a big difference for me.
I didn’t have to learn Hermes terminology first and then translate my problem into it.
I could describe the problem in my own words and figure out the terminology later.
The same turned out to be true when my profiles needed improvement.
At first I assumed maintaining them would mean manually going through their configuration every so often and deciding what needed to change.
Now I often just ask the profile itself.
For example, I might start a session with my Librarian and ask something along these lines:
Look through your sessions from the past week. Check what went well and where things became difficult or required rework because the task wasn’t solved correctly the first time.
Give me a clear list of improvements you would recommend and why. Which files or configurations should be adjusted to make your work more reliable?
Don’t change anything yet.
That’s a very different job from me manually trying to guess whether a memory file, skill, rule or configuration needs tweaking.
I still make the decision.
But I can ask the agent that actually did the work to show me where it struggled.
The moment it started to click
I remember testing this more deliberately when I only had my first few profiles.
I asked one of them whether it knew which other profiles existed and what they were responsible for.
This was mostly a sanity check. Before I let profiles work together, I wanted to know whether the agent actually understood its environment.
The answer looked right.
So I gave it a simple task and asked it to use the integrated Kanban workflow to hand work to another profile the way Hermes was intended to.
I wasn’t completely sure how that was supposed to happen.
Hermes went and checked its own documentation.
Then it did it.
I watched the process in the Kanban dashboard. The task appeared. Another profile was assigned. That profile picked it up and started working on it.
I could follow the steps as they happened, and afterwards I could still see what had happened and who had done what.
That was probably the point where I stopped thinking quite so much about how I was supposed to wire all of this together.
A surprising amount of it was already there.
I still had to decide what I wanted the profiles to do and what boundaries they should have, but I didn’t have to build the underlying way they delegated work to each other from scratch.
Not everything worked perfectly, either.
Early on, my Librarian told me quite plainly that it didn’t have direct Kanban creation tools available in its current toolset.
That was useful too.
Hermes isn’t magic, and I’ve run into things that needed adjusting or a different approach. But that’s quite different from needing to understand and design the whole system before you can get anything useful out of it.
What I would actually tell a friend to do
If a friend installed Hermes tomorrow and asked me where to start, I wouldn’t give them my profile structure.
I’d probably tell them to type something close to this:
I’m working on [project].
The relevant files and documents are here: [path].
The goal of the project is [short description].
First, get a clear overview of the project and its context so you have a reliable understanding of what I’m working on.
If anything important is missing or unclear, ask me before we continue.
Once you understand the project, help me identify one repetitive but important part of my work that Hermes could take over or make easier.
For now, work read-only. Don’t create, change, move or delete anything. Explain what you would do first and wait for my approval.
That’s enough to start a conversation.
I wouldn’t ask it to build five profiles.
I wouldn’t install a collection of skills because somebody else’s setup uses them.
And I definitely wouldn’t try to design the final architecture.
Give Hermes the project first. Then give it the problem.
“Don’t change anything” is doing more work than it looks
I still explicitly tell agents not to change things when I’m exploring something new.
That might seem redundant. My profiles already have rules in places like SOUL.md and AGENTS.md, and some of those boundaries are defined very clearly.
But during an experiment, I don’t want my confidence to depend on whether I remembered to configure every rule correctly or whether the agent interprets one of them exactly as I intended.
So I say it again in the task.
Don’t change anything yet.
Don’t delete anything.
Show me what you would do first.
Then I decide.
That small boundary makes it much easier for me to experiment.
I can give Hermes access to real project context and ask fairly open questions without immediately handing over control of the project itself.
And I think that’s the part I would have wanted to know when I started.
If you look at my Hermes setup today, you’re looking at the result of many small problems being solved over time.
You’re not looking at the prerequisite.
My first step wasn’t an agent architecture.
It was a normal question typed into a chat.
The rest came when I actually needed it.