Why I built it 🔗

I wanted a better way to process the newsletters I receive around cloud security, IAM, platform engineering, AI, and market signals. A lot of useful information ends up buried in email so my goal was to build a system that could ingest those emails, summarize them, keep track of useful signals, and produce a daily digest that actually reflects what I care about.

I also wanted the system to become more useful over time. If I tell it that a topic is not relevant, or that I prefer a different digest format, it should be able to remember that preference and adjust future outputs.

Why Hermes Agent 🔗

I used Hermes Agent from NousResearch as the agent layer, in a similar category to tools such as OpenClaw.

I chose it because I wanted something more capable than a simple summarization script: persistent context, tool execution and an OpenAI-compatible interface.

In my setup, Hermes can query a Postgres database directly, reason over past newsletters, select what matters, write a digest, and react to feedback. That flexibility is useful because I do not need to predefine every analytical question as an API endpoint.

The trade-off is that a capable agent needs boundaries. The more useful the agent becomes, the more careful I need to be about what it can access directly.

Architecture 🔗

The first diagram shows the main trust boundaries in the system: Gmail and the Newsletter Engine handle the sensitive integrations, LiteLLM acts as the LLM control point, and Hermes Agent runs in the backend network with limited access to Postgres.

At the core of the design, the system is split into two parts.

The Newsletter Engine is the deterministic part. It polls a dedicated Gmail inbox, applies sender whitelisting, ingests newsletters, cleans the content, enriches it, schedules digests, and sends emails.

Hermes Agent is the reasoning part. It reads the data it is allowed to access, selects relevant content, writes the digest, answers messages, and requests preference changes through controlled actions.

This split is the main design decision. Sensitive integrations stay in the deterministic service. The agent gets enough access to be useful, but not enough to own the whole system.

The second diagram shows the daily digest workflow end to end, from Gmail ingestion to content cleaning, enrichment, storage, agent-based selection, digest generation, and final email delivery.

Gmail as the interface 🔗

I created a dedicated Gmail account for the tool. Nothing is exposed publicly. There is no public web app and no public webhook receiving arbitrary traffic.

The Newsletter Engine polls the mailbox and only processes emails from approved senders. That means either my personal address or newsletter sources I explicitly whitelisted.

There are two workflows.

If I forward a newsletter to the dedicated address, the system treats it as a news source and ingests it.

If I write directly to the address, the system treats it as a message from me. Hermes can then answer, or request a controlled preference change. For example, I can tell it that a topic is no longer relevant, or that future digests should be formatted as email instead of Markdown.

Security model 🔗

I treat newsletter content as untrusted input. A newsletter can contain instructions, misleading text, or prompt-injection attempts. The system is designed so that a bad agent decision should have limited impact.

Hermes does not have direct access to Gmail. It does not hold OAuth tokens. It cannot send emails directly. It does not have direct internet access. It can query Postgres, but only through a read-only role.

LLM calls go through LiteLLM, using service-specific keys. That gives me a central control point for providers, models, credentials, and cost boundaries.

The Newsletter Engine remains responsible for sensitive actions: processing allowed senders, sending email, and applying controlled preference updates.

Important trade-offs 🔗

I allowed Hermes to query Postgres directly because it makes analytical questions much more flexible. It can ask questions over the dataset without me building a new endpoint each time.

The cost is that the database schema becomes part of the agent interface. That is acceptable here because the role is read-only and the dataset is narrow. It would be a bad choice if the same database contained unrelated sensitive data or secrets.

I also used email as the interaction layer because it keeps the system simple. I can forward newsletters, send feedback, and receive replies without building a UI.

The cost is that email becomes an input channel, so sender whitelisting and workflow classification matter. A forwarded newsletter and a direct instruction from me arrive in the same mailbox, but they do not have the same meaning.

Takeaways 🔗

Blast Radius 🔗

Agentic tools such as Hermes Agent or OpenClaw are powerful, but they are not just another library to plug into an application, they change the security model.

Once an agent can use tools, query data, remember preferences, and trigger actions, the important question is no longer only “does the prompt work?”. The important question becomes “what happens if the agent makes a bad decision?”.

That is why blast radius became the most important design principle in this project.

For agentic systems, the real architecture work is deciding how far a bad decision can go. That makes the system less autonomous, but more controlled.

Prompts as configuration 🔗

Prompts should be treated more like configuration than casual text. The webhook prompts, digest instructions, user profile, and learned preferences define real system behavior. They influence what the agent can decide, how it interprets inputs, and when it should call controlled actions.

For that reason, prompts deserve the same kind of discipline as other production configuration: clear ownership, versioning, review, and careful changes.

Cost 🔗

The best models are expensive, and not every step needs the strongest reasoning model. In this system, the deterministic engine handles ingestion, parsing, scheduling, state transitions, and email delivery. A cheaper model can handle basic enrichment. The stronger model is reserved for the parts where reasoning actually matters: selecting relevant content, writing the digest, and answering analytical questions.

A useful AI system is not necessarily one where the agent does everything. It is one where deterministic code handles the predictable work, and the agent is used where flexibility and reasoning justify the cost, latency, and risk.