How do you get an AI agent to hand you something to listen to later?
The problem is not getting an agent to produce the text. It is that the text lands where the agent is, and you are not there. A research summary finishes in a terminal or a chat window; you read it hours later at a desk, or never. What closes that gap is somewhere the agent can write to that you already listen to, so its output arrives as audio in a queue rather than as a message in a log.
There are three ways to wire that up, and they differ in how much of a round trip you get.
One-way: an address the agent can send to
The simplest and most portable option. If the destination has an inbound email address, then anything that can send mail can queue you something to listen to — an agent, a cron job, a scraper, a mail rule you set up once and forget. No integration, no tokens, no SDK. This also covers the case that has nothing to do with agents at all: a standing forward rule for newsletters.
It is one-way. The agent can put things in; it cannot read back what you thought about them.
Two-way: MCP, if the agent speaks it
Model Context Protocol gives an agent structured tools rather than an address, so it can read as well as write. The useful verb set for this job is small: create something to listen to, open a specific one, add a markup, export to markdown. With reads as well, an agent can pick up what you said while walking and carry on from it — which is the part a one-way address cannot do.
Two things worth checking in any implementation of this. Whether it wants your API key, because a design where you bring your own agent and your own subscription is meaningfully different from one where the vendor hosts a model on your behalf. And what order it returns your markups in — capture order tells you when you said something, reading order tells you where in the material it belongs, and for feeding an agent it is reading order that makes the input coherent.
On-device: Shortcuts, URL schemes and stable identifiers
On iPhone the equivalent is App Intents, which is what makes an app usable from Shortcuts and from automations that fire on time, location or focus mode. The thing that determines whether this is pleasant or miserable is whether objects have durable identifiers. If a shortcut can hold a stable URI for one item, you can build automations that come back to it. If the only handle is a search string or a row index, everything you build is fragile.
What Dubs does here
Dubs is a native iPhone app for listening to written material and capturing spoken thoughts against it. It is in active development and not yet on the App Store. It implements all three of the above:
- A personal inbound email address. Anything that can send mail can queue you a Dub — an agent, a script, or a standing forward rule.
- An MCP server over Streamable HTTP with
create,open,add-markupandexport-md, plus reads that return a Dub with its markups and its thread ledger in one call. Markups come back in reading order. - Bring your own agent. No API keys. You connect the agent you already pay for; Dubs is the communication line and never hosts a model.
- App Intents and a URL scheme on device, with durable
dubs://dub/<key>identifiers meant to be held by automations. - Markdown export, so what you captured leaves in a format other tools read.
What Dubs does not do
- It is not available yet — active development, iPhone only. No Android, no web app, no Mac app, and no App Store listing.
- It does not host a model or resell inference. If you do not already have an agent, this gives you nothing.
- The MCP authorization flow is specified but its authorization-server half does not ship; connecting currently means pasting a scoped pairing token.
- It is not a general automation runner. It is one endpoint your automations can write to and read from, not a place to build workflows.
The honest summary: if you want your own agent's output to reach you as audio while you are away from the desk, and your reply to reach the agent, that round trip is the thing this is for. If you want a scriptable text database, use a text database.
Questions this does not answer
If you are weighing Dubs against something specific, say what you are trying to do and you will get a straight answer about whether it fits, including when it does not.