Use Cases and Why Courier

Last updated: May 2026

AI customer-support agents that close the loop

A customer-support agent that can read tickets, look up account state, and answer a customer is only half the job. The other half is making sure the customer hears the resolution. A refund processed in the agent's loop needs an email receipt. An account change needs a confirmation. A reset password needs a delivery to the user's inbox or phone. Trusted Health uses Courier for workforce management notifications in healthcare staffing.

The pattern: agent resolves the ticket, agent calls send_message through the Courier MCP, the customer gets the notification. The agent's logs and Courier's message logs together give you a complete record of what happened on the support side and what reached the customer.

For agents that handle high volume, route low-priority confirmations through email and reserve SMS for urgent updates. The user's preference center settings carry through automatically.

Autonomous workflow agents

DevOps agents that triage alert notifications. Ops agents that handle scheduled runs. Internal-tools agents that approve access requests. These are agents acting on infrastructure, with humans in the loop for review or escalation. CircleCI uses Courier for developer notifications across its platform.

The send patterns here are different from customer-facing:

• Page on-call. Agent triggers an escalation journey. Journey sends to the on-call engineer, waits 5 minutes, branches on whether the alert was acknowledged, escalates if not.
• Notify a Slack channel. Agent posts a structured Slack message with block-kit actions. A teammate clicks "approve" or "decline" and the agent reads the response.
• Daily digest. Agent compiles its overnight activity and sends a single morning email to the owning team. LaunchDarkly uses similar workflow notifications to coordinate feature release approvals.

Workflow agents benefit most from journeys (multi-step flows with delays and branches) rather than single sends. The journey holds the state machine so the agent doesn't have to. See Chapter 4 for the journey node model and Chapter 5 for the agent-side patterns that drive them.

In-product AI features

Features built on top of Claude or another LLM often need to message users when something finishes. A long-running export. A document analysis. A scheduled summary. The agent doing the work calls Courier to deliver the result through the right channel for the moment. Twilio unified notifications across its developer platform on the same primitives.

The notification scaffolding (channel routing, preference compliance, delivery logging) is the same as any other product message. What's different is the trigger: instead of an event in your application code, it's the agent finishing a task.

Build vs. buy for AI-native messaging

Let's talk honestly about what it takes to build this from scratch, because most teams underestimate the surface area until they're months in. You need to pick providers for every channel (SendGrid or Postmark for email, Twilio for SMS, FCM for push, Slack for chat) and write per-provider client code and credential storage for each. You need a template system that renders the same message to multiple channels, preference storage per user, channel routing and fallback logic, and a webhook listener for delivery events and bounces. You need a journey engine if you want multi-step flows (or you skip it and use cron jobs, which break in subtle ways). And to make any of this AI-accessible, you need to expose the whole thing as MCP tools so your agent can call it.

That's a 2-engineer team for 6-12 weeks to ship a basic version, then ongoing maintenance for every new provider and every preference rule. The "expose as MCP tools" step alone is a multi-week project if you've never built an MCP server. Best Ways to Build Notification Infrastructure in 2026 walks through this in more detail.

"There are very few products we're using that I'm so excited about... The problem is solved."

Pierre-Camille Hamana, founder, Hospitable.com — after replacing an in-house notification system (codenamed Churchill) that had taken three engineers full-time for three months plus a CTO managing the project

Buying means the providers, templates, preferences, routing, journeys, and MCP tool surface are already there. You connect the providers you want from the Courier dashboard, point your agent at mcp.courier.com with your API key in the api_key header, and skip the build entirely. The time saved is engineering time you'd otherwise spend on plumbing instead of your product's actual differentiator.

The case for building is real for a small number of products: extremely high volume where margins matter, regulated industries with custom audit requirements, or messaging that's so core to the product that it's part of the differentiation. For everyone else, buy.

Where Courier fits

For a broader market scan of the category, see 5 Best Platforms for Product Messages in 2026.

Courier sits between pure notification infrastructure (developer-focused tools like Knock and Novu) and customer engagement platforms (Braze, Klaviyo, Intercom). Courier's positioning is infrastructure-grade reliability with tools non-technical people can actually use, plus a developer-first surface area (CLI, MCP server, typed SDKs, clean docs) that the AI-native shifts in this guide depend on.

A few things Courier specifically brings to AI use cases:

• MCP server at mcp.courier.com that exposes 109 typed tools, so an AI agent can read, write, and modify the messaging system, not just send to it.
• Bring Your Own Provider (BYOP). Courier orchestrates on top of your existing providers (Twilio, Resend, FCM, APNs, Slack, MS Teams). Swap or add providers without code changes.
• Cross-channel templates in one place. Transactional, product, and marketing notifications managed in one platform across email, push, SMS, in-app inbox, Slack and MS Teams.
• Built-in safeguards and governance. Frequency capping, preference management, compliance guardrails, automatic failover when a provider goes down.
• Drop-in UI components. Inbox, Preferences, Toasts. Production-ready, saves months of build time.

For where Courier honestly isn't the best fit: if you genuinely only ever need one channel, direct integration with that channel's provider may be simpler than running an orchestration layer.

Getting started

The fastest path: create a free Courier account at courier.com, connect Gmail as your first provider through the Courier dashboard (the dashboard walks you through Gmail's OAuth flow in your browser, no API key required), install the Courier MCP server in your AI tool with the one-line command from Chapter 2 (pass your Courier API key as an api_key header), and ask your agent to build and send a test message.

You'll have a working AI-native messaging setup in under 15 minutes. From there, add the providers you actually want, generate the templates your product needs, install the Courier skills bundle so the agent has Courier-specific guidance for common tasks, and let the agent handle the rest. The Notification Platform Developers Choose covers what teams typically build first.

For deeper reference, see the Courier docs, the AI onboarding guide, the agent quickstart, the Sending overview, and the Journeys API reference. Agents can pull a machine-readable index of the docs from courier.com/docs/llms.txt on their own when they need to discover capabilities mid-task.

FAQs

How fast is integration in a real codebase?

For a new product without existing messaging code, an agent-driven install takes about an hour to go from zero to a sent message: account, MCP install, provider connection in the dashboard, first template, first send. For an existing codebase with current providers and templates, Courier can sit alongside the existing system while you migrate flows piece by piece. Most teams report 1-2 weeks of incremental adoption rather than a single migration.

What does the free tier cover for AI agents?

A free tier with monthly send volume that's enough to run an AI agent in development and through small-scale production. All channels and features are included; the constraint is volume. If you cross the limit, you move to a paid plan that scales with volume. See pricing for current numbers, or talk to our solutions team if your usage is harder to estimate.

Where does Courier fit in the broader notification platform category?

Courier sits between developer-focused notification infrastructure (Knock, Novu) and customer engagement platforms (Braze, Klaviyo, Intercom). Distinguishing factors: BYOP (Courier orchestrates on top of providers you already use rather than being a provider itself), an MCP server that exposes 109 typed tools for AI agents, and a single platform that covers transactional, product, and marketing notifications across every major channel. For a head-to-head walkthrough of the category, see 5 Best Platforms for Product Messages in 2026.

Can I migrate existing notification logic into Courier incrementally?

Yes. Most teams start with one channel or one notification type, point that flow at Courier, and leave the rest on the existing system. Courier's template format accepts Elemental, HTML, and plain text, so you can move existing templates over without rewriting them.

Ready to put this into production? See pricing or talk to our solutions team.