Kanaban

Hermes – full automata

Posted on September 4, 2026

An experiment in turning Hermes into an autonomous software development pipeline – from a rough idea and architecture, through task decomposition and implementation, to documentation and recovery. The goal is not just to see whether the agent can write code, but whether it can manage the entire development process with minimal human intervention.

The experiment combines Hermes Remote Agent, Hermes Desktop, a Kanban-based workflow, specialized profiles, and persistent memory. An architect agent plans the system, development agents implement the work, and documentation is handled as another part of the automated workflow.

The interesting part is where autonomy starts to break down: task sizing, model selection, token limits, context management, rate limits, code review, and security. Some of these problems can potentially be solved through better skills and workflow design rather than simply using a stronger model.

I’m testing this with GLM-5.3 to see how close we can get to a full automata – a system where the human provides the goal, while the agents figure out the path from idea to working software.

Goal

  • Build an autonomous design and coding agent.
  • Evaluate Hermes’ ability to fulfill this goal.

What is involved

  • Hermes Remote Agent
  • Hermes Desktop
  • Kanban board
  • Profiles: architect, java-dev, nuxt-dev

The workflow

  1. The architect defines the system based on a given plan. The plan is written in natural language and includes some engineering insights.
  2. The architect creates a detailed plan. In my example, this is a set of .md files. We can either accept the plan or modify it. The architect can also ask questions. The Kanban board supports comments inside cards. Later, I think we could allow the architect to ask other agents for solutions, e.g. when the task involves environments, CI/CD, deployment, or monitoring systems.
  3. The next task goes to java-dev / nuxt-dev, which define implementation tasks based on the parent task created by the architect.A stronger model could still be used at this stage. Tasks can be placed in Todo or Blocked, depending on how we want to run the process and manage token consumption.
  4. Todo tasks are picked automatically based on priority. Blocked tasks need to be moved to Ready or Todo before they can be started.
  5. For documentation, I use an obsidian profile that moves the .md files to the Obsidian vault, either from a parent task or as a standalone operation after certain phases as a summary.This profile knows the vault path and other details related to the notes.

Questions

  1. Triage seems to be autonomous. We define the goal, and it works as an architect, determining what needs to be done. Therefore, giving it only a rough idea of the goal might actually be the best approach.
  2. Model costs. Use a stronger model for the architect and task creation so that important details are not missed. Use a faster model for implementation.
  3. Security and code review. For code review, it would probably be better to use a separate model. Security requirements should be part of the SOUL.md files for all profiles involved in coding.
  4. Memory: I added Supermemory for now. Honcho will be an option if I switch to a better machine.

Other information

  • For this test, I used GLM-5.3, with the option of switching to the fast version if the test cannot be completed within the weekly limits.
  • If the job stops because of rate limits or for another reason, we can run hermes --resume 20260904_072506_80bf77 -p java-dev. This command is always included in the Kanban task details. In my tests, it was better to run java-dev --resume 20260904_072506_80bf77 directly from the CLI. Basically, we can drag and drop the task back to the READY column and fix things if required.
The previous worker runs died on Z.AI rate limits mid-task, but the working tree already contains a large chunk of the attachments implementation. I'll pick it up from there: verify what exists, finish the remaining scope, run ./mvnw verify, commit, and complete the task. First, orientation in the repo.
  • I often hit the 90/90 step limit. In the beginning, I thought it was related to the log size and operations on the logs. I forced Maven to log to a file and used head -30 to only get the SUCCESS/FAILURE result. The context wasn’t filling up as quickly as before.

Results

  • GLM-5.3 agentic coding is … slower than Claude, but with my plan it seems to be able to code forever. Of course, I moved some tasks to fast and reduced the amount of logs.
  • I still work with correct workspace assignments, especially with Git — I force it to use worktrees. I was surprised that it chained tasks into features after creating the tasks.
  • Triage created tasks that were too large. Even Claude suggested splitting them into smaller ones. I guess I will define this in the card-creator skill or implicitly suggest it in the parent task.