---
title: "Three doors into one local agent"
status: published
created: "2026-08-02"
capture_date: "2026-08-02"
canonical_url: "https://tanveerriaz.me/blog/hermes-gbrain"
canonical_source: true
format: text/markdown
destinations:
  - website
privacy_review: approved-public-version
publication_approved: true
---

# Three doors into one local agent

> **Thesis:** The useful part of my agent setup is not that I can reach it from three places. It is that those places can draw from one deliberately bounded memory layer without turning my machine into a public service.

## The question

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. **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. **Telegram.** One messaging session gives me a lightweight way to ask, check, or trigger work without opening a laptop.
3. **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.

On my setup, the knowledge store is local. GBrain uses PGLite—embedded Postgres—to keep pages and graph relationships on the machine. The engine can support keyword, graph, and vector retrieval when an embedding provider is configured. In the architecture I verified for this article, embeddings are not yet configured, so the honest description today is **keyword and graph-aware recall**, with vector retrieval as a next experiment rather than a shipped claim.

That honesty is useful. “Second brain” is an attractive label, but the real questions are more 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 architecture, simplified

The public-safe version of the system is intentionally less detailed than my working diagram:

![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.](/assets/blog/hermes-gbrain-architecture.png)

*Generated architecture illustration · based on a working personal experiment · operational details removed · August 2026*

```text
Terminal / remote access ─┐
Telegram ─────────────────┼─→ Hermes runtime ─→ bounded recall + capture ─→ GBrain ─→ local knowledge store
WhatsApp ─────────────────┘
```

Hermes owns the conversation and tool loop. GBrain owns durable knowledge. A narrow memory-provider boundary connects them. The messaging channels do not connect directly to the database, and the knowledge service is not exposed as a public endpoint.

I have deliberately removed local paths, hostnames, ports, service identifiers, credential flow details, and exact operation allowlists from this public explanation. They are implementation details, not the lesson.

## 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:

- **DeepSeek V4 Flash for the default text-and-tool loop.** DeepSeek’s 31 July update specifically improved the model for agent work and added Responses API support. It is also materially cheaper than V4 Pro at the current direct-API prices.
- **Gemini 3.6 Flash for vision, documents, and fallback.** It is a stable multimodal model that accepts images, audio, video, and PDFs, with function calling and a one-million-token input window. That makes it a better fit when a Telegram or WhatsApp message arrives with more than text.
- **DeepSeek V4 Pro only as an escalation path.** I would use it for a hard reasoning task after the default model struggles, not pay the extra cost on every casual conversation. I want my own task-level evaluation to decide when Pro earns the route.

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 also 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.

The correction was to separate two artifacts:

- a private operational diagram that helps me run and repair the system;
- a public conceptual diagram that helps another builder understand the pattern.

The public diagram keeps the causality and removes the attack surface. That is now part of how I think about building in public: 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

| Item | Detail |
|---|---|
| Status | Active personal experiment; not an employer deployment |
| Tools and models | Hermes → agent runtime and channels; GBrain → recall and durable knowledge; Ghostty + Herdr → terminal continuity; Tailscale → private remote route; DeepSeek V4 Flash → default text/tool loop; Gemini 3.6 Flash → multimodal/fallback; DeepSeek V4 Pro → optional escalation |
| Public evidence | [Hermes Agent](https://github.com/NousResearch/hermes-agent); [GBrain](https://github.com/garrytan/gbrain); [DeepSeek models and pricing](https://api-docs.deepseek.com/quick_start/pricing/); [Gemini 3.6 Flash](https://ai.google.dev/gemini-api/docs/models/gemini-3.6-flash) |
| Verification | Local source and architecture review on 2 August 2026; responsive browser preview and animated route overlay passed at 1440px and 390px; reduced-motion behavior verified; no private runtime, logs, saved memory, or credentials inspected |
| Media provenance | Original architecture diagram supplied by Tanveer and excluded from the public asset set. New public-safe architecture illustration generated with OpenAI image generation from the conceptual layout; visible frame reviewed on 2 August 2026 |
| Kept private | Local paths, ports, hostnames, service identifiers, credential handling details, operation allowlists, database paths, and private conversations |

---

Curious mind. Builder mode! 🇸🇬