pinksheep
Guides/Configuration

How to Set Up AI Agent Notifications

Quick answer

The safe setup today is simple: use the in-app notifications view as the main place to review alerts, and rely on the current alert emails where they already exist. Avoid promising a bigger routing system than the product clearly proves.

The safe setup today is simple: use the in-app notifications view as the main place to review alerts, and rely on the current alert emails where they already exist. Avoid promising a bigger routing system than the product clearly proves.

7 min readUpdated 20 March 2026

Why notifications matter

Notifications matter because AI agents can pause for approval, fail on a run, hit spend boundaries, or finish important work while no one is watching the screen.

The safest way to describe the product today is to stay close to the surfaces that actually exist: the in-app notifications view and the alert emails that are already wired.

Current notification surfaces

1. Use the in-app notifications view as your main surface

The app has an in-app notifications view for recent alerts. It is the cleanest place to review what needs attention and open the next action from inside the product.

2. Treat alert emails as the companion channel

Current product truth supports alert emails for important event types. Describe email as a companion channel, not as the whole system and not as proof of a broader routing layer.

3. Keep the supported event types explicit

The in-app notifications view already supports concrete event types like approval-needed, run-complete, agent-failed, credit-low, spend-cap, paused-run, and related account or billing notices. Use that exact boundary in page copy.

4. Keep the public claim boundary narrow

This page should not imply configurable digests, department routing, or a broader notification settings system unless that exact surface is separately verified. The safer story is the simple one: in-app review plus current alert emails.

5. Do not overpromise extra channels

Avoid claiming Slack, Teams, digest routing, escalation trees, or department-specific channel mapping unless those have been separately verified. This page should stay inside the current in-app and email boundary.

Best practices

  • Keep approval requests on. Approval-needed alerts are part of the core safe-by-default flow.
  • Keep failures and billing alerts visible.They are the highest-signal categories for operational risk.
  • Use run completions selectively. They are useful for important workflows, but they can become noisy if every routine run is treated as urgent.
  • Treat the in-app notifications view as the source of truth. Use it to review, open, and clear current alerts.
  • Keep channel claims precise. Only promise what the app currently proves: in-app notifications and current alert emails.

Frequently asked questions

What notification surfaces are safe to describe today?

Stay with the surfaces the product clearly proves today: the in-app notifications view for recent events and the current alert emails for important notices.

Where do notifications appear?

The clearest proven surface is the in-app notifications view. Certain events also trigger alert emails, so treat the app as the main review surface and email as the companion channel.

Which events are safe to mention publicly?

Stay with the events the product clearly proves today: approval-needed alerts, run failures, run completions, low-credit or billing-style alerts, and related in-app notices like spend-cap or paused-run states.

Do I need to configure a complex routing system?

No. The safe public story today is intentionally narrow. Use the in-app notifications view as the main place to review alerts and rely on the current alert emails where they already exist.

Can I promise Slack, Teams, or digest routing?

Not as a safe public claim today. Keep the page inside the in-app notifications view and the current alert emails that are already wired.