Where AI Notifications Fit: Use Cases and Build vs. Buy

Last updated: September 2026

Mechanics are one thing. Here's where agent-built messaging actually shows up in production, and whether you should be buying this layer at all.

Support agents that close the loop

A support agent that reads tickets, looks up account state, and answers the customer has done most of the job. The part that's left is making sure the resolution reaches the person.

A refund gets processed and needs a receipt. An account change needs a confirmation. A password gets reset and the link has to arrive. These are the steps where agent workflows quietly fail, because the agent has no way to send anything and the handoff back to your application code is where things get dropped.

The shape that works: the agent resolves the ticket, calls Courier to notify the customer, and both sides end up in a log. Your agent's trace shows what it decided. Courier's message log shows what reached the customer and when. Together that's a complete record, which matters more than usual when the actor was a model.

One practical note: route low-priority confirmations to email and keep SMS for things that are genuinely urgent. The user's preferences carry through automatically, so you're setting a default rather than overriding a person's choice.

Workflow agents that page a human

DevOps agents triaging alerts. Ops agents handling scheduled runs. Internal tools approving access requests. These act on infrastructure with a human in the loop for escalation.

The messaging patterns here are different from customer-facing work:

Page the on-call. The agent triggers an escalation journey. Send to the first responder, wait five minutes, check whether it was acknowledged, escalate if not. The journey holds the state, which means the agent doesn't have to stay alive for twenty minutes waiting to find out.

Ask a channel. Post a structured Slack message with actions. Someone approves or declines, and the agent reads the response.

Summarize overnight. The agent compiles what it did and sends one morning email to the team that owns it.

Workflow agents benefit from journeys more than from single sends, and for a specific reason: the journey is the state machine, so the agent can fire and forget. An agent that has to manage its own timers is an agent that loses its place when it restarts.

In-product AI features that finish and tell someone

Features built on a model often run long. A document analysis, a large export, a scheduled summary. The user has left the page.

The notification scaffolding here is the same as any product message: channel routing, preference compliance, delivery logging. What's different is the trigger. It isn't an event in your application code, it's an agent finishing a task, which means it happens at an unpredictable moment and needs to reach someone who isn't looking at your app.

In-app inbox plus email fallback covers most of these well. The result is waiting when they come back, and the email catches them if they don't.

What building this yourself actually involves

Worth being concrete, because the first 80% looks reasonable.

You need a provider integration per channel, each with its own client, credential storage, and error semantics. A template system that renders one message to several channels without you maintaining four copies. Preference storage, and enforcement of those preferences on every send. Routing with fallback, so a failed push becomes an email. A webhook listener for delivery events and bounces, and something that acts on them. A flow engine if you want multi-step sequences, or cron jobs and a state table if you don't, which break in ways that are hard to see.

Then, to make any of it usable by an agent, you need to expose all of it as a typed, documented API surface.

The last one is the part that's changed. Two years ago you could skip it. Now the internal tool that isn't agent-addressable is the one your team routes around.

We're not going to put an engineer-month figure on this, because the honest answer depends enormously on how many channels you need and how good your preference model has to be. What we'd say is that the maintenance is the real cost, not the build. Every new channel, every provider deprecation, every preference rule is ongoing work that isn't your product.

When building is the right call

There are real cases.

Extreme volume where margin matters. At sufficient scale, per-message economics start to dominate and owning the pipeline pays for itself.

Regulated environments with custom audit requirements. If you need specific retention, residency, or evidentiary guarantees that a vendor can't commit to, that's a legitimate reason.

When messaging is the product. If notification delivery is what you sell, outsourcing your differentiator is a bad trade.

Outside those, buying this layer means the providers, templates, preferences, routing, journeys, and the agent-accessible surface already exist, and the time you save goes into whatever your product actually is.

Ship AI-built notifications with Courier

If you've read this far, the setup is short:

1. Create a free account and grab your Test API key.
2. Install the skill: npx skills add trycourier/courier-skills
3. Connect the MCP server so your agent can act on your workspace.
4. Ask it to build something, then ask it to show you the delivery log.

Courier's built-in email provider works in Test with nothing connected, so you can go from zero to a verified send without touching provider credentials. Connect the providers you actually want once you know the shape of what you're building.

The interesting question stopped being whether an AI can write a good subject line. It's what an agent can actually change in your stack. When every object is reachable by API, the answer is most of it.

Ready to build? Talk to a solutions expert or get started for free.

Frequently asked questions

How long does integration actually take?

For a new product with no existing messaging code, an agent-driven setup gets you to a verified send in well under an hour: account, skill, MCP, first template, first send. For an existing codebase, the realistic path is incremental. Move one notification type over, leave everything else where it is, and expand once you trust it.

What does the free tier cover?

Enough monthly volume to build and run an agent in development and light production, with all channels and features available. The constraint is send volume rather than functionality. See pricing for current numbers.

Can I migrate existing notification logic incrementally?

Yes, and it's the approach we'd recommend. Courier sits in front of the providers you already use, so you can point one flow at it while everything else stays put. Most teams start with a single notification type and expand over a few weeks rather than cutting over at once.

Where does Courier sit against other platforms?

Between developer-focused notification infrastructure like Knock and Novu, and customer engagement suites like Braze and Klaviyo. The distinguishing pieces are that Courier orchestrates on top of providers you already have rather than being a provider itself, that every object in the UI is on the API, which is what makes agent-driven building possible, and that one platform covers transactional, product, and lifecycle messaging. For a broader look at the category, see the best platforms for product messages.