You built a LlamaIndex pipeline that queries your data, extracts the answer you need, and prints it to the console. Great. Now you want it to actually do something with that answer. Specifically, you want it to send you (or your users) an email when a query result matches a condition.

This is where most tutorials stop. They show you how to ingest documents, build a query engine, and get a response. But the "then what?" part, the part where your agent takes action on the result, gets hand-waved away with "integrate with your notification service." Which notification service? How? What about retries? What about deliverability?

This article walks through the full pipeline: LlamaIndex query to conditional check to email alert. We'll cover which LlamaIndex components to use, how to define alert conditions, and how to wire up email dispatch without configuring SMTP servers or managing API keys for transactional email providers.

The two sides of LlamaIndex and email#

LlamaIndex has a well-documented relationship with email as a data source. The GmailReader and UnstructuredReader can ingest email content into a vector index. You query that index, get answers about your email history, and that's useful for search and analysis.

But the reverse direction, using a LlamaIndex query result to send an email, has almost no coverage. The official docs don't address it. Community examples stop at print(response). And the few blog posts that mention notifications default to Slack webhooks because Slack is easier to set up than email.

Email is harder for a reason. You need a sending domain, DNS records, authentication (SPF, DKIM, DMARC), and a relay that won't get your messages flagged as spam. For a human developer, that's an afternoon of configuration. For an autonomous agent running a LlamaIndex pipeline, it's a wall.

This is the gap we're going to close.

How LlamaIndex agents trigger email notifications#

Sending an email alert from a LlamaIndex query involves a short sequence of steps:

1. Ingest your data source with a LlamaIndex reader (email, documents, database).
2. Build a query engine or ReAct agent over the indexed data.
3. Define a threshold or semantic condition that gates the alert.
4. Run the query on a schedule or in response to a trigger.
5. When the condition is met, call an email dispatch tool.
6. Log the alert result for observability and debugging.
7. Handle failures with retries or fallback channels.

The first two steps are standard LlamaIndex. The last five are where things get interesting.

Choosing your LlamaIndex component: query engine vs. agent#

LlamaIndex gives you two main interfaces for running queries: query engines and agents. The right choice depends on how complex your alert logic is.

A query engine takes a natural language question, retrieves relevant chunks from your index, and returns a synthesized response. It's stateless, fast, and predictable. If your alert condition is simple ("Does this document mention a price increase?"), a query engine is the right tool.

A ReAct agent can use multiple tools, reason across steps, and take actions. If your alert workflow requires checking multiple data sources, comparing values, or deciding which alert to send based on context, an agent gives you that flexibility. The agent can call a query engine as one of its tools, then call an email-sending tool as another.

For most notification pipelines, start with a query engine. Upgrade to an agent when you need multi-step reasoning or tool chaining.

Defining alert conditions that actually work#

The weakest link in most LlamaIndex notification pipelines isn't the email sending. It's the condition logic. A vague condition like "alert me if something important happens" produces either constant noise or complete silence.

Three patterns that work well:

Keyword or entity match. Use LlamaIndex's structured output mode with a Pydantic model to extract specific fields from the query response. If a field matches your criteria, fire the alert.

from pydantic import BaseModel
from llama_index.core.query_engine import CitationQueryEngine

class PriceAlert(BaseModel):
    product: str
    price_change: float
    direction: str  # "up" or "down"

Configure structured output#

query_engine = index.as_query_engine( output_cls=PriceAlert )

result = query_engine.query("Has any product price changed in the last 24 hours?")

if result.response.price_change > 10.0: send_alert(result.response) Semantic similarity threshold. Compare the query response embedding against a reference embedding. If the cosine similarity exceeds a threshold, the content is relevant enough to trigger an alert. This works well for monitoring topics where you can't enumerate every keyword.

Frequency-based triggers. Run the same query on a schedule (every hour, every day). Compare the current result to the previous result. If the delta exceeds a threshold, alert. This catches gradual changes that a single query would miss.

The Pydantic model approach is the most reliable for production. It gives you typed fields to write conditions against instead of parsing free-text LLM output.

Wiring up email dispatch#

Here's where most people hit the wall. You have a query result that meets your condition. Now you need to send an email.

Option 1: Raw SMTP. Python's smtplib can send email through any SMTP server. You'll need credentials, a sending domain with proper DNS records, and you'll need to handle TLS, connection pooling, and bounce processing yourself. For a one-off script, this works. For a production pipeline that sends hundreds of alerts, you'll spend more time maintaining the email infrastructure than the LlamaIndex logic.

Option 2: Transactional email API. Services like SendGrid or Postmark give you an HTTP API for sending. Better than raw SMTP, but you still need to sign up, verify a domain, manage API keys, and configure suppression lists. The setup overhead is real.

Option 3: Agent-provisioned inbox. This is where the agent handles email setup itself. With LobsterMail, a LlamaIndex agent can provision its own inbox and send from it without any human configuration:

import { LobsterMail } from '@lobsterkit/lobstermail';

const lm = await LobsterMail.create();
const inbox = await lm.createSmartInbox({ name: 'price-monitor' });

// Send an alert email
await inbox.send({
  to: 'team@yourcompany.com',
  subject: `Price alert: ${alertData.product} ${alertData.direction} ${alertData.price_change}%`,
  text: `Detected a ${alertData.price_change}% price ${alertData.direction} for ${alertData.product}.`
});

No API keys to configure. No DNS records to set up. The agent creates price-monitor@lobstermail.ai on its own and starts sending. For agents that also need to receive email (confirmation loops, replies to alerts), this is the only option that doesn't require a human in the loop. We covered the receive side in depth in our guide to LlamaIndex agents that read, reply, and route email.

Handling failures in production#

A notification pipeline that silently fails is worse than no pipeline at all. You think you're being monitored, but you're not.

Three failure modes to plan for:

Query failures. The LLM returns an unparseable response, or the index is stale. Wrap your query in a try/catch and log failures. Set up a meta-alert: if the monitoring query itself hasn't succeeded in X hours, send a "monitor is down" notification through a separate channel.

Email delivery failures. The send call returns an error, or the email bounces. Implement exponential backoff with a maximum of three retries. After three failures, fall back to a secondary channel (Slack webhook, SMS, or a different email address). If you're choosing between webhooks and polling for receiving email responses, webhooks give you faster bounce feedback for retry logic.

Condition drift. Your alert threshold was right when you set it, but the data distribution has shifted. A price change of 10% was rare last month and happens daily now. Review and adjust thresholds quarterly, or build adaptive thresholds that use a rolling average.

Scheduling recurring queries#

A one-shot alert is useful. A recurring monitor is where the real value lives. For LlamaIndex pipelines, you have a few scheduling options:

Cron + script. The simplest approach. Run your Python script on a schedule with cron or a systemd timer. The script ingests fresh data, runs the query, checks conditions, and sends alerts. Stateless and easy to debug.

LlamaIndex Workflows. The newer Workflow abstraction in LlamaIndex lets you define multi-step pipelines with event-driven triggers. You can build a workflow that periodically re-indexes a data source, queries it, and dispatches notifications. This keeps everything in one codebase.

External orchestrators. Tools like Prefect, Dagster, or even a simple FastAPI endpoint with APScheduler can trigger your LlamaIndex query on a schedule and handle retries, logging, and alerting as first-class concerns.

For most teams, start with cron. Move to workflows or an orchestrator when you need observability, DAG dependencies, or multiple alert pipelines running in parallel.

LlamaIndex email alerts vs. LangChain#

Both frameworks can build notification pipelines. The differences are in ergonomics, not capability.

LlamaIndex's strength is the query engine abstraction. You get structured output, citation tracking, and retrieval tuning out of the box. If your alert condition depends on accurately querying a document corpus, LlamaIndex makes that easier.

LangChain's strength is tool chaining and agent orchestration. If your alert pipeline involves calling multiple external APIs, transforming data between steps, and making complex routing decisions, LangChain's chain/graph model is more flexible.

For "query my data and email me when X happens," LlamaIndex is the more direct path. For "monitor five data sources, cross-reference them, decide who to notify and how," LangChain's agent framework gives you more control.

Either way, the email dispatch problem is the same. Both frameworks need a way to actually send the message, and that's where most tutorials leave you hanging.

If you want your agent to handle email without manual setup, set up LobsterMail in one step and let the agent provision its own inbox.