From Stock Alerts to a Conversational Research Agent

What the stock service does

Each portfolio is represented by a YAML configuration. It can include the stocks being monitored, approximate allocation and cost basis, the reason for holding or watching each position, and the thresholds or rules that matter to me.

For every ticker, the service can evaluate information such as:

• Current price and daily movement

• Gain or loss relative to cost basis

• 50-day and 200-day moving averages

• Relative Strength Index (RSI)

• Position concentration

• Stock-specific price, RSI, gain/loss, and score thresholds

The rule engine then produces review signals such as BUY REVIEW, HOLD / WATCH, SELL REVIEW, or URGENT REVIEW.

The wording is deliberate. These are prompts to review a position, not automated trading instructions. The service does not connect to a brokerage and cannot place a trade.

The project supports multiple configuration profiles, allowing separate portfolios or investment accounts to keep their own holdings, strategies, thresholds, and rules. The application reloads those configurations for each API request, so a threshold can be updated without rebuilding the image.

What Hermes added

Hermes is the agent and orchestration layer in this setup. I created a dedicated stocks skill within my personal Hermes profile and gave it access to the stock service through its API.

That allows me to use Discord as the interface. I can ask a natural question such as:

How is Snowflake doing?

Hermes can retrieve the configured position context and the latest analysis from the stock service, then research material developments and explain what may deserve attention. It does not invent a new holding, cost basis, allocation, or signal; the backend remains authoritative for those values.

The same separation applies to scheduled work. Hermes can orchestrate portfolio reviews and add research when reasoning is useful. For frequent threshold monitoring, however, no language model is needed at all.

Why I did not let the language model decide

One of the easiest ways to build an “AI stock agent” would have been to send market data to a model and ask whether a stock looked like a buy or sell.

I intentionally chose a different approach.

The calculations and signal decisions are deterministic. The same data and rules should produce the same result. Holdings, cost basis, allocation, thresholds, technical indicators, and alert state remain authoritative in the stock service.

AI can still add value, but in a role that suits it better: explaining the output, researching relevant developments, and turning structured results into a useful conversation.

This also makes the system easier to inspect. If a signal changes, I can trace it back to a rule or a data point instead of wondering how a model interpreted an open-ended prompt.

The ten-minute monitoring flow

The production monitor runs through Hermes every ten minutes in script-only, or “no-agent,” mode.

On each run:

1. Hermes calls the stock service with AI summaries and direct backend Discord delivery disabled.

2. The stock service fetches current data, evaluates the configured rules, and returns any sendable alert events.

3. If nothing crossed a threshold, the job remains silent.

4. If an event is waiting, the Hermes helper sends the alert through the Hermes Discord bot.

5. Only after Discord returns a message ID does the helper acknowledge that exact event with the stock service.

This keeps a repetitive, deterministic task out of the agent loop. It uses no model call when all the system needs to know is whether a configured boundary was crossed.

It also makes delivery more reliable. Detecting an event and delivering it are separate operations. If Discord delivery fails, the event remains pending and can be retried on the next run.

Why threshold crossings needed persistent state

A simple condition such as “price is above $X” sounds easy until it runs every ten minutes. Without state, the service could send the same message repeatedly for as long as the price remained above the threshold.

The stock service therefore distinguishes a condition from a transition.

It records which side of a price boundary was last observed and creates an event only when the price crosses from one side to the other. Each crossing has a generation-specific event ID. Hermes acknowledges that exact event only after successful delivery.

This detail matters because a delayed acknowledgement should never clear a newer transition. Persisted state also means a pending alert survives container recreation instead of disappearing with the process that detected it.

For other alert types, such as RSI or gain/loss thresholds, the service can apply cooldown behavior to reduce repeated notifications.

Why the integration is more useful than either component alone

The stock service is good at repeatable calculations, stored state, and enforcing rules. Hermes is good at natural-language interaction, orchestration, research, and presenting information in context.

Combining them lets each component do the work it is best suited for:

Responsibility Authoritative component

Holdings, cost basis, allocation, and strategy Stock Alert Agent

Market data, indicators, scoring, and signals Stock Alert Agent

Threshold and crossing state Stock Alert Agent

Scheduled execution Hermes

Discord interaction and delivery Hermes

Additional research and plain-language explanation Hermes

Investment decisions and trade execution Me

That final row is the most important one.

What I learned

The most useful lesson from this project was that adding an agent does not mean moving every responsibility into the agent.

A stronger architecture emerged when I treated Hermes as an orchestration and reasoning layer around a small, purpose-built service. The service remains testable and deterministic. Hermes makes it accessible and capable of richer workflows.

I also learned that reliable notifications require more than a scheduler and a webhook. A real alert workflow needs persistent state, retry behavior, and delivery acknowledgement. Otherwise, the system can lose an event, repeat it indefinitely, or mark it handled before anyone actually received it.