Hermes is my personal assistant. Mine, not the large open source project that later took the same name. I had already called the folder ~/Hermes before that one shipped. The name was mostly obvious for a system that carries messages, signals and decisions, and the code has no ambition to become a generic product. It is useful to me precisely because it is so personal.
I built it because part of my working life looks like that of many freelancers and small teams. Important things are scattered across Gmail, GitHub, Sentry, Pennylane, Things (my task manager), Markdown files, internal dashboards and a few corners of my brain that would rather have been used for something else. A CI run that fails, a Sentry error that keeps coming back, a quote to follow up on, an invoice to track, a project almost finished that risks getting stuck. None of these is hard on its own. Their accumulation, on the other hand, ends up producing a fairly mediocre kind of mental load.
The ridiculous pitch would be to say I built a “personal agentic operating system”. I could even add “AI-augmented” to make sure I lose everyone except two LinkedIn consultants and a prompt engineering course salesman. The reality is simpler. Hermes is a set of small local agents running on my Mac, with state files, Python scripts, a private dashboard, a few business integrations, and above all fairly strict rules about what they are allowed to do.
Some agents use an LLM. Many do not. That distinction matters, because the right use of AI is not to replace every if with a prayer billed by the million tokens. When a task is deterministic, a dumb reliable script is usually better. When heterogeneous signals need summarizing, an arbitration needs proposing or three clear options need laying out, an LLM can earn its place. Adding AI everywhere is easy. Knowing where it genuinely deserves to enter the loop is the hard part.
A personal tool, not a generic framework
I increasingly think AI becomes genuinely effective when it is embedded in a very personal tool, in the strict sense: a tool built for one person, with their reflexes, their blind spots, their priorities and their way of deciding. Hermes is not a plugin bolted onto my work. It is an extension of how I work, made of my information sources, my risk thresholds, my decision habits, and the exact places where I want to take back control.
That is why I am fairly wary of generic agent frameworks sold as shortcuts. They can be useful for prototyping, but their structure already carries a view of what work is: how memory behaves, how tasks are routed, what counts as success, when to escalate, how to notify, what qualifies as an action. Using someone else’s framework without questioning it often means adopting someone else’s logic. Sometimes it fits your problem. More often it fits the demo of whoever wrote it.
We have seen this film before with React SPAs. For years, brochure sites, tiny back offices and rather ordinary forms absorbed Facebook’s complexity while believing they were becoming Facebook. What they mostly got was the mental cost, the oversized bundles, the fragile client state and the hydration bugs, without ever having the problem that justified the architecture. AI is walking the same path whenever people start by picking an agent stack before understanding the actual work to automate.
So Hermes is deliberately built around my constraints. My inbox is my todo list. Things is where the real actions live. The dashboard carries passive information. Telegram is for urgent arbitrations. Clients, quotes, incidents and projects already have their sources of truth. The system does not get to invent a parallel world, it has to connect what already exists and interrupt me only when that is worth the cost.
What the system has to solve
The starting need was not “having an agent”. I did not need one more chatbot to remember to talk to, to re-brief with context, and then to double-check. That is sometimes useful for thinking out loud or producing a draft, but it does not really remove the operational load. It moves that load into a chat window, with a more polished interface and the same problem behind it.
What I wanted was to know each morning what deserves my attention, to avoid finding out too late about a blocked PR or a production error, to track quotes without turning my brain into a low-budget CRM, to keep client context available before a call, and above all to finish the things that are close to done instead of opening fifteen fronts at once. Most of these needs are prosaic. That is exactly why they matter. A useful tool usually starts by removing mundane friction, not by announcing that it will reinvent work.
The boundary I set from the start is simple. Hermes may observe, classify, summarize, prepare, flag and propose. It must not mistake itself for me. It does not publish a quote, does not send a client email, does not make an architecture decision, does not modify a project beyond trivial fixes, and does not manufacture noise to prove it is working. I already have enough software that confuses activity with usefulness.
Anonymized overview. The dashboard keeps actions, signals and agent state in one place, without turning every piece of information into a notification.
Deliberately ordinary architecture
Hermes runs locally on my Mac. A scheduler managed by launchd reads a schedule.toml file, works out which agents are due, applies simple preconditions, then launches the jobs. Runs write their logs, their state, and an HTML dashboard page. Shared state lives in JSON or JSONL files, the more human notes are in Markdown, and deterministic tasks go through Python scripts.
This architecture will impress nobody at an AI conference, and that is fine. I would rather have a system I can understand at 11pm, when something stops working, than a magical platform where three proprietary abstractions hide a cron, a queue and a prompt. The day it breaks, I want to open a file, read a log, work out which agent wrote what, and fix it. The rest is often decoration sold at SaaS prices.
The scheduler also caps concurrency. It does not launch twenty agents because twenty agents exist. Some jobs run in pure Python, particularly where the logic is stable and an LLM call would only add cost and randomness. Others go through a model when they have to aggregate less structured signals. The mix is not very dogmatic, but it has the merit of being honest. AI is a component, not an architectural religion.
Agents with a narrow job
Every agent has a tight scope. That is probably the most important choice in the project. A “general assistant” agent quickly swallows all available context and acts with a confidence inversely proportional to its actual understanding. An agent that reads one specific queue, produces one specific state and writes one specific dashboard is far more boring, and far more usable.
The morning briefing prepares the start-of-day summary: PRs to review, failed tasks, overnight activity, Sentry signals, work queue. Inbox triage reads the Gmail inbox, since my inbox is deliberately a todo list. It classifies threads, spots the ones that are aging, and can draft simple administrative replies, but it never touches client or prospect mail. Project focus picks the three projects to push that day, favoring whatever is close to done, whatever got a client signal, or whatever risks getting stuck.
Dev agent is tighter still. It can handle a few obvious Sentry errors, risk-free Dependabot merges, or mechanical CI fixes. It has no right to do product, architecture, refactoring or ambiguous application bugs. The slightest doubt falls out of scope. Frustrating for a demo, very healthy for a tool that touches real repositories.
The business agents follow the same principle. Pennylane sync pulls invoices, transactions and balances to maintain a cash position, and stays read-only. Estimates tracks quotes and prepares proposals, but nothing is sent or published without explicit approval. Client context keeper rebuilds living client files from quotes, invoices, recent conversations, PRs and incidents, preserving the manual notes. None of this replaces human judgement. It gets me to a decision with the right context already in hand.
Project Focus does not look for the most appealing project. It pushes whatever has to move forward: nearly finished work, recent client signals, explicit blockers.
Attention as a product constraint
The biggest trap in automation is not outright failure. It is the system that works well enough to produce noise. A useless alert becomes an interruption, a repeated interruption becomes a reflex to ignore, and an ignored system ends up worse than no system at all, because it creates the impression that something is being watched when nobody is listening any more.
So Hermes separates the channels. The dashboard holds passive information, Things holds the actions I actually have to take, Telegram covers emergencies and short arbitrations, and the state files keep history for the next runs. An invoice expected in three days is not necessarily an action. A client to follow up on is. An already merged PR must not spawn a fresh todo because an agent re-read an old JSON file with the administrative enthusiasm of a tax form on amphetamines.
There is deduplication, there are anti-spam windows, there are “one subject, one todo” rules, and there are cases where Hermes explicitly decides to push nothing at me. Less spectacular than an avalanche of notifications, and it is what makes the system usable. Attention is a limited resource, and an assistant that wastes it is working against me, however statistically well-meaning its intentions.
Refusals are a feature
The most important part of Hermes is not the list of what it can do, it is the list of what it refuses. No automatic client email. No quote published without explicit approval. No code change beyond a trivial scope. No architecture decision. No Things todo for its own internal plumbing. No “I think that…” when the system could ask a clear question with three actionable options.
This is where the product mindset really counts. When you discover agents, the natural reflex is to add capabilities: answer clients, publish quotes, merge PRs, decide the next piece of work, reorganize the schedule. Some of those may be reasonable one day. But the right question is not “is it technically possible?”. The right question is “which mistake becomes possible if I allow it?”.
An agent that can do everything is not necessarily powerful. It is often an accident surface with good UX. Hermes is useful because it knows to stop where my judgement is still needed: arbitrating a client need, accepting a commercial risk, approving a proposal, deciding that a request contradicts the reason a piece of software exists. Those decisions are not annoying details waiting to be automated, they are exactly where the value sits.
Memory you can inspect
Hermes memory is not magic. It is files. JSON, JSONL, Markdown. Basic, versionable, inspectable, repairable. Each agent reads what it needs and writes into precise areas: dev queue, PR memory, failed tasks, project signals, answers to questions, client files.
I have nothing against semantic search, and Hermes uses it where it adds something. But the operational memory of a working system has to stay readable. An agent that justifies a decision with “I found that in my memory”, with no way to inspect the source, is not intelligent. It is hard to audit, which is a very modern way of being dangerous.
The dashboard plays the same role. It is not there to look nice, even if I eventually gave it a decent shape because I am weak in the face of a clean interface. Its real job is letting me check that an agent ran, what it saw, what it did, and sometimes what it refused to do. Dates are absolute rather than relative, because “two hours ago” turns false fast in a cached page or a screenshot. Timestamps come from the system, not from the model’s imagination. An agent that writes a future date is not visionary, just broken.
What this really shows
Hermes is a side project, but it is not a technical whim. It is a way of treating my own business as an internal product. The need was never to use AI. The need was to reduce forgotten things, prioritize work that actually matters, keep a usable financial picture, avoid repetitive admin, make client context available at the right moment, and preserve human decisions where they carry value.
That logic looks a lot like the one I apply at client sites. Before building anything, you have to understand the real work: who does what, with which information, in what order, with which risks, and which decisions must absolutely not be automated. Only then do you pick the tool. Sometimes that means a full custom application. Sometimes it means automating three painful steps. Sometimes it mostly means asking Excel to stop playing ERP, CRM, scheduler, reporting layer and collective conscience of the company all at once. Excel is very good, but it too deserves a dignified retirement.
I am not going to publish Hermes as it stands. It contains my professional life, my clients, my finances, my emails and enough internal paths to make any normally constituted CISO cough. The principles, though, are reusable. Start from a recurring friction, separate information from action from decision, give every automation a narrow scope, keep state inspectable, put the human in the loop in the right places, and use an LLM for ambiguity rather than as a replacement for a reliable script.
If any of this sounds familiar
Hermes is personal, but the problem is very common: scattered information, manual processes, forgotten follow-ups, decisions made without the full picture, SaaS tools that are too generic, and an Excel file still standing out of sheer local patriotism. In those situations the right question is not “how do we put AI in the company?”. It is more like: which tasks keep coming back, which decisions genuinely need a human, which information arrives too late, and which existing tools could be connected instead of replaced.
That is the kind of work I do at SXN Labs, understanding the business, finding the real friction, building the software or the automations that cover the need, then leaving behind a system that is simple to use, observable and maintainable. Not a magic demo. A tool that helps, with enough limits to stay good company.