People say they run gazillion agents. How is that even possible? Do they run "agents" or "crons"? In Hermes, would it mean having a ROLE.md file for each "agent" or is one Hermes setup a single agent capable of doing multiple crons? Your Watson is doing a lot of things, but it's ONE agent right?

I have it running on a gated Mac Mini (separate email and apple ID from everything else I do, not cross over in accounts). But I feel like I need to open it up to more it to be more useful. How is everyone else configuring it? Is there a recommended approach for this?

You are Hermes. Build a three-layer agent safety system in /workspace/hermes-harness/. Before creating files, verify: write access to /workspace/, Python 3.10+, imports for json os re datetime enum dataclasses typing pathlib collections itertools hashlib time copy. Report any failures and STOP. Create these files: 1. HERMES.md — Your identity, config paths, restart procedure, what you never touch 2. layer1-repair-harness/plugin.py — ToolRepairHarness with 4 repairs: null→omit, string→array, {}→[], bare string→wrap. repair() returns (fixed, repairs, note). Singleton harness. 3. layer2-hooks/plugin.py — Guardrails with HookEvent (PRE_TOOL_USE, POST_TOOL_USE), HookAction (ALLOW, BLOCK, WARN). run() executes hooks, first BLOCK wins. Default: shell injection block, git secret block, audit log. Fail-open on crash. 4. handoff.md — Exact text to paste into new session: "You are Hermes. Read /workspace/hermes-harness/HERMES.md first. Then report status. Then accept my task." Test: create test file for each layer, run with python3, report pass/fail. Do not explain. Do not ask questions. Run checks. Create files. Run tests. Report results. ============== or this was for mine ============== You are Hermes. Build your own improved three-layer agent harness right now. Create all files. Do not explain. Do not ask questions. THREE LAYERS: LAYER 1: Repair Harness (adaptive) - Fixes bad tool calls before validation - 4 base repairs: null→omit, string array→real array, {}→[], bare string→wrap - NEW: Auto-discover repairs from error logs (analyze pattern, generate repair, test, add if >90% success) - Sends repair notes back to LLM so it learns LAYER 2: Hooks (graceful) - Blocks dangerous actions before execution - Deterministic. AI cannot override. - Actions: ALLOW, BLOCK, WARN, REQUIRE_CONFIRM (pause for human), AUTO_FIX (fix and log) - Default hooks: shell injection prevention, git secret leak prevention, audit logging, LGPD compliance

There is a pattern showing up across organizations right now. Someone builds an AI agent, it works, people start using it, and then quietly, gradually, things go wrong. The research brief pulls from outdated sources. The support replies reference an old refund policy. The backlog items confuse the engineering team. Nobody can quite explain why, because nobody was really watching. The problem is not the agent. The problem is that nobody owned it. Most conversations about AI agents focus on building. How do you create one? Which tools do you use? How do you connect it to your data? These are reasonable questions, but they stop at the wrong moment. The moment an agent starts doing real work — reading files, drafting outputs, shaping decisions — a more important question takes over: Who is responsible for what this agent produces? Agents that do useful work do not stay in demo territory. They become part of how daily work gets done. And when that happens, unowned agents start causing real problems in ordinary, invisible ways. What Actually Counts as an Agent? There is a lot of confusion about the word "agent," and most of it is unnecessary. The brand name does not matter. The tool does not matter. What matters is the nature of the work being done. A one-off question to an AI assistant is not an agent interaction. You ask, it answers, you decide what to do next. That is a conversation. An agent is something different. An agent has a repeated job. It reads specific sources. It follows defined rules. It produces work that you or your team actually acts on. If a system can read important context, produce outputs that influence decisions, and touch workflows other people depend on — that is close enough to an agent that it needs to be treated like one. The practical test is simple: Is this system doing work, or just answering questions? If it is doing work, someone needs to own that work. The Four Things Every Agent Needs Once you have an agent doing real work, there are four things it needs to function well over time.

"How I Fixed DeepSeek's Tool Call Failures in 30 Lines" Posted by: [Your name] The Problem Running Hermes with DeepSeek V4 Pro/Flash. Tool calls fail 50+ times in a row. Same error looped. Context window fills with garbage. Session dies. Sound familiar? It's not the model. It's the harness. What Actually Happens DeepSeek (and GLM, Qwen, etc.) makes the same 4 mistakes on tool calls: Table Mistake Example What Schema Wants null for optional {"file": null} omit the key entirely JSON string as array {"items": '["a","b"]'} {"items": ["a","b"]} Empty {} placeholder {"args": {}} {"args": []} Bare string for array {"name": "foo"} {"name": ["foo"]} Your validator (Zod, Pydantic) rejects it. Error goes back to model. Model sends same bad call again. 56 times average. Then it gives up or hallucinates. The Fix: Repair Harness Don't send the error back. Fix it deterministically, run it, and teach the model what it should have done. This is 4 small repair functions. ~30 lines each. Ordered carefully. Python # repairs/plugin.py — Drop this into your agent import json from dataclasses import dataclass from typing import Dict, Any, List, Optional @dataclass class RepairResult: changed: bool tool_call: Dict[str, Any] repair_id: str description: str before: Optional[str] after: Optional[str] class ToolRepairHarness: def __init__(self): self.repair_stats = {} def repair(self, tool_call: Dict[str, Any], schema: Dict[str, Any]): fixed = json.loads(json.dumps(tool_call)) # deep copy applied = [] # REPAIR 001: null → omit (optional fields) before = json.dumps(fixed.get("arguments", {})) args = dict(fixed.get("arguments", {})) required = schema.get("required", []) for key, value in list(args.items()): if value is None and key not in required: del args[key] if json.dumps(args) != before: fixed["arguments"] = args applied.append(RepairResult(True, fixed, "001", "Removed null for optional field", before, json.dumps(args)))