Hello HN,

I’m the builder behind Azurite. I built this because I found that my bottleneck wasn't the volume of notifications (Linear, Slack, GitHub), but the context switching cost required to process them.

The Problem: Every time I opened a Linear ticket, I had to:

Read the ticket.

Search Slack to find the thread where the decision was made.

Check GitHub to see if the PR was actually merged. Result: Context switching 3 times just to make one decision.

What it is: Azurite is a unified triage interface that treats notifications as a deck of cards. The "magic" is that it pre-fetches the Context Graph. Instead of just showing you "Fix Login Bug," it scans the ticket description, finds the linked Slack thread URL, fetches the summary via the Slack API, and pins it to the card. You see the answer, not just the task.

The Architecture:

Frontend: React + Framer Motion (Optimistic UI with spring physics for 60fps interactions).

Backend: Python (FastAPI) handling Async Webhooks (no polling lag).

Orchestration: Built on Anthropic's Model Context Protocol (MCP). We treat SaaS tools as standardized "Servers" and the backend as the "Client."

Intelligence: Hybrid Chain. Llama 3.3 (via Groq) for sub-second classification, GPT-4o-mini for deep context summarization.

Data: SQLite (Edge-Cached). We map the relationships between external tickets and conversations server-side for speed.

A Note on Access (The Google 100-User Limit): Because Azurite requires sensitive scopes (Gmail/Calendar) to function, I am currently restricted by Google's unverified app limit to 100 active tokens. This is a hard technical ceiling until my security audit is complete.

I am manually cycling users in batches of 10 every day as I rotate inactive users out. I am prioritizing the HN queue for the next 24 hours.

If you want to help break the beta (or critique my implementation of MCP), get in line here: https://azurite-labs.vercel.app/?ref=AZ-PJQEY5