Launching today
Audryo
Customer email your agent can operate.
25 followers
Customer email your agent can operate.
25 followers
Audryo is lifecycle email built for AI agents. Connect Claude Code, Codex or Cursor via MCP, API or CLI. Your agent can create audiences, journeys, campaigns and branded emails, then measure what worked. You approve before anything reaches a customer. Every new project starts in a sandbox, so you can test with real data without sending. Emails go through your own provider. Store contacts for free; after beta, pay only for the people you email each month. Free during public beta.
Audryo
Hey Product Hunt 👋
I'm Werner from Dear Friend, a product studio in Germany.
Two things about email tools kept annoying us:
They're built for clicking. You pick the audience, draw the journey, write every email, check consent, all in a canvas. Meanwhile we spend our day working with AI agents. Some tools have since added an MCP server on top, but the product underneath is still a canvas.
They charge for contacts you store. Your list grows with every signup, so your bill does too, even for people you haven't emailed in a year. We caught ourselves deleting customer data just to stay on a cheaper plan.
So we built Audryo agent-first: the API is the product, and our app is just one client of it.
• Your agent does the work. Audiences, journeys, campaigns, emails, transactional sends, all over MCP, API or CLI.
• You approve. Agents draft and set things up; nothing reaches a customer until you say so.
• Sandbox first. Run journeys on real data and see every email without sending a thing.
• Your own sender. Mail goes out through your Resend, Mailgun or SMTP account, so your domain reputation stays yours.
• Pay for who you email. Store every contact and event for free. Someone only counts in a month you actually email them.
Audryo works for both sides of the team: developers sync contacts and product events via API, marketers plan and review in the app or with their own agent. Nothing goes out without a human approving it.
Getting started takes about five minutes:
Sign up and create a project (it starts in the sandbox)
Create an API token
Connect your agent → Agent quickstart
Then try: "Set up an onboarding journey for signups who haven't created a project after 3 days." Your agent builds the audience, writes the emails and tests it in the sandbox.
Free during the public beta. I'm here all day. What would you hand to your agent first?
The sandbox for testing campaigns is a really useful feature. You can try things out without worrying about sending something be mistake.
Audryo
@manisha_bhil Thanks! Every new project starts in the sandbox, so you can trigger journeys with real data and see exactly who would receive what—without sending anything. It’s especially useful when your agent is setting things up and you want to check its work first.
Hey Werner, genuinely useful for us. We currently handle it in the codebase, nudging signups who haven't connected a repo after 2 days etc.
We did it ourselves because we want to create the email rule / journey in our coding agent. Maintaining all these rules in the codebase has proved a challenge - no visibility!
I've signed up and we'll give it a proper test over the next few days.
One onboarding thought - for an agent-first product, starting in the UI (create a token, copy a one-time secret, export it, paste a project ID) feels backwards. Could the agent start it instead? Install the plugin, the first call opens a browser approval, I pick the project and scopes, done. No secret to copy or leak. Claude Code and Codex both support OAuth on remote MCP servers now.
And "pay for who you email" is a great model.
Audryo
@simon_moxon Thanks for signing up! The “rules in the codebase, but no visibility” problem is exactly what we wanted to solve: keep creating them with your coding agent, while giving the team somewhere to inspect the audience, emails and timing.
You’re right about onboarding. We made the agent workflow central, but getting connected still involves too much manual setup. Browser approval with project and scope selection sounds like a much better starting point. I’ll look into OAuth for remote MCP onboarding; I don’t want to promise a timeline before checking the implementation.
Your repo-connection nudge would be a great first test. I’d love to hear how it compares with your current setup, especially whether the sandbox makes it clear who would receive what and when. Thanks for the thoughtful feedback!