In 2024, a group of researchers at the University of Maryland brought together 30 other co-authors — from universities and from companies such as OpenAI, Microsoft, and Google — to answer a simple question: is there really a right way to ask an AI for something? The result, published under the title "The Prompt Report," analyzed more than 1,500 academic studies and catalogued 58 different techniques for making requests to AI models, plus another 40 specific to image, audio, and video.
The central conclusion is not sophisticated, but it is uncomfortable: the same question, worded two different ways, can produce answers of very different quality — from the same model, on the same day. Part of what companies call "the AI isn't good enough" is, in practice, "the request wasn't well written."
This matters for anyone deciding whether to invest in AI, because it explains a common pattern inside companies: the same tool that disappoints one person solves another person's problem — and the difference is rarely the tool itself.
The generic summary and its hidden cost
Ask an AI to "summarize this" and the result is usually a correct paragraph that is not much use: generic enough to fit any document, and specific enough to fit no real reader. The person reads it, discards it, rewrites the request, tries again. Every attempt costs time — and, on many AI tools billed by usage, it costs budget too.
OpenAI's official guide for building on top of the AI sums up the reason in one line: the first recommended strategy is to write clear instructions, and the second is to split complex tasks into smaller parts. A request like "summarize this" does not say who the summary is for, what should be left out, or what format the reader expects — so the AI model fills those gaps with a generic guess, because that is the only option it has.
Anthropic's official documentation, for the maker of the Claude model, arrives at the same rule from a different angle: it recommends treating each request as a set of clear parts — context, instruction, output format — rather than one continuous sentence. An AI model follows the literal instruction it received, not the intent that stayed only in the requester's head.
Why trying again alone does not fix it
The most common workaround is for the person to tweak the request on the next attempt, improving it a bit each round, until they get it right on their own. It works — but only for whoever is asking at that moment. As soon as that person changes teams or goes on leave, the good request disappears with them. Whoever comes next starts from zero, with the same generic summary as before.
"The Prompt Report" calls the process of refining a request until it works reliably "prompt engineering" — the skill of asking in a way that works by design, not by luck. Among the 58 catalogued techniques, four elements show up repeated across most of them — the same ones OpenAI's and Anthropic's own guides recommend:
- Context: what the AI needs to know that isn't obvious from the request — who it's for, for what purpose, what has already been tried.
- The writer's role: what function the AI should answer in, as if it were someone from legal, from finance, or a senior analyst in the area.
- Output format: a list, a table, a short paragraph, a ready-to-send email. Stating the format upfront avoids a second round spent only on reformatting.
- Acceptance criteria: how the person will know the answer is good — length, tone, what must appear and what must not.
A request with these four parts tends to land on the first attempt. A request without them turns into a multi-round negotiation — and every round is someone's time and, on many tools, metered cost too.
What has to be in place
The problem, then, is not only writing a better request — it's stopping a good request from staying locked inside the head of whoever wrote it. That takes mechanisms, not good intentions.
A good request becomes a reusable template. Once someone finally nails the request for a recurring task — closing a monthly report, answering a common type of request, reviewing a standard contract — that request needs to become a saved template, not a personal secret buried in an old conversation.
Scope defined by person, group, and role. A request template created by finance does not need — and should not — show up for everyone. It gets shared with whoever has the right role to use it, the same access logic that already exists for folders and systems, applied to AI requests too.
One current version, not several loose copies. Without control, each person keeps their own copy of "the request that worked" — in a notes app, an email, a pinned message. When the process changes, no one knows which copy is out of date. The template needs an owner and a current version, the same way any other internal process document does.
Agents that already carry the request built in. Instead of the person writing the request from scratch every time, an agent set up for a specific routine already carries the right context, role, and format — the person only enters the information for that particular task.
This is how Skyller was designed: reusable request templates and agents, scoped by person, group, and role, so one person's good request becomes time saved for the whole team — with more than 170 ready-made policy and process templates for anyone who doesn't want to start from zero.
From individual request to team capability
The gain from reusing a good request is not just speed — it's consistency. When ten people on the same team ask for the same thing ten different ways, the company gets ten different qualities of answer to the same question. That's the opposite of what any operations area wants: the same type of request should produce the same standard of answer, not depend on the luck of who happened to write the better request that day.
Reuse also changes who can get good results from AI. Today, getting the most out of it takes some trial and error that not everyone has the time or patience for. When the good request already comes ready — inside an agent, a saved template, a multi-step flow — someone who has never written an AI request in their life gets close to the result of someone who spent months refining one.
There's also a direct effect on the bill. A poorly written request costs more attempts, and more attempts cost more use of the tool. In a company with a shared AI budget across the team, one request designed well and used by everyone afterward is budget left over for other routines.
A starting checklist
Before writing yet another request from scratch, a short checklist helps turn "summarize this" into something that works on the first try:
- Write the context before the task. Say who it's for, for what purpose, and what has already been tried — don't leave the AI to guess the rest.
- Give an explicit output format. A list, a table, a ready-to-send email: the right format eliminates an entire round of rework.
- Define the acceptance criteria. Describe what makes the answer good — length, tone, what must appear and what must not.
- Save what worked. A request tested once should become a template, not get lost in an old conversation.
- Ask who else does this task. If three people on the same team make the same type of request, one shared template replaces three reinventions.
