For agentsMarkdownJSON
Build journey02 Aug 2026~8 min read

Three doors into
one local agent.

I wanted continuity without giving up boundaries: terminal, Telegram, and WhatsApp drawing from one deliberately bounded memory layer.

Working experiment Personal hardware Privacy-first
Public-safe architecture

Several surfaces.
One memory contract.

This schematic preserves the route and the ownership boundaries while omitting operational coordinates.

Public-safe architecture diagram showing Terminal, Telegram, and WhatsApp flowing into the Hermes runtime, which connects through bounded recall and capture to GBrain and a local knowledge store.
Generated architecture illustration · based on a working personal experiment · operational details removed · August 2026 · Open full size

I wanted to know whether a personal agent could feel continuous without forcing me into one interface.

Sometimes I am already in the terminal. Sometimes I am away from my desk and want to send a message. Sometimes I need the same working session I left behind, not a fresh chat that has forgotten the trail.

That led to a simple question: can I give one local agent several front doors, while keeping the context and the sensitive parts on hardware I control?

Three front doors

My current Hermes experiment has three active conversation surfaces.

  1. 01
    Terminal. Hermes runs on my personal Mac. Ghostty is the terminal surface, Herdr keeps the working session available, and Tailscale gives me a private route back when I am away from the machine.
  2. 02
    Telegram. One messaging session gives me a lightweight way to ask, check, or trigger work without opening a laptop.
  3. 03
    WhatsApp. A dedicated number gives me another familiar channel into the same agent harness.

These are separate conversations, not one magical chat window copied three times. The continuity comes from the layer behind them.

The memory layer

I connected Hermes to GBrain as a standalone memory provider. Before a response, Hermes can ask GBrain for relevant pages. After a completed turn, it can capture durable knowledge back into the brain. The agent also has explicit tools to search, read, traverse connected knowledge, and remember something intentionally.

The distinction matters. A chat transcript is a record of what was said. A second brain is an attempt to turn useful parts of those conversations into knowledge that can be found again.

That honesty is useful. “Second brain” is an attractive label, but the real questions are practical: What gets captured? What gets recalled? What is the source of truth? What happens when the memory service is unavailable?

In this build, conversation continues if GBrain cannot respond. Memory enriches the agent; it does not become a single point of failure.

The model is a route, not the architecture

I also had to decide what model should sit inside the Hermes loop. My working choice as of 2 August 2026 is:

Default

DeepSeek V4 Flash

The everyday text-and-tool loop: fast, agent-focused, and materially cheaper than Pro at current direct-API prices.

Multimodal + fallback

Gemini 3.6 Flash

Images, documents, audio, and the messages that need more than text.

Escalation

DeepSeek V4 Pro

Hard reasoning after the default route struggles—not a tax on every casual turn.

So the answer is not “pick one winner.” It is Flash by default, Gemini when the input is multimodal, Pro when the task proves it needs escalation.

This is why the harness matters more than a permanent model choice. Models will change. The channel boundaries, memory contract, permissions, fallbacks, and verification habits still have to work after a model swap.

The correction

My first architecture diagram tried to show almost everything: runtime boundaries, memory calls, host services, storage, ports, and operational controls. It was useful for me, but too close to an access map for a public post.

Keep private

Operational diagram

The artifact that helps me run and repair the system.

Share publicly

Conceptual diagram

The artifact that helps another builder understand the pattern.

The public diagram keeps the causality and removes the attack surface. Transparency does not require publishing every coordinate.

What changed in my thinking

I started this experiment thinking about access: terminal, Telegram, WhatsApp.

I now think the more interesting design problem is continuity with boundaries. The channels are replaceable. The memory layer needs a clear owner. The runtime needs to fail safely. Remote access needs to stay private. And a model should be routed by the job it is doing, not by whichever name is trending that week.

There is already a noticeable improvement in how quickly the agent can return to a topic I have discussed before. I am treating that as an observation, not a benchmark. The next step is to build a small evaluation set: repeated questions across separate sessions, recall precision, false-memory rate, response latency, and what happens after knowledge is corrected.

Where you can begin

Start smaller than this diagram. Pick one agent, two interfaces, and one memory question you can test repeatedly. Decide what is allowed to become durable before turning on automatic capture. Keep the memory service private. Then ask the same question from both interfaces and inspect the evidence behind the answer.

The useful milestone is not “my agent remembers everything.” It is: my agent can retrieve the right thing, show where it came from, and keep working when memory is unavailable.
Build receipt

What this build can prove

Status
Active personal experiment; not an employer deployment
Verified
Local source and architecture review · 02 Aug 2026
Public sources
Hermes · GBrain · DeepSeek · Gemini
Visual
Generated architecture illustration · public-safe abstraction · visible frame reviewed
Kept private
Operational coordinates, credentials, private conversations, and the original diagram