Hermes

Personal AI agent2026

An agent that connects calendar, tasks, email and knowledge — and lets me interact with them through conversation.

Bruno Rausch / Concept, development and maintenance

Hermes · editorial artwork for the personal project

01 / The problem

Information was scattered. I was the connection.

Calendar in one system, tasks in another, email and decisions elsewhere. To understand what needed my attention, I had to connect everything myself. I built Hermes to consult that context and act in the systems I already used, through a single Telegram conversation.

02 / Conversation instead of navigation

A request becomes an action. And the action leaves a record.

Asking about tomorrow checks the calendar. Requesting a focus block creates the event and confirms the result. The cycle includes context, tools, execution and a record — with follow-up on anything still open. Calendar queries, event creation and pending-item follow-up have confirmed execution in the package.

Request
Context
Tool
Action
Record
Follow-up

Desktop interface / swipe to inspect

Visual reconstruction · checking the calendar. Example content, no personal data; not a screenshot of the system.

Desktop interface / swipe to inspect

Visual reconstruction · a request becoming a recorded action. Example content, no personal data; not a screenshot of the system.

Desktop interface / swipe to inspect

Visual reconstruction · following up on pending items. Example content, no personal data; not a screenshot of the system.

03 / Knowledge

Hermes acts. Brain preserves.

The agent handles conversation and tools. Brain holds knowledge in versioned text notes, readable without the agent. Semantic search finds records even when a question uses different words. The index can be rebuilt; the notes remain. This separation lets the agent change without losing the knowledge base.

Notes in Brain: 6.081
Recorded versions: 1.318
Indexed documents: 614

Editorial representation · from a question to a sourced answer

Desktop interface / swipe to inspect

Visual reconstruction · retrieving a decision with a source reference. Example content, no personal data; not a screenshot of the system.

Counts from the audit package dated October 2, 2026. These describe the knowledge base, not productivity outcomes.

04 / Routines

The day starts before the first request.

Briefings, pending-item reviews, note organization and search updates run on a schedule. The model interprets and converses; scripts handle much of the repetitive work. Notifications are reserved for things that need attention, while results remain available as records.

Scheduled routines: 79
Active routines: 59
Script routines, without an LLM: 68 / 79

Editorial representation · a day of routines, based on the October 2, 2026 audit

Desktop interface / swipe to inspect

Visual reconstruction · an automatic briefing that continues as a conversation. Example content, no personal data; not a screenshot of the system.

Of the 79 routines, 12 were completed and 8 paused. Four active routines had failed on their latest run, including the daily backup. A schedule does not prove that each run succeeds.

05 / Architecture decisions

Every piece of information has a place.

Four responsibilities organize the system: channels receive requests; the agent decides and uses tools; knowledge and data provide context; integrations connect external systems. The installation runs on my own server while communicating with external services. It is a personal project, not a service offered to others.

Small, lasting rules

Short memory holds preferences and pointers. Details live in Brain, where they can be corrected and versioned.

State separate from knowledge

Pending items and execution history describe what is happening now. Notes preserve what needs to last.

Skills on demand

121 documented skills are loaded as needed, avoiding putting every procedure into each conversation.

Integrations with explicit status

Calendar, tasks and email have confirmed execution. The voice bridge is implemented, but no interaction was observed during the audit window.

06 / Control and limits

Errors need to stay visible.

Sensitive actions require an explicit request, and writes go through defined tools. Each execution records its state and result. The audit found four active routines with failures, including the daily backup. Profiles separate context, but do not provide a formal multi-user security boundary.

Editorial representation · audited state on October 2, 2026, including four failures

Desktop interface / swipe to inspect

Visual reconstruction · checking system state with a disclosed failure. Example content, no personal data; not a screenshot of the system.

The images protect personal content: they are compositions created for this case, not visual evidence of a real conversation. Facts and counts come from the supplied audit.

07 / The lesson

The hard part was designing the context.

Making the agent converse was only part of the work. The central task was deciding where each piece of information belongs, what can run automatically and what requires my intervention. The result is a layer I use to check the day, retrieve decisions and follow up on open items, while keeping the systems that already worked.

A personal project in use and ongoing development. This case is based on the audit package dated October 2, 2026; figures reflect that date. All images were created for this presentation. Conversations are reconstructions with example content. There are no time-saving metrics or public demo of the personal environment.

Back to the LabLab ↗