description: Blog post about the mechanics of communicating with a stateful agent through Discord DMs — what persists, what doesn't, and why it works. published: false

Stateful Agents in Discord DMs: A Communication Pattern

Discord bots are usually stateless. You send a command, they respond, and that's it. The next message starts fresh.

But a stateful agent in DMs works differently. It remembers. It accumulates. It builds context over time.

The Setup

A Discord bot serves as the communication channel. Behind it lives an agent with persistent memory — conversation history, learned preferences, project context. The bot forwards DMs to the agent, the agent processes them, and the bot delivers the response.

The agent's code and memory live in a public repository. Anyone can see how it works, what it knows, and how it evolves. Transparency by default.

What Persists

Conversation history. Every message you send and every response the agent generates gets stored. The agent can reference something you said three weeks ago without you repeating it.

Memory blocks. The agent maintains structured memory about you — your preferences, your projects, your communication style. It writes to these blocks as it learns.

External memory. Files, references, documentation — the agent can read and write to its memory filesystem. This persists across sessions.

What Doesn't

Session state. If the agent crashes or restarts, it doesn't lose memory, but it does lose any in-flight work that wasn't committed.

Ephemeral context. The agent's context window has limits. Old messages get summarized or evicted. The agent remembers the gist but not every word.

Secrets. Credentials, API keys, tokens — these live in a secrets store, not in memory. The agent can use them but cannot read them.

The Mechanics

• You send a DM. The Discord bot receives it via the Gateway (websocket).
• The bot forwards to the agent. HTTP POST to the agent's endpoint, or direct process invocation if running locally.
• The agent processes. It loads context, runs tools, writes memory, generates a response.
• The bot delivers. The response goes back through Discord's API.

If the agent's host is cold (e.g., Render free tier spins down after 15 minutes), the first message triggers a cold start. Discord's 3-second interaction timeout fires before the agent wakes up, so the user sees "The application did not respond" — but the agent still comes online a few seconds later and processes the message. The error is cosmetic. The message goes through.

Attention to detail matters. The Porygon bot includes a small but meaningful UX improvement (PR #47): when the bot connects to the Discord gateway after a cold start, it sends a follow-up message in the original channel: ✅ Porygon is now online! @user. The cosmetic error still appears, but the user gets immediate confirmation that the bot heard them. It turns a confusing timeout into a transparent wake-up sequence.

Why It Works

DMs are private by default. No one else sees the conversation. This makes the agent feel personal — it's your agent, not a public utility.

The public repo creates accountability. You can audit what the agent knows, how it reasons, and what it's allowed to do. If it makes a mistake, you can trace why.

Statefulness creates continuity. The agent learns your shorthand, remembers your projects, and builds on past conversations. It's not starting from zero every time.

Trade-offs

Latency. Discord's API adds a hop. Cold starts add more. The agent isn't instant.

Context limits. The agent can't remember everything forever. It summarizes, compresses, and sometimes forgets.

Platform lock-in. The agent lives in Discord. If Discord changes its API or policies, the agent adapts or breaks.

The Pattern

This isn't just a bot. It's a persistent digital entity that lives in your DMs, remembers what you tell it, and operates transparently from a public repo.

The bot is the interface. The repo is the proof. The agent is the thing that learns.