I Built a Custom Hermes Around Claude Code

▶️ Watch the full video

General-purpose agent tools cover many needs. They also impose their menus, objects, and preferred way of working. When an agency has its own roles, approvals, repositories, and client constraints, part of the job becomes working around the tool.

I approached the problem from the other direction: keep Claude Code as the execution engine and build the system I needed around it. The product follows a task from a Kanban card to a mission, exposes tool calls and token usage, and stores the result in an interface I can change in the source code.

What the product does today

The current system has two Claude Code execution modes. The first runs a mission non-interactively. The second controls a persistent interactive session in tmux. Agents and skills keep the .claude formats, so the product does not create an incompatible ecosystem.

The working path looks like this:

Kanban card
→ mission created
→ runtime selected
→ Claude Code execution
→ visible tools and events
→ stored result
→ available metrics

The value does not come from a new model. It comes from the product layer: business objects, interface, persistence, approvals, and measurement.

Layer	Role in the system	Visible example
Claude Code	understand and execute the mission	non-interactive job or tmux session
Agents and skills	apply roles and procedures	reused `.claude` files
Product	organize real work	Kanban, missions, history
Measurement	make activity readable	tokens, tools, states, and results

Why two execution modes?

The non-interactive mode fits bounded jobs: generate a report, audit a directory, or apply a procedure with an expected output. It is easy to launch from a card and track as a job.

The tmux session keeps the context of a longer interaction. It lets me take control, inspect the session, and continue work that needs several decisions. These modes are complementary because they serve different tasks.

A short mission does not need a persistent session. Exploratory work should not be forced into a blind job. Keeping both modes prevents one interface from pretending to solve every case.

The practical value for an agency

An agency does not sell a Kanban board. It sells a reliable way to complete domain work. Access to the source code allows generic objects to be replaced with client-specific ones: content requests, legal approval, code review, campaign preparation, or internal support.

A serious adaptation covers:

agent roles and procedures;
approved data sources;
human approval steps;
evidence required before a mission can close;
views and metrics that matter to the business.

The product can then become an internal system or the base of a client offering. Customization is not a color change. It translates a real workflow into objects, permissions, events, and evidence.

Current limits

I do not present this base as a team SaaS that is ready to expose to the Internet. The current version does not yet provide SSO, RBAC, multi-user accounts, or distributed orchestration. It requires a controlled environment and technical adaptation.

Those limits separate a working product from a vague promise. The system runs my workflows, exposes its code, and displays its results. An agency still needs to decide how to isolate, authenticate, maintain, and adapt it for each client.

Building around an engine you already know

This approach reduces the number of layers to rebuild. Claude Code already handles repository exploration, tools, and execution. The product focuses on what my operation was missing: start a mission from the right object, follow its state, store its history, and adapt the interface to the domain.

The video shows the product, both execution modes, a complete task path, and the source files behind the customization: watch the demonstration.