RUDR9 — Turning Hermes Agent Into a Dev Team via Toolset Restriction, Not Prompts

Source: raw/reddit-1uxnr3u.md — u/humanth-shashani on r/hermesagent, “RUDR9 - Turn Hermes Agent in to dev-team” (SHOWCASE flair, score 43, 11 comments, posted 2026-07-16). Corroborated by a direct fetch of the repo (github.com/ardhaecosystem/RUDR9, MIT, 29 stars, Shell-dominant) at ingest time.

RUDR9 is a one-command installer that turns a fresh Hermes Agent install into a multi-role development organization: a default profile acting as CTO plus specialist profiles for planning, architecture, version control, building, security auditing, performance auditing, and review. Coordination runs through Hermes’s built-in Kanban board — the CTO creates tasks, a dispatcher spawns the assigned profile as a worker, and results flow back through task comments and linked dependencies. The distinguishing claim, and the reason this is a distinct technique from other Hermes multi-agent templates already in the wiki, is that role authority is enforced by restricting which tools a profile has, not by instructing a shared-tool model to behave a certain way — and the author discloses, unprompted, exactly where that enforcement still has holes.

Key Takeaways

• Toolset restriction as the authority mechanism. The Planner profile has no file-write tool at all; the Security Auditor has no terminal. The stated principle: “cannot write code” means the tool isn’t present, not that the model was told not to — a structural claim rather than a behavioral one. A rudr9-guard plugin (a pre_tool_call hook, per the repo’s own description) adds a second enforcement layer that catches anything the per-profile toolset configuration misses — “belt + suspenders authority enforcement at the tool-call level.”
• Role count: branded as “9,” enumerates as 8. Both the Reddit post and the repo’s own README describe a CTO/default profile plus seven named specialist roles (Planner, Architect, Version Control Manager, Builder, Security Auditor, Performance Auditor, Reviewer) — eight roles total, not nine, despite the project’s name and the installer’s own “9-role development organization” tagline. The installer’s setup steps confirm this count independently: it creates seven Hermes profiles (the specialists) alongside the pre-existing default (CTO). Neither source resolves the naming discrepancy.
• The author discloses the enforcement gap, not just the feature. Builder and Version Control Manager both retain terminal access, so the “physically cannot” framing does not hold for those two roles specifically — the guard plugin checks tool names, not command content, so a determined Builder can still write application code by shelling out. The real fix for that gap (branch protection or merge tokens) is named explicitly as not yet wired up, rather than glossed over.
• Other disclosed limitations: the repo uses the deprecated reference @modelcontextprotocol/server-github MCP server rather than the newer official one; there is no CI workflow (a Dockerfile exists for manual testing only); and install time was originally ~8 minutes because a shared skill was being security-scanned once per profile on every install, fixed down to ~30 seconds by installing that skill once on the default profile first, since cloned profiles inherit skills from default (the fetched README names this shared skill “Ponytail”).
• A built-in adversarial review, partially rejected. The repo includes an architecture review of RUDR9’s own design authored by Claude Opus, which argued the 9/8-role structure is over-engineered and recommended collapsing it to 3 roles; the author states they partially disagreed rather than accepting or dismissing the critique wholesale. Shipping a self-critical review inside your own repo, and stating exactly how much of it you accepted, is itself a notable disclosure norm for a SHOWCASE post.
• Confirmed via the repo directly: MIT license, 29 stars at ingest, Shell-dominant (79.3%) implementation. The installer’s stated steps are: create seven Hermes profiles, configure per-profile permissions, install the Ponytail skill across all roles, deploy the rudr9-guard plugin, and initialize the Kanban coordination board.

How This Differs From the Wiki’s Existing Multi-Agent Hermes Template

tonbistudio’s Hermes Multi-Agent Workflow is the wiki’s other reference Kanban-coordinated Hermes pipeline, but it solves a different problem: it’s a fixed intake → dedup → score → research → route → human-gate → fulfill pipeline for triaging incoming items (support tickets, content candidates, etc.), with the Kanban board as the message bus between pipeline stages. RUDR9 also uses the Kanban board as its coordination substrate, but the roles it coordinates are software-development functions (plan, architect, build, review, secure) rather than triage stages, and its headline technique — restricting the toolset per role rather than the prompt per role — doesn’t appear in the triage-pipeline template at all. The two are complementary references for “how do Hermes agents coordinate,” not competing implementations of the same idea.

Try It

• If you’re running any multi-profile or multi-agent Hermes setup where roles are supposed to have different authority levels, treat RUDR9’s core claim as a design test for your own setup: can a “read-only” or “review-only” role actually write files or run shell commands if it tries, or is that restriction only a prompt instruction? A tool that isn’t present is a harder guarantee than a model told not to use it.
• Read the gap disclosure before adopting this for anything beyond a demo. Builder and VCM having terminal access is a named, real hole — don’t treat the “9-role dev team” framing as a completed security boundary until branch protection/merge tokens are wired up.
• If you install a shared skill across several cloned Hermes profiles, install it once on the default profile first — this project’s own ~8min → ~30s fix for repeated per-profile security scanning is a directly reusable optimization for anyone building a similar profile-cloning setup.

Related

• Hermes Multi-Agent Workflow — Kanban-Coordinated Triage Pipeline Template — the wiki’s other Kanban-based Hermes multi-agent reference; a different coordination problem (triage pipeline vs. dev-team roles) solved with the same board-as-bus substrate.
• Hermes Profiles & Multi-Instance — the underlying Hermes primitive (cloneable profiles with independent config) that RUDR9’s installer builds its 7 specialist roles on top of.
• Hermes Agent — Security Model — general Hermes security background; RUDR9’s rudr9-guard pre_tool_call hook is a project-level addition on top of, not a replacement for, Hermes’s own security model.
• Hermes Skill Bundles — background on how Hermes skills are packaged and scanned; directly relevant to the “Ponytail” install-time bug and its fix.
• Hermes MCP Catalog — context for the deprecated @modelcontextprotocol/server-github reference this project still uses instead of the current official server.
• Agent Guardrails: Hooks, Permissions, and Sandboxing Patterns — the general hooks/permissions/sandboxing taxonomy; RUDR9’s toolset-restriction-plus-guard-hook is a Hermes-ecosystem instance of the same “permissions layer plus deterministic hook backstop” composition documented there.
• Hermes Agent — topic landing page.
• Structural Safety Enforcement — the cross-topic synthesis pairing this project’s toolset-restriction design with Custodian’s kill switch and Anthropic’s Agentic Misalignment research on why prompted-only safety has a real failure rate.

Open Questions

• The 9-vs-8 role-count discrepancy (both sources describe 8 distinct roles under a “9-role” / “RUDR9” name) is unresolved — neither the Reddit post nor the fetched README explains what the ninth role or count basis is meant to be.
• The repo’s own tagline references “PAUL-inspired workflows” without further explanation in either source reviewed at ingest — not investigated further, flagged here in case a refresh finds the reference explained elsewhere in the repo.
• Adoption is very early (43 score, 11 comments, 29 stars) with a single maintainer — durability and whether the branch-protection gap ever gets closed are both unverified.
• The internal mechanics of the rudr9-guard plugin (exactly which tool-call patterns it catches beyond what per-profile toolset config already blocks) were not detailed in either source — only the “belt and suspenders” framing.