Avgi
Email triage that sorts your inbox by priority and language
I've been thinking about a problem many of us have: receiving hundreds of emails every week while most of them never get opened.
I'm building Avgi, an AI-powered email triage tool that reads emails in multiple European languages, sorts them by priority, and sends one simple daily digest. No auto-replies, no deleting emails, and read-only access to your inbox.
My goal is to help people spend less time checking email and more time on what actually matters.
Right now, I'm validating the idea before building the full product. If email overload is something you struggle with, I'd love your feedback and I'd be grateful if you joined the waitlist.
What feature would make a tool like this essential for you?
13 Comments
The feature I would look for first is an audit trail for the triage decision.
For email, “read-only” is a good boundary, but users still need to trust what was read, what was inferred, and why something was marked urgent. A simple reason like “German client + deadline language + unpaid invoice context” is more useful than a black-box priority score.
Especially for multilingual work, I’d also want controls for what never gets sent to the model: legal, medical, family, finance, or specific senders/domains. The product promise becomes stronger if users can see and adjust those boundaries instead of just trusting the AI layer.
This is exactly the right axis, thank you. Two reactions:
The "why" is already core, not a score. In the design, every email gets a one-line reason in plain language (e.g. "German client, explicit deadline, awaiting your reply") rather than an opaque urgency number. Surfacing that next to each email so you can see and correct the call is the plan.
The "what never goes to the model" controls are a great point and fit the whole promise. Sender and domain block-lists are already on the roadmap; adding category-level exclusions (legal, medical, finance, family) so those never leave your inbox for classification is a strong addition I'm taking from this. Being able to see and adjust those boundaries, instead of just trusting the AI layer, is exactly the trust I want to earn.
Quick question: would you want those exclusions mostly as broad categories, or as specific senders/domains?
Curious which would give you more confidence.
Both, but I would start with broad categories and then let people override with senders/domains.
Categories are the faster trust affordance: legal, medical, finance, family, HR, etc. A user can understand that before they have mapped every sender. Then sender/domain rules are the precision layer for real inboxes, because the sensitive boundary is often "this client" or "this accountant," not every message with a finance keyword.
The safest default might be: classify locally into broad exclusion buckets first, do not send excluded messages to the model at all, and let the user promote or demote senders/domains after seeing mistakes. That gives confidence without making setup feel like another inbox-management chore.
This is genuinely shaping how I'll build it, thank you. "Categories first as the trust affordance, sender/domain as the precision layer" is exactly right, and you nailed why: the real boundary is usually "this client" or "this accountant," not a finance keyword.
Honestly, you think about this the way my ideal user does. If you're open to it, I'd love to have you among the first to try Avgi when it opens, your eye on the trust boundaries would be invaluable.
No pressure either way, and thank you again.
Good timing — I'm building something similar. Slash it is an Email Decision OS, also focused on getting time back from email every morning.
The difference I've landed on: digest still asks you to read. Slash it removes reading entirely — AI judges priority, drafts the reply, you tap approve.
Curious how you're thinking about the "no auto-replies" constraint. That's where the real trust question lives.
Thanks, and good luck with Slash it. I made the opposite bet on purpose. "Never writes" isn't a missing feature for me, it's the wedge.
The people I'm building for juggle clients in 2-4 languages, and they're exactly the ones who won't let AI send on their behalf: a slightly off-tone reply to a German client or the tax office is expensive, and cross-language tone is where AI still slips.
So Avgi's job is to tell you what needs you and in which language, then get out of the way. You stay in control.
Genuinely curious though: are you seeing people comfortable approving AI drafts in a language they don't speak well?
That's the case I keep getting stuck on.
Fair distinction. My users are Korean business owners — one language, familiar context. And Slash it never sends automatically. Every reply goes through one tap approval. The human stays in the loop.
The cross-language trust problem you're describing is real though. Different markets, different bets. Curious how Avgi handles false positives in triage.
Makes sense, and honestly a single-language market is a cleaner starting point than mine, less ambiguity to fight. And fair on the one-tap approval, I had your flow wrong.
On false positives, my whole approach is to make a wrong call cheap by design:
Nothing is ever hidden or deleted, only labeled, so a mistake never loses an email. Worst case it sits one section lower in the digest, still right there.
Every classification carries a confidence score. Below a threshold it goes to an "uncertain" bucket and gets flagged for me instead of guessed, so the shaky calls surface rather than going silently wrong.
Correcting one is a single tap, and it updates that sender's memory so the same mistake doesn't repeat.
Since I never draft or send, a wrong triage can't become a wrong reply going out, which keeps the blast radius small.
Curious about your side: when a draft is off, does the one-tap approval catch it in practice, or do people end up editing more than they expected?
Honest answer: still pre-launch, so I don't have real usage data yet. My hypothesis is that a rough draft beats a blank page — even if they edit, the friction is lower than starting from scratch. But that's the assumption I most need first users to test. Your confidence score approach is smart. I'm doing something simpler — edit or approve, and the pattern feeds back to the OS over time.
Appreciate the honesty, that's refreshing. We're in the same boat: both pre-launch, both about to find out which core assumption survives contact with real users.
For me it's whether people trust the triage enough to lean on the digest; for you it's whether the draft beats the blank page.
Funny parallel too, your "pattern feeds back to the OS" and my "correction updates the sender's memory" are basically the same learning loop pointed at different jobs. Let's compare notes once we both have first users. Good luck with Slash it.
I’d be careful with treating this as a feature question too early.
The challenge may not be what Avgi does. The challenge may be that "people with too much email" is a very broad group, and different types of overload lead to very different buying behavior.
The risk is collecting waitlist feedback from people who agree the problem exists but would never actively adopt a solution.
That’s worth tightening before building too much around feature requests.
If useful, share your email and I’ll send over the tighter version in a way you can actually use rather than trying to solve it loosely in the thread.
This is the most useful thing anyone has said to me, thank you. You're right that "people with too much email" is too broad, and that waitlist agreement isn't adoption.
I'm narrowing toward a specific segment: freelancers and small agencies working with clients across English, German and French, where missing one time-sensitive email in a non-default language has a direct cost.
That pain is much sharper and more uniform than "busy inbox" in general.
I'd genuinely value your tighter version.
Happy to take it to email, but feel free to drop the gist here too so others in the thread benefit either way.
Glad that resonated.
The reason I'm hesitant to drop the gist publicly is that the useful part isn't the observation that the audience should be narrower. It's making the actual call on which overload pattern is worth building the product around.
A lot of product decisions start looking obvious once that choice is made.
Drop your email and I'll send the tighter version over properly.