We keep circling this thing. The gap between what AI can do and how we actually use it day to day. Daniel's been living in that gap and he's got a whole taxonomy of it now.
He does. Here's what Daniel wrote to us. He says we've looked at this before, but AI is evolving so quickly it's worth revisiting periodically because from his perspective the need remains largely unaddressed. His gateway into AI was custom GPTs — miniature assistants where you define a system prompt and, if you want, add actions, although he hasn't explored that aspect very much. As AI has matured and he's become more involved with it professionally, much of his focus has shifted toward agentic AI workflows and autonomous agents. But he's come to think that these smaller, more constrained assistants are often the more useful and reliable form of AI in day-to-day life. He creates them for very specific text transformation tasks. He has one for this podcast that takes the text he dictates, tightens the structure, and organizes the questions. Early versions had a tendency to invent questions he hadn't asked, but after refining the prompt it's become very reliable. This is a good example of what he'd call a text-in, text-out assistant. He uses similar assistants for other narrowly defined tasks — for example, one for inventory where he can simply say, save this to my inventory system. Another useful example would be an email-to-meeting-agenda formatter. Paired with MCP integrations for email and calendar, that could naturally evolve into a lightweight agent that also handles the sending. One assumption baked into most AI products is that the interface should always be conversational. For these kinds of utilities, he thinks that's the wrong interface. If a text transformation works, he doesn't need an ongoing conversation. If it fails, it's often quicker to start a fresh interaction than continue debugging the existing thread. What he's been looking for for years is a better way to organize these tools. He might use ten or more of these micro-applications throughout a typical day for both work and personal life. He doesn't want to bookmark twenty separate custom GPTs, and the current interface isn't really designed for this workflow. The UI he's imagining is more like a workspace where each assistant is a small, self-contained application he can launch from a menu. Given how inexpensive LLM APIs have become — especially with models like DeepSeek — the cost of running these kinds of utilities all day is no longer the limiting factor. Then he asks: what would you call this category of software, does something like this already exist, and if not, are there open-source projects trying to build it?
Three questions, all pointing at the same hole in the market. He's built a whole ecosystem of tiny tools and they have no home. Let's start with the thing he's actually right about — why these constrained tools beat the big agentic stuff for daily work.
The invented questions. That's the detail that does the work here. His podcast formatter early on would fabricate questions he never asked. He fixed it by refining the prompt. That's a tiny failure surface — one kind of error, one place to fix it.
And that's exactly the mechanism. When you constrain the task to a single transformation — dictation goes in, structured questions come out — the output distribution tightens around what you actually want. A system prompt tuned for one thing has what I'd call a narrow success envelope. You know what good looks like, you know what bad looks like, and the distance between them is small enough that you can see the whole thing.
Whereas an agent...
An agent compounds error at every decision point. Each tool call, each time it extends the context window, each branch in the reasoning chain — every one of those is a new failure mode. And they don't fail in isolation. The failure at step three becomes the input for step four, and now you're debugging a cascade instead of a single bad output.
So the agent fails in ways that are novel and interconnected. The utility fails in one predictable way. Which one's actually more usable?
The one that fails predictably, every time. If I know my podcast formatter sometimes invents questions, I check for invented questions. That's a quick scan. If my autonomous agent sometimes hallucinates a calendar event and sometimes double-books and sometimes sends the wrong attachment and sometimes does all three in sequence because the second error fed the third — I now have to audit everything it touched.
You're describing the reliability paradox. The thing that makes agents powerful is the thing that makes them brittle. More autonomy means more decisions, more decisions means more places to be wrong, and the wrongness isn't contained.
Daniel's experience is a perfect illustration of this at small scale. The early podcast formatter invented questions. That's one failure type. He refined the prompt. Problem solved. If this had been an agentic workflow — the AI reads his dictation, decides which parts are questions, decides which need restructuring, decides whether to add follow-ups, decides whether to reorder — each of those decisions is a place where "inventing questions" could creep in from a different angle. Fixing it would mean hunting through a decision tree instead of tweaking one system prompt.
And the cost argument Daniel raises removes the last objection to having a dozen of these things. DeepSeek and similar models have driven API costs down to the point where running ten utilities all day is trivial. The bottleneck isn't compute anymore. It's organization.
That's a genuine shift. Two years ago you'd think twice about spinning up a dedicated assistant for something as narrow as "format my dictated podcast notes." Now the cost is noise. A few cents a day, maybe less. So the economic argument for consolidating everything into one big agent — "I can't afford ten API keys" — that's gone.
Which means the only remaining argument for the one big agent is... what, exactly? That it's what the products ship with?
Habit, mostly. And the fact that the UI for managing ten small tools doesn't exist yet, which is Daniel's whole point. But before we get to the interface problem, there's a distinction I want to nail down. These are not agents. Daniel's inventory assistant — "save this to my inventory system" — that's a structured action. It takes text in, it produces a structured output, it's done. There's no loop. No decision about whether to save, where to save, what format to use beyond what the prompt specifies. It's a deterministic transformation with a thin LLM core.
The LLM is doing the parsing, not the deciding.
It's turning natural language into a structured action. The structure is predetermined. The action is predetermined. The LLM is just the translation layer between "hey, I got three more of the blue ones" and whatever format the inventory system expects. That's not agency. That's a formatter with a very specific input domain.
And the podcast formatter is the same thing. Dictation in, organized questions out. The LLM is doing text transformation, not reasoning about what to do.
Right. And here's where Daniel's MCP point gets interesting. He mentions that an email-to-meeting-agenda formatter, paired with MCP integrations for email and calendar, could naturally evolve into a lightweight agent that also handles sending. That's the growth path. You start with the pure transformation — email text in, agenda out. That's your constrained utility. It works, it's reliable, you trust it. Then you add one integration: read from email via MCP. Now the input is automated but the transformation is the same. Then you add another: write to calendar. Still the same transformation, just automated I/O. Then you add sending. Now it's an agent, but the agent is built around a core transformation you already trust.
That's backwards from how most people think about building agents. The default assumption is start with autonomy and add constraints to fix the failures.
And that's the misconception Daniel's whole prompt is pushing against. Bigger and more autonomous is not always better. The natural path is start with a simple transformation that works, then add I/O integrations incrementally. Each addition is a small, testable change. If the sending breaks, you know it's the sending, because the transformation was solid before you added it.
The failure stays contained because the growth was contained.
Yes. And that argues for a whole different approach to building AI tools. Don't start by asking "what can this agent do?" Start by asking "what transformation do I actually need?" and then ask whether automating the I/O around it is worth the added complexity.
So we've established these utilities are reliable, predictable, cheap, and grow naturally into agents when you need them to. But Daniel's real complaint isn't about whether they work. It's about where they live.
The interface. This is where the whole industry is, I think, making a category error. Chat is the default for everything. You open ChatGPT or Claude or whatever, you get a text box, you start typing. That makes sense for exploration, for brainstorming, for things where you don't know what the output should look like. But for a utility where you know exactly what the output should look like?
Chat is a liability.
It's a synchronous, stateful medium. These utilities are asynchronous, stateless transformations. If the podcast formatter works, I don't need a thread. I fed it dictation, it gave me questions, we're done. The conversation is overhead. And if it fails — Daniel's point about starting fresh being faster than debugging the thread — that's because the context window becomes a trap. The failure is in the context. The prompt that didn't quite work is in the context. The model's wrong assumption about what you meant is in the context. Continuing the conversation means you're carrying all that forward.
Whereas a fresh start gives you a clean context window and a known starting state. You tweak the input, not the conversation.
And the input is the thing you can control. You can't control what the model latched onto three turns ago and is now treating as gospel. You can control the text you paste into a fresh window.
So what's the right interface? Daniel describes a workspace where each assistant is a small self-contained application launched from a menu. That's not chat. That's...
A launcher. Think Spotlight on a Mac, or the app dock, or the Windows start menu. You invoke the tool, you give it input, you get output, you move on. Each tool is a card with a defined input field and a defined output area. No conversation history unless you explicitly want it. No context carried forward from last Tuesday when you were formatting something completely different.
And the organizational model is spatial, not conversational. You arrange your tools, you name them, you group them. You don't scroll through a list of chat threads trying to remember which one was the inventory formatter.
Custom GPTs get close to this conceptually, but the interface is still chat-centric. You're still opening what looks like a conversation. And the management interface is just a list. Daniel's got ten or more of these — a list of twenty custom GPTs is not a workspace. It's a bookmark folder with a text box attached.
And that list doesn't tell you what the tool does at a glance. You have to remember. "Podcast formatter v3" — is that the one that stopped inventing questions, or is that the experimental one?
The naming problem. Which Daniel asked about directly. What do you call this category? I've been turning over candidates. Micro-assistants. Utility AIs. Prompt tools. AI applets. None of them have stuck in the industry, and that's itself a signal.
A signal of what?
That the category hasn't been productized. Names emerge when someone ships a product that defines the category and everyone else follows. We had "apps" because the iPhone App Store made "app" mean a specific thing. We had "tweets" because Twitter shipped a product with a character limit and a feed. Nobody has shipped the thing Daniel's describing, so there's no name for it.
The absence of a name is the absence of a product.
And the absence of a product is not because the need isn't there. Daniel's using ten of these a day. I'd bet most people who work heavily with AI have at least a handful of prompt templates they reuse constantly. They're just managing them badly — copy-pasting from notes apps, bookmarking chat threads, keeping a document full of system prompts.
I do exactly that. I have a note with about eight prompts I use repeatedly. Every time I need one I open the note, copy the prompt, open a new chat, paste it, add my input. That's the workflow Daniel's trying to escape.
And it's a workflow that exists because the tools don't. So what does exist? Custom GPTs are the closest mainstream thing. They let you define a system prompt, they give you a dedicated chat interface, you can share them. But they're still chats, and they're still buried in a list, and they're tied to OpenAI's platform.
What about open source?
There are projects. Nothing that's broken out as the standard. You've got things like Open WebUI which lets you manage multiple models and prompts, but it's still chat-first. There are developer-focused tools like LangChain's prompt templates, but those are for building applications, not for daily use. The niche is genuinely open.
So if someone were building this — a launcher-style workspace for micro-assistants — what would it actually look like?
I think it looks like a palette. You define a tool with three things: a name, a system prompt, and optionally an MCP integration or two. The tool appears as a card or an icon in a launcher. You click it, you get an input field — not a chat box, just a text area. You paste or type your input. You hit enter. The output appears below. That's it. No conversation. No history unless you enable it. The tool is a function, and the UI treats it like one.
And you'd want keyboard shortcuts. If I'm formatting podcast dictation three times a day, I want to hit a hotkey and be in the input field.
Power users would want this to feel like a system utility, not a web app. The model would be configurable per tool — you'd use a cheap fast model for simple formatting, a more capable one for things that need nuance. The cost per invocation would be fractions of a cent for most things.
Daniel mentioned DeepSeek specifically. The cost argument has flipped. It used to be that running ten separate API calls to ten separate tools felt extravagant. Now it's... What, less than a dollar a day for heavy use?
For most of these utilities, with a model like DeepSeek or even the smaller open models, we're talking maybe a tenth of a cent per call. If you're doing fifty transformations a day, that's five cents. The cost barrier is gone. What's left is the UI barrier and the organizational barrier.
Which brings us back to naming. You said none of the candidates have stuck. What's the one you'd bet on?
I keep coming back to "micro-apps" because it borrows from a paradigm people already understand. An app is a self-contained tool with a defined purpose. A micro-app is that, but smaller — one function, one input, one output. But I'll admit it's not great. "App" implies more than a text transformation.
"Prompt tool" is accurate but boring. Sounds like something you'd find in a settings menu.
"AI applet" has a nice ring but applets died with Java in the browser. "Utility AI" is probably the most descriptive — it tells you it's a utility, not a companion, not an assistant you chat with. But it's clinical.
The name that sticks will probably come from whoever ships the product. "I'm organizing my X" where X is whatever they called it. Until then we're just guessing.
That's the open invitation here. Daniel's essentially written a product spec in the form of a podcast prompt. The cost barrier is gone. The UI pattern is clear — it's a launcher, not a chatbot. The demand is proven by the fact that people are jury-rigging this workflow with notes apps and bookmarks. The niche is open.
The question is who fills it. Does a major player productize this, or does it come from open source?
My bet is open source gets there first. The big players — OpenAI, Anthropic, Google — they're all invested in the conversational paradigm. Their products are chats. Their business models are built around engagement, around conversations that continue, around you spending time in their interface. A utility you invoke for three seconds and close is not what their metrics want.
Whereas an open-source project doesn't care about engagement metrics. It cares about solving the problem.
Right. And the problem is well-defined. Manage a collection of system prompts, expose them through a launcher interface, pipe input to an API, display output. That's a weekend project for the core functionality. The hard part is polish — keyboard shortcuts, MCP integration, model selection, export and sharing. But the bones are simple.
There's a knock-on effect here that's worth pulling out. If this category matures — if we get a real micro-app launcher that people actually use — it changes how we think about AI products entirely. Right now the dominant metaphor is "assistant you talk to." This shifts it to "tool you invoke."
That shift has implications all the way down. Pricing, for one. If I'm using a tool for three seconds at a time, I'm not going to pay a twenty-dollar monthly subscription for it. Per-use pricing makes more sense, or a very cheap flat rate. Model choice — these utilities don't need the biggest model. A small, fast, cheap model does the job for most text transformations. Privacy — if the model is small enough, you can run it locally. Your inventory system, your email formatter, your podcast dictation processor — those could all run on-device with no data leaving your machine.
The pendulum might swing back from autonomy to constraint. As models get cheaper and smaller, the utility category could absorb tasks we currently delegate to agents.
I think that's exactly where we're heading. The agent hype cycle has been intense, and agents are useful for complex multi-step workflows. But most daily AI use isn't complex multi-step workflows. It's "clean up this text," "format these notes," "extract the action items from this email." Those are transformations. They don't need autonomy. They need reliability.
A UI that doesn't make you open a chat window.
A UI that doesn't make you open a chat window. Daniel's been saying this for years, apparently, and the industry still hasn't caught up.
Let's land the practical side. Someone listening to this, they've got their own collection of prompt templates scattered across notes apps and bookmarks. What do they actually do this week?
First, audit your daily AI use. Identify your top five to ten text-in, text-out transformations. Not the exploratory chats, not the brainstorming sessions — the things where you know the input and you know what the output should look like. Those are your candidates.
The podcast dictation formatter, the email-to-agenda converter, the inventory logger. Things where you're feeding text in and expecting structured text out.
For each one, write a tight system prompt. Be specific about the output format. Test it against known failure cases — like Daniel's invented questions. A constrained tool that fails predictably is more valuable than an agent that fails creatively. Find the failure pattern and prompt around them.
Then watch the MCP ecosystem. The path from formatter to agent is already paved. Start with a simple transformation, get it solid, then add I/O integrations one at a time. Don't build a full agent from scratch. Grow one from a utility you already trust.
If you're a builder, this is an open niche. A launcher-style workspace for micro-assistants — the cost barrier is gone, the UI pattern is clear, and the demand is proven by the fact that people are jury-rigging it already. This is a viable open-source project. Maybe a very good one.
If you're not a builder, you're still doing the audit and writing the prompts. Because when the tool arrives — and it will — you'll have your library ready.
Hilbert: But if these utilities are so simple and reliable, why hasn't someone just built a folder of system prompts and a shell script to pipe text through an API? Why does this need to be a product at all?
It doesn't need to be a product. It can be a shell script. And for a certain kind of user, that's exactly the right answer. But most people don't want to manage API keys and write launch scripts. They want a launcher they can click. The shell script approach is what people are doing now because the product doesn't exist. The product exists to make that workflow accessible to everyone who isn't comfortable at a terminal.
Also, a shell script doesn't give you MCP integration, model switching, or a visual library of your tools. It works, but it's the floor, not the ceiling. Thanks, Hilbert.
The open question I keep coming back to is whether a major player will recognize this category and ship something, or whether it'll stay an open-source niche. My instinct is the latter, at least for the next year or two. The incentives for the big AI companies point toward conversation and engagement. A utility launcher is almost anti-engagement — you use it and you leave.
Which is exactly why it would be useful. The best tools get out of your way. The best AI tool might be one you barely notice you're using.
If you've built your own collection of these micro-assistants, or if you've got a name for the category that's better than anything we came up with, we want to hear about it. Email the show at show at my weird prompts dot com.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. We'll be back soon.
