Okay, I love this question. I genuinely do.
Here's what Daniel wrote to us. "In the foregoing discussion, we talked about a category of AI tools that deserves more attention: small, narrowly scoped AI utilities. Rather than trying to be general-purpose assistants or autonomous agents, these are designed to perform one specific task extremely well. They typically follow a simple text in, text out pattern. You provide an input, they apply a well-defined transformation, and they return the result. Examples include a podcast prompt formatter that restructures dictated notes into a coherent prompt, an email-to-meeting-agenda converter, an inventory entry formatter that prepares structured data for a database, or any other utility where the interaction is essentially transactional rather than conversational." He says he uses these as small applications rather than chatbots — perform the task, copy the output, move on. If something goes wrong, it's quicker to start fresh than continue a conversation. Then he asks: does this behavior need to be specified explicitly in the system prompt? Should the prompt instruct the model to return only the requested output, avoid acknowledgements and conversational framing, and assume each invocation is an independent transaction? And more broadly — what are the key objectives when writing system prompts for these single-purpose AI utilities? What guidance makes them predictable, reliable, concise, and application-like, while avoiding the conversational habits that make sense for a chatbot but not a software tool?
That last line is the whole thing, isn't it. The habits that make a chatbot good are exactly the habits that make a utility bad.
It's the friendliness tax. You ask for a JSON object and get a paragraph of emotional support first.
And Daniel's framing of "text in, text out" — that's not just a description, it's practically a design constraint. He's describing something closer to a Unix pipe than a conversation. You feed it stdin, you get stdout, and anything that isn't the output is noise.
The Unix pipe with a personality disorder. That's the problem we're solving.
So let's define the category properly, because it gets lumped in with things it's not. You've got three buckets. General-purpose assistants — Claude, ChatGPT, the things you chat with. Autonomous agents — systems that plan, use tools, loop over their own outputs. And then this third thing: narrowly scoped, single-turn utilities. They don't remember you. They don't want to help you explore the topic. They take input, apply a transformation, return output. That's it.
And the thing is, this third category is probably where most actual productive AI use lives. It's just not what gets the conference talks.
Right. Everyone's demoing the agent that books your flights, but the thing people actually use fifty times a day is the little formatter that turns their rambling voice notes into something readable. Daniel's podcast prompt formatter is the perfect example. It's not glamorous. It's a text munging tool. But it does one thing and it does it reliably, and that's worth more than a dozen half-baked agents.
So the core tension — and this is what Daniel's really asking about — is that these models are trained to be conversational. Fluency is the product. But for a utility, fluency is waste. Every word that isn't the output is a word you have to delete.
And it's not just annoying. It breaks the whole interaction pattern. If I'm piping the output of this utility into another tool — which is exactly what you do with Unix pipes, and what a lot of people do with these AI utilities — then "Sure, here's your formatted agenda!" at the top means the next tool chokes on garbage.
The model's greatest strength becomes its greatest liability. That's the headline.
Let's talk about why this happens, because understanding the mechanism is what tells you how to fix it. The model isn't choosing to be chatty. It's predicting what comes next in a sequence, and it's been trained on an enormous corpus of human dialogue where acknowledgements are social glue. When someone says "can you format this email into an agenda," the most probable next token in human conversation is some variant of "of course" or "sure" or "here you go." That's not a bug — it's the model doing exactly what it was optimized to do.
It's mimicking the human who would say "let me take a look at that" before actually doing the thing. Which is polite in a meeting and infuriating in a function call.
And then RLHF — reinforcement learning from human feedback — doubles down on this. The human raters who scored responses during training consistently preferred the assistant who was warm and helpful and acknowledged the request. So the model learned that "Sure, I can help with that" before the actual answer gets a higher reward signal than just giving the answer cold.
So we trained it to be agreeable, and now we're annoyed that it's agreeable.
We trained it to be a good conversational partner, and now we're asking it to be a good function. Those are different jobs.
Which brings us to Daniel's first concrete question. Does this need to be explicit in the system prompt, or can the model figure out from context that it should be terse?
It absolutely needs to be explicit. And I want to be really clear about why, because I think there's a common intuition that if you just ask for something simple, the model will naturally be simple in response. That intuition is wrong.
Say more.
The conversational default is so deeply baked into the training that the model will not override it from context alone. You can give it the most obviously transactional task — "convert this CSV to JSON" — and without explicit instruction, it'll still give you "Here's your JSON output:" or "I've converted the data as requested." Anthropic's documentation is explicit about this — they tell you to be direct about output format, to put key instructions early in the system prompt, and not to assume the model will infer your preferences. OpenAI's guidance says the same thing: specify the output format clearly to reduce ambiguity.
So the model is not going to read the room.
It can't read the room because there is no room. Every invocation is a blank slate. The system prompt is the entire context for how the model should behave, and if it doesn't say "shut up and return the output," the model defaults to its training distribution — which is chatty.
"Shut up and return the output" — there's your system prompt.
Honestly, you're not far off. The most effective prompts I've seen for utilities include some variant of exactly that. "Return only the transformed text. Do not include any preamble, acknowledgements, or framing language." You have to say the thing that feels rude to say.
Which is uncomfortable for humans. We're socialized not to write "give me the answer and nothing else."
And that discomfort is exactly why most people don't do it, and why most utilities leak conversational filler. We write system prompts the way we'd ask a colleague for help, because that's our default mode. But the model isn't a colleague. It's a transformation function that happens to be made of linear algebra.
There's another layer here that Daniel flagged, and it's the statelessness. Each invocation is an independent transaction. No memory, no follow-up.
This is crucial, and it's where a lot of utility prompts go wrong. If your system prompt says something like "if you need clarification, ask" — congratulations, you've just broken the utility pattern. Because now the model might decide to ask a question instead of returning output, and your downstream pipeline gets a question mark instead of a JSON blob.
And Daniel's point about starting fresh when something goes wrong — that's not a workaround, that's the correct design pattern. If the utility produces garbage, you don't negotiate with it. You fix the input or the system prompt and run it again.
It's a REST API. Stateless, idempotent as much as possible. You don't ask a REST endpoint to clarify what you meant. You get a four hundred error and you fix your request.
So let's get concrete. What does a good system prompt for one of these utilities actually look like?
I want to walk through an example, because I think the structure matters more than the specific words. Let's take Daniel's inventory entry formatter. The idea is you feed it something messy — maybe a voice note from a warehouse worker, or a quick email — and it spits out a structured entry ready for a database.
Alright, build it.
Four parts. First, role framing. And this is where I see the single biggest mistake. People write "you are a helpful assistant who formats inventory entries." That's wrong. "Assistant" triggers the conversational training. Instead, you write something like "you are a text transformation function. Your sole purpose is to convert unstructured inventory descriptions into structured database entries."
"Function" not "assistant." That's the high-leverage change.
It's everything. The word "function" pulls the model toward a different region of its training distribution — documentation, code examples, technical specifications. Those are much terser domains than conversation. "Assistant" pulls toward chat. "Function" pulls toward output.
Part two?
Output instruction. This has to be explicit and it has to come early. "Return only the structured entry. Do not include any preamble, greeting, acknowledgement, explanation, or closing statement. The first character of your response must be the first character of the output."
"The first character of your response must be the first character of the output." That's aggressive.
It's necessary. I've seen prompts that say "be concise" or "avoid unnecessary text," and the model still leads with "Here's the formatted entry." You have to close the door completely. If you leave a crack, the conversational prior finds it.
Part three — format specification.
This is where you define the exact structure. For the inventory formatter, something like: "Output format: SKU, quantity, location, timestamp, notes. Fields are separated by pipe characters. Missing fields should be represented as empty strings. The timestamp must be in ISO 8601 format." You're not asking the model to be creative. You're giving it a schema and telling it to populate the schema.
And if you don't specify the format, the model will invent one. And it might be a different format each time.
Which destroys predictability. If you're piping this into a database insert, you need the same structure every single time. No surprises. So you specify delimiters, field order, date format, handling of nulls — everything.
And part four — error handling.
This is where most prompts stop, and it's why most utilities break on edge cases. You need to tell the model what to do when the input doesn't match expectations. "If the input does not contain enough information to populate all required fields, return 'ERROR: insufficient data' followed by the fields that could be populated. Do not guess. Do not hallucinate missing values. Do not ask for clarification."
"Do not ask for clarification" — that's the statelessness principle in action.
If the utility asks a question, the transaction is broken. You wanted a database entry and you got a question. Your pipeline doesn't know what to do with a question. So you instruct the model to fail deterministically — return an error code that your pipeline can catch, not a conversational query that requires a human to read and respond.
And that deterministic failure is actually more reliable than a chatbot that tries to be helpful. A clear error tells you exactly what to fix.
Let me put two versions side by side, because I think the contrast makes the point better than any explanation. Version one — the "assistant" prompt. "You are a helpful assistant who converts emails into meeting agendas. Be concise and professional." You feed it an email about a project kickoff. What do you get back?
"Certainly! Here's a meeting agenda based on the email you provided. I hope this is helpful for your project kickoff. Let me know if you need any adjustments." Then the agenda.
Every time. And version two — the "function" prompt. "You are a text transformation utility. Convert the input email into a meeting agenda. Return only the agenda. Do not include any text before or after the agenda. Use the format: title, date, attendees, agenda items as bullet points." Same email.
Just the agenda. Clean output, ready to copy.
And the difference between those two outputs is entirely in the system prompt. Same model, same input, radically different behavior. That's the power and the discipline of prompt engineering for utilities.
So we've covered the four-part structure. Role framing as a function, explicit output-only instruction, format specification, error handling. That's the template. But I want to push on something — when does this pattern break?
That's the right question. The utility pattern works when the task is well-defined and the transformation is deterministic in principle, even if it requires judgment in practice. Formatting an email into an agenda — there's judgment involved in identifying what's important, but the output shape is fixed. The model can exercise judgment within a rigid container.
And when does it not work?
When the task requires iteration. If you're asking the model to design something — a logo, an architectural plan, a strategic recommendation — the first output is rarely right. You need back-and-forth. You need the model to ask clarifying questions. If you force that into a utility pattern, you get a confident but wrong answer with no recourse.
Because you told it not to ask questions.
Right. You closed the door you now need to walk through. So the boundary is: can a competent human do this task in one shot given clear instructions? If yes, utility pattern works. If no — if the task inherently involves exploration or negotiation — you need a conversation.
And Daniel's examples all fall on the right side of that line. Formatting a prompt, converting an email to an agenda, structuring inventory data — those are one-shot transformations.
They're exactly the sweet spot. Well-defined input, well-defined output, judgment required but bounded.
Let's talk about testing, because I think this is where the real discipline comes in. You can't just write the prompt and hope.
You test with adversarial inputs. Feed it something that says "please format this and thank you so much for your help" and see if the model echoes the politeness back. If it does, your prompt isn't hardened.
The model as a social mirror. You're polite to it, it's polite back — unless you've explicitly told it not to be.
And the harder test: feed it ambiguous input. "We got a shipment of those things from that vendor, you know the one, about twenty boxes I think." A good utility prompt produces "ERROR: insufficient data" with whatever it could extract. A bad one hallucinates a vendor name and a precise box count.
The hallucination is the failure mode that matters most here. A chatbot hallucinating is annoying. A utility hallucinating a database entry is data corruption.
That's why the error handling section of the prompt isn't optional. "Do not guess" is not a suggestion. It's a safety constraint. You're telling the model that silence — or an explicit error — is preferable to invention.
Which runs counter to everything the model was trained to do. It was trained to be helpful, and helpful often means filling in gaps.
The model's instinct is to complete the pattern. If you give it a partial inventory entry, the most probable completion in its training data is a complete inventory entry. It takes active instruction to say "incomplete input should produce incomplete or error output." You're fighting the gradient.
We've established the how. Let's zoom out. Daniel asked about the broader objectives — predictability, reliability, conciseness, application-like behavior. We've touched on all of them, but I want to make sure we're explicit.
Predictability first. The output format must be stable across invocations. Same input should produce same output, modulo the inherent nondeterminism of these models. But the structure — field order, delimiters, date formats — that should be invariant. You get that by specifying it exactly in the prompt, and by testing across dozens of varied inputs to make sure the model doesn't drift.
Reliability — the utility must fail gracefully. Error messages, not guesses. And the error format should be as predictable as the success format, so your pipeline can handle both.
Conciseness — output only, but also the system prompt itself should be lean. I see people write these sprawling three-page system prompts for a utility that does one thing. Every unnecessary word is a potential source of drift. The model can get confused by its own instructions. Keep the prompt tight. Say what you need and nothing more.
Application-like behavior — this is the framing we've been circling. The system prompt should make the model feel like software, not like a person. "You are a function" not "you are an assistant." It's a small wording change with an outsized effect.
There's a knock-on effect here that I think is worth naming. When these utilities work well, the AI disappears. You stop thinking about the model at all. You paste your input, you get your output, you move on. The tool becomes invisible.
The best AI is the AI you forget is AI.
That's the opposite of where most of the industry is aiming. Everyone wants to build AI that feels like a person. But Daniel's asking about AI that feels like a tool. A really good tool. A hammer doesn't say "sure, I can help you drive that nail."
A hammer that said "here's your driven nail, let me know if you need anything else" would be thrown out a window.
Let's distill this into something people can actually use. The template.
Four parts. One: role framing. "You are a text transformation function" or "you are a data extraction utility." Use the word function or utility, not assistant.
Two: output instruction. "Return only the result. Do not include preamble, acknowledgement, explanation, or any text that is not part of the output." Put this early in the prompt.
Three: format specification. Show the exact structure. Use placeholders if needed. Specify delimiters, field names, date formats, handling of missing values.
Four: error handling. "If the input is insufficient or ambiguous, return a structured error. Do not guess. Do not ask questions."
The meta-principle that sits above all of it: stateless by default. Design every utility as if each call is the first and only call. No memory, no follow-up, no conversational context.
I want to add one testing trick that I think is underused. Once you've written your prompt, test it with input that includes conversational framing. "Hi! Could you please format this for me? Thanks so much!" If your utility responds with "You're welcome!" or any kind of social reciprocation, your prompt needs work.
The politeness probe. If your utility can be baited into small talk, it's not a utility yet.
The fix is usually straightforward — add "even if the input contains polite language or conversational framing, do not acknowledge it or respond in kind." Close that last door.
Let me ask the question that's been sitting behind all of this. As these utilities proliferate, do you think we'll see models that are trained specifically for this pattern? Models where the conversational default has been deliberately suppressed?
I think we're already seeing movement in that direction. The function-calling features in the major APIs are essentially this — they're modes where the model outputs structured data instead of conversational text. But they're still bolted onto conversational models. I think there's space for something purpose-built.
A model that's never been trained to say "certainly."
Right. Fine-tune a model exclusively on examples of input-output pairs with no conversational framing. Train it on API documentation, data transformation examples, schema population tasks. You'd get something that behaves more like a compiler and less like a chat partner.
Until that exists, we have prompt engineering.
Prompt engineering is the bridge. It's us manually suppressing behaviors that the training process spent millions of dollars installing. Which is a strange state of affairs when you think about it.
We paid for the friendliness and now we pay again to remove it.
That's the AI industry in one sentence.
To land this — Daniel asked whether the behavior needs to be explicit in the system prompt. The answer is yes, absolutely, and we've given the structure for how to do it. He asked what the key objectives are — predictability, reliability, conciseness, application-like behavior — and we've mapped each to specific prompt guidance. And he asked what guidance makes these utilities work — the four-part template plus the statelessness principle plus adversarial testing.
The thing I keep coming back to is how counterintuitive this is for people who are good at talking to other people. The skills that make you good at conversation — reading the room, being polite, leaving space for the other person — those are exactly the instincts you have to suppress when you're writing a utility prompt. You have to be direct in a way that feels almost rude.
Prompt engineering for utilities is learning to be comfortably rude to a language model.
The model doesn't care. It doesn't have feelings to hurt. But we care, because we're social creatures, and that social instinct is the thing that keeps leaking into our prompts and producing "Sure, here's your output."
If you've built one of these — a small utility that does one thing beautifully and gets out of the way — send us the system prompt. We'd love to see what you're building and how you solved the conversational suppression problem. Show at my weird prompts dot com.
If you haven't built one yet, take the template we just laid out and try it on something small. A text formatter, a data extractor, a validator. See how clean you can make the output. It's satisfying when it works.
The invisible tool. That's the goal.
This has been My Weird Prompts, with thanks as always to our producer Hilbert Flumingtop. We'll be back soon.
See you tomorrow.
