how I design a new Hermes Agent marketing specialist from scratch
every agent I run started as a pattern I noticed in my own work. here is the process I follow when I want to create agents
1. prototype in your main agent first
> open a session and try to do the work yourself
> run the same shape of task 2 or 3 times
> notice what you keep repeating, what context the agent needs, what tools it reaches for
> save the prompts and skills that worked
do not jump straight to a new agent. you do not know enough about the workflow yet.
2. decide open or closed
> open if the work is exploratory, requires taste, or has unpredictable inputs
> closed if the shape is clear, inputs are predictable, output is verifiable
> when in doubt, keep it open one round longer
3. write the soul. md
this is the agent's identity and purpose.
> what is this agent
> what outcome does it own
> what voice and standards does it follow
> what does it never do
skip the marketing fluff. the agent reads this every run.
4. pick the skill bundle
> what skills does this agent need to do its job
> bundle them so they load together when the agent fires
> reuse skills from existing frameworks (gStack, Superpowers, matt pocock's skills)
> if a skill does not exist yet, write the smallest version of it that works
5. define inputs, outputs, and triggers
> input: what does the agent receive (a row in a sheet, a topic, a URL, a brief)
> output: what does it return (a file, a row, a Slack message, a published article)
> trigger: cron, backlog, chat, or all three
if you cannot describe "done" in one sentence, the agent is not ready.
6. scope the tools
> allowed: only what is needed for the job
> not allowed: anything that touches production without approval (send email, edit CRM, post live, transfer money)
> default to least privilege, expand only when you need to
7. spin up an isolated environment
> own docker container
> own env vars and credentials
> own memory and skills
> own model choice (cheap and fast for throughput, stronger for review steps)
> register it in the control room
never share keys across specialists. if one gets compromised, you want the blast radius small.
8. run it on real work, iterate
> give it 5 to 10 jobs
> watch where it drifts, where it asks for help it should not
> tighten the soul, the skills, the eval
> retire the prototype version in your main agent once the new one is solid
9. promote it to production
> set the cron or wire the trigger
> add monitoring (output quality, run cost, runtime)
> document it in the control room: inventory, runbook, env-map, backup
