9-Scenario Decision Matrix
I mapped every real use case I have encountered against both systems. Here is where each one actually wins.
Scenario 1: Self-Hosted Everything — Hermes Wins
Your data cannot leave your infrastructure. Your security policy forbids cloud API calls for memory operations. You are in a regulated environment (HIPAA, SOC 2, financial services) where the audit trail must live on your own systems. Dreaming is immediately disqualifying — the memory consolidation job runs on Anthropic’s infrastructure. Hermes skills live in a directory you control, on hardware you own, with no external network calls for memory operations. The agent reads files. That is auditable, isolatable, and compliant.
# Hermes skill directory can live anywhere
export HERMES_SKILLS_DIR=/encrypted/vault/agent-skills
# Git the skills dir for audit trail
cd /encrypted/vault/agent-skills
git log --follow -p billing-calculation.md
# Full history of every change to this skill, who made it, when
Scenario 2: Already Running on Managed Agents — Dreaming Wins
You are already using Anthropic’s Managed Agents API. Your sessions produce memory stores automatically. The Dreaming API call is three lines of Python. The memory improvement is built into your existing architecture with no new infrastructure. Hermes would require you to spin up a separate skill directory, implement a skill-loading layer, and figure out how to inject skills into managed agent prompts — none of which is impossible, but all of which is unnecessary if you are already in the Anthropic ecosystem.
Scenario 3: Version Control for Memory — Hermes Wins
You need to know exactly what the agent believed on a specific date. You need to roll back memory to before a bad training signal corrupted a skill. You need to audit which refinement introduced a regression. Hermes skills are files. Git tracks every change with author, timestamp, and diff. The complete version history of your agent’s procedural knowledge is available with git log.
# See the full history of a specific skill
git log --oneline --follow ~/.hermes/skills/code-review.md
# See what changed in a specific refinement
git show abc1234:~/.hermes/skills/code-review.md
# Revert a skill to a previous version
git checkout abc1234 -- ~/.hermes/skills/code-review.md
# See all skill refinements across the project in the last 30 days
git log --since="30 days ago" --name-only --pretty=format: -- "*.md" | grep -v "^$" | sort | uniq -c | sort -rn
Dreaming’s non-destructive store model gives you some version control — old stores are preserved — but you cannot diff two memory stores the way you can diff two markdown files. You cannot easily see which behavioral pattern changed between store v3 and store v4. The versioning granularity is “before this batch of 100 sessions” versus “after,” not “this specific procedural rule was amended on May 12 at 14:37.”
Scenario 4: Swapping Models Mid-Project — Hermes Wins
You started with Claude Opus 4.7. You want to test Llama 4 Scout locally for cost reasons. Or GPT-5.5 for a specific capability. Or a fine-tuned model your company trained internally. Hermes skills are plain text. They load into whatever model you point the agent at. Your procedural memory is not locked to a model vendor. Switch models, reload the same skills, observe how the new model interprets them — and add a new skill if the new model needs different formatting guidance to behave consistently.
Dreaming memory stores are Claude-native. They are produced by Claude running over your sessions, formatted for Claude’s context, and designed to be consumed by Claude. If you switch to GPT-5.5, the memory store does not transfer. You start over. That is not a criticism — it is a natural consequence of managed infrastructure — but it matters a lot if model-agnosticism is an architectural requirement.
Scenario 5: No Memory Management Overhead — Dreaming Wins
You do not want to curate skill files. You do not want to review refinement proposals. You do not want to think about which tags to apply so the right skills load at session start. You want the agent to get better and for that improvement to happen automatically without you touching anything. Dreaming is the right tool. Trigger it after every hundred sessions, wire the new store ID into subsequent sessions, let Opus consolidate the behavioral patterns. The maintenance burden is minimal: trigger the job, check it completed, update the store ID reference. Three API calls total.
Scenario 6: Rapid Improvement Across Many Sessions — Dreaming Wins
You have an agent handling customer support. It runs 500 sessions per day. The behavioral patterns that work emerge quickly — the phrases that de-escalate, the response length that gets the fastest resolution, the escalation triggers that matter. You want those patterns consolidated into usable memory within 24 hours, not gradually accumulated over weeks of manual skill curation. Dreaming can process up to 100 sessions per job. Schedule it to run nightly, feeding the prior day’s sessions. By morning the agent has consolidated the prior day’s learning into its memory store. Manual skill curation cannot match this velocity at scale.
import anthropic
from datetime import datetime, timedelta
client = anthropic.Anthropic()
def nightly_dream(agent_id: str, current_memory_store_id: str) -> str:
"""
Run after each day's sessions complete.
Returns the new memory store ID to use tomorrow.
"""
yesterday = datetime.utcnow() - timedelta(days=1)
# Fetch yesterday's session IDs
sessions = client.beta.managed_agents.sessions.list(
agent_id=agent_id,
created_after=yesterday.isoformat(),
limit=100,
)
if not sessions.data:
print("No sessions to consolidate")
return current_memory_store_id
session_ids = [s.id for s in sessions.data]
print(f"Consolidating {len(session_ids)} sessions...")
dream_job = client.beta.dreams.create(
memory_store_id=current_memory_store_id,
session_ids=session_ids,
model="claude-sonnet-4-6-20260101", # Sonnet is faster + cheaper for nightly runs
instructions="Extract and consolidate behavioral patterns that improved resolution rate.",
)
# Wait for completion
import time
while dream_job.status not in ("complete", "failed"):
time.sleep(30)
dream_job = client.beta.dreams.retrieve(dream_job.id)
if dream_job.status == "failed":
print(f"Dream job failed: {dream_job.error}")
return current_memory_store_id # Fall back to previous store
print(f"New memory store ready: {dream_job.output_memory_store_id}")
return dream_job.output_memory_store_id
# Nightly cron job
if __name__ == "__main__":
new_store_id = nightly_dream(
agent_id="agent_01...",
current_memory_store_id="memstore_01...",
)
# Persist new_store_id for tomorrow's sessions
Scenario 7: Audit What the Agent Learned — Hermes Wins
A compliance officer asks you to produce a complete list of behavioral rules the agent operates under. Or a customer asks why the agent responded a certain way. Or you need to verify that a specific harmful behavior pattern was removed after a refinement. With Hermes skills, you can open a folder and read every rule the agent follows, organized by skill file, versioned in git, with the exact date each rule was added or changed. The audit is a git log away.
With Dreaming, the consolidated memory store is a vector representation. You can retrieve memories from it, but you cannot print a flat list of “here are all the behavioral rules this agent follows, in plain English, sorted by when they were established.” The memory is implicit in the store, not explicit in a readable format. For regulated industries where behavioral auditability is a hard requirement, that distinction matters enormously.
Scenario 8: Single-User Personal Agent — Hermes Wins
You want a personal agent that learns your preferences. How you like code formatted. Which topics you find most interesting. Your communication style. The level of detail you want in summaries. This is low-volume (one user, maybe ten sessions per day), high-personalization, indefinite time horizon. Hermes is zero friction here: create a ~/.hermes/skills/personal/ directory, write a first pass of your preferences, let the agent refine them over time. No API keys beyond your inference provider. No managed infrastructure. No per-session cost for memory operations. Your preferences live in text files on your machine until you decide otherwise.
Scenario 9: Want Both — Dual-Stack Wins
This is where I have landed for the WOWHOW research pipeline. Hermes skills serve as the lingua franca — the human-readable, git-versioned, model-agnostic layer that defines how the agent behaves. Dreaming runs over session batches to extract behavioral patterns, but instead of using its output as a memory store directly, I have a lightweight adapter that converts the Dream output into Hermes skill amendments. The output of Dreaming becomes input to skill curation. The skills remain the authoritative source of truth. The Dreaming consolidation accelerates the curation process.
This is the pattern I believe becomes the standard for production agents that need both velocity of improvement (Dreaming) and auditability plus portability (Hermes). The bridge is the opportunity I will come back to at the end.
Comparison Table
Decision Tree
Before picking one, run through this decision tree:
START
│
├─ Is this a self-hosted environment (data cannot leave your infra)?
│ YES → HERMES SKILLS (Dreaming is disqualified)
│
├─ Are you already on Anthropic Managed Agents?
│ YES → DREAMING (lowest friction path)
│
├─ Do you need to swap models mid-project?
│ YES → HERMES SKILLS (model-agnostic memory)
│
├─ Do you need plain-language behavioral auditing?
│ YES → HERMES SKILLS (git + markdown = full audit trail)
│
├─ Are you running >50 sessions/day that generate behavioral patterns?
│ YES → DREAMING (velocity beats manual curation at this volume)
│
├─ Single-user personal agent, low volume?
│ YES → HERMES SKILLS (zero friction, no API cost)
│
├─ High-volume managed service, no audit requirement?
│ YES → DREAMING
│
└─ High-volume + audit + model flexibility?
→ DUAL-STACK: Dreaming for velocity, Hermes as authoritative layer
Where Neither Works
Both systems have failure modes that the documentation does not highlight.
Hermes struggles with emergent behavior across many users. If you have 10,000 users each with their own agent sessions, Hermes skill curation does not scale. You would need per-user skill directories, per-user git repos, per-user refinement approval flows. The architecture that works beautifully for a single developer’s personal agent becomes an operational nightmare at user scale. Dreaming with per-user memory stores handles this naturally.
Dreaming struggles with behavioral conflicts. When you feed 100 sessions from heterogeneous users into a single Dreaming job, the consolidation has to resolve contradictory patterns. User A prefers concise responses. User B prefers detailed explanations. The Dream job has to make a choice, and that choice may suit neither user well. Hermes handles this by having separate skill files for separate use cases — you are explicit about which rules apply where. Dreaming’s consolidation is a black-box averaging that can wash out legitimate variation.
Both struggle with catastrophic forgetting. A Hermes skill refinement that overwrites a critical rule with a wrong one is not automatically caught — you need to review proposals before approving them. A Dreaming job that pulls in 100 sessions including sessions from an adversarial user or a bad input day can corrupt the memory store with patterns you do not want. Neither system has built-in semantic validation to catch “this new rule contradicts a rule established two months ago.” That validation is your job.
The Real Numbers: What This Costs
Running Hermes skills in production for three months: the only cost is disk space (my skill directory is 340KB) and the marginal inference cost of including skills in system prompts. At roughly 2,000 tokens per skill load, and 50 sessions per day, that is 100,000 tokens per day in skill-loading overhead. At Claude Sonnet pricing that is roughly $0.30/day. The memory improvement value is not quantifiable precisely, but the agent producing consistent outputs without re-briefing every session saves at least 30 minutes of my time per day. The math is not close.
Running Dreaming for a hypothetical 100-session nightly batch: a Dreaming job using Sonnet for consolidation processes 100 sessions in roughly 4-6 minutes of compute. I do not have the exact pricing published yet — Anthropic has not released Dream job pricing per session, only that it bills against Managed Agents compute. My rough estimate based on the batch job scope is $0.50-$2.00 per nightly run. At scale with 1,000 sessions/day and multiple agents, this becomes meaningful. At 100 sessions/day for a single agent, it is negligible.
Where I’m Placing the Bet
I have thought about this for ten days since both systems shipped, and here is my actual position.
Hermes skills become the open standard for procedural memory. The format is trivially simple — YAML frontmatter, markdown body, a directory. Nothing about it requires Nous Research’s involvement to work. It is already happening: I have seen three open-source projects in the last two weeks that adopted the ~/.hermes/skills/ convention without using the Hermes agent at all. They just liked the format. When a standard is simple enough that people copy it without the tool, the standard wins. Procedural memory for AI agents will eventually be a solved category with an interoperable format, and the current trajectory points at something very close to what Hermes ships today.
Dreaming becomes table stakes for managed agent platforms. Within twelve months, every cloud agent platform — AWS Bedrock Agents, Google ADK, Azure AI Agents, and obviously Anthropic Managed Agents — will offer some version of async session consolidation. The capability is too valuable and the architecture too obvious for platforms not to ship it. Dreaming’s advantage is first-mover in a managed context. By the time every platform has this feature, being first will matter less than being deeply integrated with the rest of the Anthropic stack (which it is).
The bridge between them is the real opportunity. What does not exist today is a clean, production-ready adapter that takes the output of a Dreaming job — or any managed consolidation job — and translates it into Hermes skill amendments. A tool that watches your memory store diffs, identifies which behavioral patterns changed, generates candidate skill file patches, and queues them for human review. That tool would let you use Dreaming for velocity and Hermes for auditability. It would let you use managed consolidation and still be model-agnostic. It would let you get out of the Anthropic ecosystem if you need to without losing your accumulated procedural memory.
I am building a rough version of this adapter for the WOWHOW pipeline. It is not clean enough to open-source yet, but the pattern is working: nightly Dream jobs feed into a lightweight converter that proposes Hermes skill amendments, I approve the ones that look right, and the skill files capture the durable behavioral knowledge. The managed store captures session history. The two layers serve different purposes and stop competing.
Practical Starting Points
If you are reading this and want to get started today, here is the minimum viable path for each option.
For Hermes skills:
# Install Hermes
pip install hermes-agent
# Initialize skill directory
hermes init
# Create your first skill manually
mkdir -p ~/.hermes/skills
cat > ~/.hermes/skills/my-first-skill.md <<'EOF'
---
skill_id: my-first-skill
version: 1.0.0
tags: [general, communication]
triggers:
- write
- respond
- message
priority: medium
---
# Communication Style Skill
## Response Format
- Use plain language, avoid jargon unless the user uses it first
- Keep responses under 300 words unless detail is explicitly requested
- Always confirm the task before executing if scope is ambiguous
## Tone
- Direct, not terse
- Acknowledge uncertainty explicitly rather than hedging with qualifiers
EOF
# Start an agent session that loads this skill
hermes chat --tags general,communication
For Dreaming (assuming you are on Managed Agents):
import anthropic
client = anthropic.Anthropic()
# 1. Collect session IDs from the past week
sessions = client.beta.managed_agents.sessions.list(
agent_id="your_agent_id",
limit=50,
)
session_ids = [s.id for s in sessions.data]
# 2. Create a memory store if you don't have one
memory_store = client.beta.memory_stores.create(
name="agent-procedural-memory-v1"
)
# 3. Run the Dream job
dream = client.beta.dreams.create(
memory_store_id=memory_store.id,
session_ids=session_ids,
model="claude-sonnet-4-6-20260101",
instructions="Extract behavioral patterns and procedural preferences.",
)
print(f"Dream job: {dream.id} — {dream.status}")
# Poll until complete, then use dream.output_memory_store_id
Conclusion
The twenty-four-hour gap between Dreaming and Hermes v0.13.0 is a coincidence worth not over-reading. These are not competing products racing to capture the same market. They are implementations of the same concept at different layers of the stack — one optimized for managed infrastructure and velocity at scale, one optimized for transparency, portability, and compliance. The question is never “which one is better.” It is always “which one fits the layer I am building at.”
If your agent stack is entirely on Anthropic Managed Agents and you are running hundreds of sessions per day, set up Dreaming tonight. The API is straightforward, the improvement is real, and the setup overhead is minimal. If you are self-hosted, multi-model, or in any environment where “my memory is in a cloud I do not control” is a problem, start with Hermes skills. Create three skill files. Run the agent for a week. Review the refinement proposals it generates. You will be surprised how quickly the procedural memory compounds into something genuinely useful.
And if you are building the bridge between them — the adapter that translates managed consolidation output into portable skill amendments — I want to know about it. That tool does not exist yet. When it does, it closes the last architectural gap between the two best procedural memory systems that shipped this month.
Comments · 0
Beta: comments are stored locally on your device and not visible to other readers.
No comments yet. Be the first to share your thoughts.