A Chatbot Became Useful When I Let It Touch My Real Systems
I had an idea for a blog post sitting in a Kanban column called Selected.
I typed one message: work kanban task.
Hermes did not immediately produce a post. It read the card, loaded the blogging workflow, opened the repository, checked related material, and left an editorial outline in the workspace. The board still knew what was happening. The outline was a real file. A human decision was still required before publication.
Why is this more useful than opening a chat window and asking for an outline?
Because the message was attached to a workflow. The chat was only the handle. The useful part happened in the systems around it.
The chat window is the smallest part
A chat assistant can produce an answer. That answer is easy to lose, hard to review, and disconnected from the next action unless somebody puts it somewhere useful.
In this case, the flow looked roughly like this:
message
-> Kanban card
-> blogging profile and skill
-> repository workspace
-> outline artifact
-> human review
Every step has a place where I can inspect it. The card has a state. The workspace has files and a Git diff. The skill contains the writing rules. The final post can be built with Hugo. If something is wrong, there is a smaller thing to fix than “the AI behaved strangely.”
This sounds obvious. It is not how most assistant demos work. Demos usually end when the assistant finishes typing.
Files and repositories are the first layer
Hermes can work inside a known workspace. That changes the job considerably.
When I ask it to edit a blog post, it can first inspect the repository instructions, read neighboring posts, check the front matter shape, and run the actual Hugo build after the edit. The result is not a paragraph floating in a chat transcript. It is a Markdown file that belongs to a project and can be reviewed like other project changes.
That creates a useful discipline:
- inspect the existing files before changing anything;
- keep the work inside an explicit workspace;
- make the smallest useful change;
- run the project’s real build or tests;
- treat the diff and command output as evidence.
The last point matters most. An assistant saying “the build should pass” is not verification. A build that exits with status zero is verification. A page that renders at the expected URL is better still.
The repository remains the source of truth. Hermes is a way to reach it conversationally and to perform the boring sequence around a change.
Scheduled work changes the relationship
A chat is pull-based. I ask, and the assistant responds.
A scheduled job lets a small process continue to exist when I am not talking to it. A script that collects data and produces a fixed output is usually predictable. An LLM-driven job can decide what deserves attention, but it needs narrower inputs, clearer failure behavior, and an observable result.
I do not want a nightly agent with an enormous mandate to “manage my life.” I want a job with a small input, a clear output, and a quiet way to do nothing when there is nothing worth reporting. Every recurring process should answer:
- What does it read?
- What does it write or send?
- What happens when the source is unavailable?
- Where can I inspect the last result?
- How do I stop it?
Cron is not magic either. It is a process that needs an owner and an output.
Notes and memory need a boundary
I keep durable notes in Obsidian. That makes the boundary fairly clear: Obsidian is the note store; Hermes is one of the processes that can read, summarize, and route information around it.
The tempting design is to save everything. Every preference, every temporary decision, every fragment of a conversation. This quickly creates a second problem: the assistant has plenty of context, but none of it has a useful signal-to-noise ratio.
A durable note should earn its place. A fact belongs there when it will still matter later. Temporary task state, duplicates, and private details with no future use should stay out.
Durable state is valuable because it is selective. A source of truth is not a warehouse for every intermediate thought.
Real systems have different consequences
Home Assistant and Mattermost are both endpoints Hermes can reach, but they are not interchangeable.
One can change the physical environment. The other can change what another person sees. Reading a temperature sensor, calling a light service, and sending a message are three different actions with three different consequences.
That means tool access is a capability boundary, not a convenience feature.
For a read-only operation, the main questions are whether the data is correct and whether it is safe to expose. For a side effect, I also need to know exactly what will change, whether the action is reversible, and how to verify the result afterward.
A sensible flow for a consequential action is:
discover available capability
-> choose an explicit target
-> perform one narrow action
-> read the resulting state
The assistant should not receive unrestricted access simply because it can make a tool call. A chat interface makes actions feel lightweight. The connected system knows better.
The board supplies the missing state machine
Kanban is where the pieces become a process instead of a pile of integrations.
This post followed that path. Hermes left an outline in the repository. I reviewed it, approved a draft, and published this page. Each handoff had a visible state and an artifact I could inspect.
For my personal automation work, the states have practical meaning:
- Triage means I captured something without deciding what it is.
- Selected means I chose it as worth doing.
- Ready means there is explicit permission to start.
- Running means a worker is active.
- Review means a person or another worker must inspect the result.
- Done means an external outcome exists: a published page, a merged change, a sent message, or another clearly completed result.
This is more important than it may look. Without a state machine, an assistant can accumulate invisible side effects. A response exists, a file may have changed, and nobody knows whether the work is finished or merely plausible.
A card does not become done because a worker stopped talking.
The current blog card is a small example. The worker first produced an outline; I then reviewed the draft and explicitly published this page. That distinction is useful. A generated artifact does not quietly become a published claim.
What Hermes is not
Hermes is not a replacement for Git, Obsidian, Home Assistant, cron, or Mattermost.
It does not turn an ambiguous request into a safe specification. It cannot make verification disappear. It should not be given every permission just because one broad tool is easier to configure.
The useful design is simpler: let the conversational layer decide what should happen, then let an existing system perform and record the operation.
This is late binding applied to personal automation. The request stays flexible until it reaches the system that owns the state. Git owns the diff. Obsidian owns the note. Home Assistant owns the device state. The board owns the lifecycle.
Hermes connects them without pretending to be the source of truth for all of them.
A practical starting point
If you want to build something similar, start with one boring task.
- Choose one real system and one repeatable operation.
- Define the source of truth.
- Define the artifact or state change the task must leave behind.
- Give the assistant only the workspace and tools it needs.
- Add an explicit human promotion or review boundary.
- Run the manual path until the failure modes are visible.
- Schedule the task only after the manual path is reliable.
- Verify state after every consequential side effect.
- Preserve logs, outputs, or diffs that explain what happened.
- Make “done” mean an external result, not a completed chat turn.
The chat window is still where I start many things. It is simply no longer where they end.
The useful part begins when the message reaches a file, a board, a scheduled process, a device, or another person — and when I can still see what happened afterward. In this case, the final artifact is this page, built from a reviewed file and linked back to the card that started it.
That is a narrower claim than “AI will automate everything.” It is also much more practical.