The AUTOMAT Prompt Framework, Explained (With Examples)

TL;DR: AUTOMAT is a seven-part prompt framework: Act as a, User persona, Targeted action, Output definition, Mode/tone, Atypical cases, and Topic allowlisting. It builds one detailed, front-loaded prompt instead of a back-and-forth conversation, and it's most useful for prompts you'll reuse, where missing an edge case or a scope boundary actually costs you something.

What does AUTOMAT stand for?

AUTOMAT stands for Act as a, User persona and audience, Targeted action, Output definition, Mode/tone/style, Atypical cases, and Topic allowlisting. Each word maps to one letter, and each one answers a different question a well-built prompt needs to settle before you send it.

The framework comes from Maximilian Vogel's Medium piece "The Perfect Prompt: A Prompt Engineering Cheat Sheet," presented as the ingredient list for what he calls, only half-jokingly, the perfect prompt. It isn't an official standard from OpenAI, Google, or Anthropic; it's an independent framework, worth understanding on its own terms rather than assuming a lab invented it.

Here's the expansion, one line each:

If you've seen prompt templates before, AUTOMAT will look familiar: same instinct, pushed one step further into naming the failure modes explicitly.

Why do the first five letters cover things every framework has?

Because they're the load-bearing basics of any structured prompt, and AUTOMAT doesn't reinvent them; it just insists you don't skip any.

Act as a… sets the role: "act as a senior technical support agent for a SaaS billing product" reads differently than no role at all. This is persona prompting in its most direct form.

User persona and audience is what most casual prompts skip. "A frustrated, non-technical customer" produces a different reply than "a developer debugging a webhook". The model can't guess which one you mean.

Targeted action is the ask, stripped of hedging: not "help me with my emails" but "draft a reply that acknowledges the delay, offers a specific fix, and asks for one missing detail."

Output definition is the shape: length, format, table vs. JSON vs. prose. A lot of "the AI didn't do what I wanted" complaints are really this: a correct answer in the wrong shape.

Mode/tone/style is register (formal, casual, blunt) plus house rules like "no exclamation points."

None of these five are unique to AUTOMAT. RTF and CO-STAR cover the same ground under different letters. What AUTOMAT adds, and what most competing frameworks drop, is the last two.

What are "atypical cases" and why do most frameworks skip them?

Atypical cases are your instructions for what happens when the normal path doesn't apply. Most frameworks skip this because it's the least fun part to write.

It's easy to spec the happy path: user asks a normal question, model gives a normal answer. It's less obvious what to do when a field is missing, the request is ambiguous, or the user asks for something the prompt wasn't built to handle. Without instructions, the model guesses, sometimes reasonably, sometimes by inventing an answer that sounds confident and isn't (a hallucination, in the technical sense).

A few concrete atypical-case instructions, by scenario:

• Data lookup / table-building prompt: "If the release date is unknown, write a dash. If the title can't be confirmed, leave the row out entirely rather than guessing."
• Customer support bot: "If the user reports a billing charge they don't recognize, do not speculate about the cause. Tell them a human will review it within one business day."
• Recipe or how-to assistant: "If the user says their water is boiling too hard for a pour-over, tell them to let it rest 30 seconds off heat before pouring, rather than proceeding as normal."

None of these are exotic edge cases. They're the first weird input a real user sends within the first hour of using the thing. Naming two or three of them up front is cheap; discovering them in production, from a user complaint, is not.

What is "topic allowlisting" and why does it matter more than it sounds like it should?

Topic allowlisting is an explicit list of what the model is allowed to discuss, plus a fallback line for anything outside it. Without one, a narrow tool quietly turns into a general-purpose chatbot wearing your brand's name.

Say you're building a prompt for a farm-equipment company's support widget. Without topic allowlisting, questions about tractor financing, dog breeds, and the weather all get answered. The model doesn't know it's supposed to say no to two of those three. With it: "Only answer questions about our tractors, harvesters, and parts. For anything else, say: 'I can only help with questions about our farm equipment. For other topics, please contact support directly.'"

A tighter second example: a coffee-brewing assistant scoped to pour-over and French press only, with a line to redirect espresso questions elsewhere rather than improvise about a machine it wasn't briefed on.

This is the same instinct behind a system prompt that constrains a deployed assistant. You're drawing a boundary before the conversation starts, not correcting it after the fact.

How do you build an AUTOMAT prompt, letter by letter?

You start with a vague, one-line ask and add one AUTOMAT component at a time until the prompt says exactly what you mean. Here's the build, using a customer-support reply prompt as the running example.

Start, with no framework at all:

Help me reply to this customer complaint.

This works, technically. It also produces a generic, hedge-everything reply that reads like it came from nowhere in particular.

+ Act as a:

Act as a senior customer support specialist for a project-management SaaS product.
Help me reply to this customer complaint.

+ User persona and audience:

Act as a senior customer support specialist for a project-management SaaS product.
The customer is a small-business owner, non-technical, who has been a paying user for
8 months and is frustrated about a missed deadline notification.
Help me reply to this customer complaint.

+ Targeted action:

Act as a senior customer support specialist for a project-management SaaS product.
The customer is a small-business owner, non-technical, who has been a paying user for
8 months and is frustrated about a missed deadline notification.
Draft a reply that acknowledges the frustration, explains that deadline notifications
were delayed by a bug we've now fixed, and offers one month of service credit.

+ Output definition:

Act as a senior customer support specialist for a project-management SaaS product.
The customer is a small-business owner, non-technical, who has been a paying user for
8 months and is frustrated about a missed deadline notification.
Draft a reply that acknowledges the frustration, explains that deadline notifications
were delayed by a bug we've now fixed, and offers one month of service credit.
Output: a plain-text email, 3 short paragraphs, no subject line, no signature block
(I'll add that separately).

+ Mode/tone/style:

Act as a senior customer support specialist for a project-management SaaS product.
The customer is a small-business owner, non-technical, who has been a paying user for
8 months and is frustrated about a missed deadline notification.
Draft a reply that acknowledges the frustration, explains that deadline notifications
were delayed by a bug we've now fixed, and offers one month of service credit.
Output: a plain-text email, 3 short paragraphs, no subject line, no signature block
(I'll add that separately).
Tone: warm and direct, not corporate. No exclamation points. No phrases like
"we apologize for any inconvenience this may have caused."

+ Atypical cases:

Act as a senior customer support specialist for a project-management SaaS product.
The customer is a small-business owner, non-technical, who has been a paying user for
8 months and is frustrated about a missed deadline notification.
Draft a reply that acknowledges the frustration, explains that deadline notifications
were delayed by a bug we've now fixed, and offers one month of service credit.
Output: a plain-text email, 3 short paragraphs, no subject line, no signature block
(I'll add that separately).
Tone: warm and direct, not corporate. No exclamation points. No phrases like
"we apologize for any inconvenience this may have caused."
Atypical cases: if the complaint mentions a lost contract or financial loss beyond a
missed notification, do not offer a specific dollar figure — say an account manager
will follow up directly within 24 hours instead.

+ Topic allowlisting, the complete prompt:

Act as a senior customer support specialist for a project-management SaaS product.
The customer is a small-business owner, non-technical, who has been a paying user for
8 months and is frustrated about a missed deadline notification.
Draft a reply that acknowledges the frustration, explains that deadline notifications
were delayed by a bug we've now fixed, and offers one month of service credit.
Output: a plain-text email, 3 short paragraphs, no subject line, no signature block
(I'll add that separately).
Tone: warm and direct, not corporate. No exclamation points. No phrases like
"we apologize for any inconvenience this may have caused."
Atypical cases: if the complaint mentions a lost contract or financial loss beyond a
missed notification, do not offer a specific dollar figure — say an account manager will
follow up directly within 24 hours instead.
Only discuss this specific incident, the fix, and the credit. Do not discuss unrelated
account changes, pricing plans, or feature requests — if the customer raises one, note
that you'll pass it to the right team, and keep the reply focused on the complaint at hand.

That's the whole framework, applied. Seven additions, one prompt, no back-and-forth.

When is AUTOMAT overkill?

AUTOMAT is overkill for anything you're only going to run once. Asking for a one-line summary or a quick rephrase, writing out all seven components costs more time than the better output saves. Save it for prompts you expect to reuse — a support macro, a content template, an internal tool prompt — where a missed edge case or an out-of-scope answer would actually cost something downstream.

How does AUTOMAT compare to RTF, CO-STAR, CRISPE, and RACE?

Here's how the common frameworks stack up on component count and what each is actually for:

Quick context: RTF is Role, Task, Format. Minimal, good for a quick ask. CO-STAR is Context, Objective, Style, Tone, Audience, Response. Strong on tone, thin on edge cases. CRISPE is Capacity/role, Insight, Statement, Personality, Experiment. Built for creative prompts more than operational ones. RACE is Role, Action, Context, Expectation. Compact, similar territory to RTF.

None of these is wrong; see our roundup of 7 ChatGPT prompt frameworks for the fuller lineup. AUTOMAT's edge is narrow: it's the only one of the five with a named component for edge cases and a separate one for scope. That's overhead you don't need on a throwaway prompt. It's exactly what keeps a prompt your whole team reuses from quietly breaking.

AUTOMAT cheat sheet

Screenshot-ready version, the seven components one line each:

For the wider reference on tokens, temperature, and the mechanics AUTOMAT doesn't cover, see our prompt engineering cheat sheet, and what is prompt engineering for the fundamentals AUTOMAT builds on.

Is this what Prompt Architects' Enhance feature does?

Not exactly, and it's worth being precise: AUTOMAT is what a structured prompt looks like built by hand, letter by letter, the way we just did above. Prompt Architects' Enhance feature applies the same kind of structural thinking (role, task, format, constraints) automatically, in under 2 seconds, without you working through seven components yourself.

It doesn't literally run the AUTOMAT checklist under the hood, and we're not claiming it does. What it shares with AUTOMAT is the underlying belief: a vague prompt gets a vague answer, and the fix is structure before you hit send. If you want to compare the manual version above against the automated one, that's what the free plan is for: no API key required, working across ChatGPT, Claude, Gemini, and the rest of the supported platforms at the time of writing.