Last Week

Last week, the memory system behind Hermes was finally paying off. OpenViking was helping the agent remember how I like to work, and I was spending less time repeating instructions. I expected that progress to free me up for Shokken marketing.

Instead, I spent most of this week trying to get Hermes into a usable state. The problem was not memory this time. It was asking an autonomous team of agents to configure the very installation they were running on, while I was also managing that configuration through Ansible.

What looked like a sensible way to finish the setup became a moving target.

Why Ansible Seemed Like the Right Tool

I am gradually moving more of my workflow from the Codex desktop app to Hermes. I want something closer to a general personal assistant than a tool I only open when I need to write code.

The ability to use different model providers is part of the attraction. I am experimenting with a mixture of backends, and I want the freedom to change that mixture as my needs and the available plans change. I have not settled on the final arrangement.

That flexibility comes with configuration work. Hermes can be tailored to the way I work, but getting it there has involved a lot of tinkering. I want my own version of Jarvis, and that desire makes it easy to keep adding one more rule, skill, tool, or dependency.

I already use Ansible to manage my computers and services: my laptop, Windows machine, AI inference machines, servers, and GitHub runners. Across that fleet, manually keeping packages, updates, and configuration aligned would be a lot of work.

Ansible lets me describe the setup I want and apply it to the relevant machines. It also gives me a reasonable starting point if I need to reinstall something. Credentials and logins still need attention, but much of the machinery can come back from the configuration I have recorded.

So putting Hermes under the same management seemed natural. Its dependencies, including the OpenViking memory system I discussed last week, were already part of that work. Why not have Ansible manage the Hermes configuration too?

What Does It Mean in English?

A Kanban board is a way to move work through stages. A task starts in triage, becomes something ready to implement, moves into progress, and eventually reaches review and completion. It gives a team a shared picture of what needs to happen.

That is useful even for a solo developer now that an “individual” workflow can involve several agents. I am increasingly managing a team rather than doing every piece of implementation myself.

I configured the Hermes board to take that idea further. It could triage a request, split it into smaller cards and pull requests, implement them, arrange reviews, and merge the results.

The mistake was using that workflow to finish configuring the running Hermes installation before I had made the boundaries clear.

There were several different versions of the setup:

  • The configuration currently running on the machine.
  • The configuration merged into the repository, which Ansible had not yet applied.
  • Changes committed locally that had not been pushed or merged.

A change could be finished in the repository without being active in Hermes. Another change could exist in a local branch without being present in either the merged repository or the running installation.

When I asked whether something was configured, “configured where?” became a much more important question than I had realized.

A Dozen Cards Became Fifty or Sixty

I started with a number of things I wanted the agent to do. It produced about a dozen cards. Investigate, implement, review, merge: that sounded manageable, so I went to bed.

I woke up to fifty or sixty cards.

The different states were creating confusion. An agent would encounter a conflict or inconsistency and open another investigation. By the time that investigation became active, more changes had happened and the target had moved again.

I added to the problem. I could not keep track of what was already merged, what was only local, and what had actually been applied. I ended up asking for the same work more than once.

Last week, I was happy that memory had reduced the frustration of repeating instructions to an agent. This week, I was the one repeating requests because I had lost track of the state.

The agents had a similar problem. Unless I spelled out the intended target carefully, an instruction could be interpreted as a request to change the repository or a request to change the live installation. The board kept producing work, but more work was not bringing the setup closer to a clear, finished state.

The volume of updates made it harder to notice what was happening. Each card came with a lengthy report. In my hurry to get through them, I skimmed details that might have helped me identify the problem sooner.

Asking for summaries might have lost some detail too, but glossing over the reports was hardly an improvement. I spent time and model credits investigating confusion that the workflow itself was generating.

Resetting the Boundary

Eventually, I decided to reset the setup rather than keep chasing the inconsistencies.

I wrote down what I wanted by hand and established a simpler rule: changes to the Hermes installation would happen locally, and Ansible would stop tracking its installation and configuration for now.

That gives me one place to work while I am still changing the setup every day.

My initial plan is to reach a configuration I am comfortable with, freeze it, and have Ansible capture that arrangement. I am not certain that a useful freeze point will arrive, though. Hermes keeps evolving as I add skills, change preferences, and learn what I need from it.

Another possibility is to use Ansible to seed a fresh installation, then handle the agent’s accumulated state through its own backup and restore process. I am still working out that boundary. The lesson from this week is about how I combined these workflows, not a conclusion that Ansible and Hermes can never work together.

The backups matter either way. Hermes holds memories about how I work, skills I have added, and information from the work we have done together. Recreating the installation is only part of recovering the assistant.

Losing that accumulated context would feel like replacing an assistant and starting the onboarding process again. I am backing it up because I do not want to repeat that work.

Next Week

I think I am finally at a point where I can become productive again. The next priority is the marketing pipeline for Shokken, especially social media exposure.

The app-store optimization from the last few weeks is showing results. Discoverability, downloads, and app opens have increased, and I am seeing more consistent traffic. The starting point was close to zero, so I do not want to turn that into a claim of major traction. It has not produced a paying user yet.

Still, it is movement, and I need to widen the top of the funnel.

I want help producing useful product videos more frequently, including tutorials, longer explanations, and short-form content. I am going to explore OpenMontage as a possible part of that workflow with Hermes. I have not built or proven that pipeline yet; I hope to have a mostly automated video to show within the next couple of weeks.

Shokken is available on Google Play and the iOS App Store. If you are interested in the restaurant waitlist tool, the product website is the place to start.

This week was mostly consumed by the Hermes transition. Now I need the tools to help me get Shokken in front of more people.