3 min read

What I Let a Hermes Agent Remember in Telegram Support

What I Let a Hermes Agent Remember in Telegram Support

The first bad draft

Last month I watched a Hermes agent draft a support reply in Telegram and include a payment card number from a customer message sent three weeks earlier. Nobody had asked for it. The agent was trying to be helpful. That was the problem.

The agent was running for a small support team. It was deployed with Docker Compose, configured in the AgentForge web UI, and connected to a Telegram support chat. Its job was simple: draft replies and follow-ups.

The setup

I gave it broad memory at first. I thought more context would make better answers. Every message, ticket note, and customer detail went into the same store. The agent could recall anything, so I assumed it would choose the right thing.

It did not. Within a week, memory became a junk drawer. A closed refund ticket still looked open. An old shipping address was treated as current. A private aside from a customer showed up in a sales follow-up draft. The card number was the moment I stopped the rollout.

The problem was memory quality

The issue was not the model. The issue was what I let it remember. The agent had no distinction between a fact that changes future work and a detail that should never leave the original message.

That caused two kinds of pain. Support drafts referenced stale status, so the team had to correct them. And the agent had access to data it did not need, which created a privacy risk in a Telegram chat that several people could read.

Memory is not a transcript. It is a decision input.

Why it matters

Bad memory breaks automation quietly. A support agent that remembers an old refund status will promise the wrong next step. A sales agent that remembers an unconfirmed personal detail will sound intrusive. A single leaked card number or credential can end the project.

The cost of doing nothing is not just a bad reply. It is more manual review, less trust in the agent, and a data incident waiting for the right message.

What I changed

I stopped storing raw history as long-term memory. I split memory into three buckets and wrote the rule into the agent instructions in the AgentForge web UI.

  • ✅ Working context: current ticket, open question, owner, deadline. It expires when the task closes.
  • ✅ Approved long-term facts: product plan, confirmed customer preference, open commitment with source and date.
  • 🚫 Forbidden data: card numbers, credentials, API keys, raw private chats, health details, and guesses.

I also used the Docker Compose setup to keep the persistent volume but add a retention job. Old conversations are purged after 30 days. Before anything is indexed, obvious secrets are redacted. The agent still has the current task in context, but it does not keep every message forever.

In Telegram, I made memory visible. The agent proposes a short memory line in its draft: what it wants to remember and why. The operator can approve, edit, or remove it. That one step caught more bad facts than any prompt tweak.

The result

After two weeks, the agent stopped dragging old payment data into drafts. Support follow-ups used the current ticket state. Sales follow-ups remembered only confirmed preferences. The memory store stopped growing with every message, so the context sent to the model stayed smaller and easier to inspect.

The team reviewed fewer stale-fact corrections. More importantly, we could explain what the agent knew, where it came from, and when it would expire. That is the line I use now: if I cannot justify a memory as a future decision input, it does not belong in the agent.

AgentForge

AI agents for real work. If you want to see how this works in practice, visit our product site and blog.

Share
Serhii

Serhii