Module 1 · Foundations of Agentic AI · scripted

Build a Prompt Pattern Library

40 min

Instructions as operations

Before you build anything, a way of seeing. A computer's power has always come from a small set of primitive operations — add, compare, sort, store — that compose into everything else. An LLM gives us new primitives, and each one is unlocked by a pattern of instructions: a reusable shape of prompt that, once you know it, works across a thousand situations. When you meet a prompt pattern, always ask the operational question:

The operational question

Don't ask: "what does this prompt say?"
Ask: "what OPERATION does this pattern give my computer —
and could a computer do that operation before?"

A pattern is not a trick. It is a new primitive.

We'll look at three patterns together — watch how each one names an operation — and then you'll go find three of your own.

Pattern 1 · Persona — the simulation operation

The shape: "Act as ___." One of the foundational patterns from the prompt pattern catalog (White et al., arXiv:2302.11382), and the simplest to say:

Example 1 · Act as
user

Act as a skeptical journal reviewer with expertise in research methods. Here is my abstract: [abstract about a survey study]. Give me your review comments.

assistant

As a reviewer, three concerns. First, you claim causal impact but describe a cross-sectional survey — no design you mention supports causation. Second, "significant improvement" appears without any effect size; reviewers will assume the worst. Third, the abstract promises "implications for policy" the study design cannot carry. Fix the causal language first — it invites rejection on page one.

NoteRead what the operation is: not "answer a question" but simulate a perspective — convincingly, on demand, in one line. A reviewer, a confused first-year student, a hostile customer, a regulator, a patient hearing bad news. Before, getting this perspective meant finding such a person. Now it is an operation.

The pattern

Act as <persona — who, with what expertise or stance>.

Here is <the material>.

<what you want from that persona: review, react, question, push back>

A key point: the persona does not have to be a person. You can simulate systems too — anything with consistent behavior:

Example 1b · Act as a system
user

Act as a Linux computer that has been the victim of a cyberattack. I will type bash commands, and you will respond exactly as the terminal would — output only, no explanations.

ls -la /tmp

assistant
total 48
drwxrwxrwt  9 root root  4096 Sep 12 03:11 .
drwxr-xr-x 20 root root  4096 Aug 02 09:30 ..
-rwxr-xr-x  1 www  www  38912 Sep 12 03:09 .kworker
-rw-r--r--  1 www  www    214 Sep 12 03:10 .cron.tmp
user

cat /tmp/.cron.tmp

assistant
*/5 * * * * /tmp/.kworker >/dev/null 2>&1
NoteThe persona here is not a person — it is a SYSTEM, played convincingly: a fake binary hiding as ".kworker", a dropped cron entry, plausible timestamps, and it stays in character command after command. Anything with consistent behavior can be simulated: a terminal, a database, an API, a bureaucracy. This one line conjured a security-training playground.

The operation: simulate. The ability to summon a convincing perspective — or a working imitation of a system — and interrogate it, stress-test against it, rehearse with it.

Pattern 2 · Flipped Interaction — the adaptive elicitation operation

The shape: "Ask me questions, one at a time, until you have what you need to ___." Also from the pattern catalog — and the key word is adaptive:

Example 2 · One question at a time
user

I need to choose statistics software for my lab. Ask me questions one at a time until you know enough to recommend one, then recommend.

assistant

First question: will the people using it primarily be writing their own analyses, or running analyses others have built?

user

Mostly running analyses others built. Two of us script; eight don't.

assistant

That changes my next question: for the eight — is a point-and-click interface a requirement, or would they run prepared notebooks if the setup were done for them?

NoteWatch the second question. It exists because of the first answer — the LLM used its domain knowledge plus what you said to choose what to ask next. This is not a form with fixed fields; it is an interview that steers. The expert interviewer's skill — knowing what to ask next — has become an operation.

The pattern

Ask me questions one at a time, until you can <goal>.

The same shape flips the other way: instead of drawing information out of you, it drives you through a task — one action at a time, adapting each next step to what you report back.

Example 2b · One action at a time
user

Walk me through recovering my lab's git repository — I think I deleted the wrong branch. Tell me ONE command to run at each step, wait for me to paste the output, and use it to decide the next step. Don't give me the whole plan up front.

assistant

Step 1. Let's see what git still remembers. Run this and paste the output:

git reflog --date=short | head -20

user
a1b3c9d HEAD@{0}: checkout: moving from feature/pipeline to main
7f2e001 HEAD@{1}: commit: add retry logic
c04ab19 HEAD@{2}: checkout: moving from main to feature/pipeline
assistant

Good — your work isn't gone. 7f2e001 is the tip of the branch you deleted. Step 2: create a new branch pointing at exactly that commit. Run this and tell me what it prints:

git branch feature/pipeline-recovered 7f2e001

NoteThis is the same pattern as the interview — one step at a time, each chosen from what came back — but pointed outward: the LLM is the expert, and YOU are the hands and eyes. The cooking-walkthrough, the debugging session, the lab protocol: all this one shape.

The pattern

Tell me one action to take at each step, until <goal>. Wait for me to report what happened, and use it to choose the next.

The core shape either way: do this ONE STEP AT A TIME, in order to achieve — with each step chosen from everything that has happened so far. It can pull information out of a person, or drive a person through a task.

The operation: elicit adaptively. The ability to draw the right information out — or drive the right action in — one adaptive step at a time, steering with domain knowledge.

Pattern 3 · Semantic Filter & Concept Detector — the meaning operations

Two shapes, one family. First: "Remove everything from ___ that ___" — where the condition requires understanding:

Example 3 · The semantic filter
user

Remove all information from this patient record that might help someone figure out that the patient has diabetes. Keep everything else intact. [record follows]

assistant

Redacted record attached. Removed: the metformin prescription, the HbA1c results, the endocrinology referral, the dietary counseling note — and the podiatry appointment, since routine foot exams are themselves a diabetes tell.

NoteStop on that last removal. No keyword list contains "podiatry" as a diabetes indicator — the filter required understanding what a reader could infer. This is filtering at the level of MEANING, and no classical program could do it at any price.

The pattern

Remove everything from <the material> that <a condition requiring understanding>. Keep everything else intact.

And its sibling: "Detect whether ___ is present in ___".

Before you meet it, one idea worth pausing on — it is what makes this whole family of operations feel different:

The old rigidity

Prior computing operations were rigid about the SHAPE of the data coming in: a fixed schema, a specific file format, columns in the right order. Hand them the wrong shape and they simply failed.

The new permissiveness

These operations are radically permissive about the input. The SHAPE of the information coming in matters far less than the QUALITY of it. Photo, contract, email, transcript — one pattern absorbs them all, as long as the meaning is there to be read.

The concept detector — one shape, any content

Example 1Detect whether a glass needs a refill … in this photo
Example 2Detect whether GDPR obligations are mentioned … in this contract
Example 3Detect whether the patient reports side effects … in this email
Example 4Detect whether anyone was assigned an action … in these minutes
One pattern:Detect whether a concept is present in anything

The blank on the left is a CONCEPT — not a keyword. The blank on the right is anything at all. This is a GENERIC OPERATION: one shape, applied to any kind of data you can hand the model.

One generic operation, any input

The operations: filter by meaning, and detect by concept. Tests and filters whose condition is understanding — applicable to any medium.

The patterns compose

Here is where it becomes computing. Primitives matter because they combine — and these combine as easily as arithmetic:

Example 4 · Two primitives make an inventory system
user

📷 a supply depot stacked with boxes and equipment

Detect all supplies in this photo related to IV therapy or patient mobility. Filter out anything whose contents can't be verified from the photo alone. Give me the list with approximate quantities.

assistant

IV therapy:

  • 0.9% NaCl (saline) injection, 100/150 mL — at least 4 cases, labels readable
  • Hospira infusion products — 3+ cases, front left
  • B. Braun cartons — 2 visible, upper right

Patient mobility:

  • Wooden crutches, child-sized — a stack of roughly 10–12 pairs, foreground

Excluded (can't be verified from the photo):

  • Several sealed cartons in the back rows — box shape only, no readable labels
NoteCount the primitives: a concept detector ("IV therapy or patient mobility supplies, in a photo") composed with a semantic filter ("only what the photo itself can verify"). Two patterns, one sentence apart — and together they are an inventory system that would have been a funded computer-vision project five years ago. Patterns that compose are worth ten that don't.

And notice the other kind of range: the same pattern crossed media without changing shape — a contract, a photo, a record, a meeting. A good pattern is promiscuous about what it applies to.

Patterns have different levels of abstraction

One more degree of freedom before you build. Patterns live at different levels of abstraction, and both levels are legitimate:

Generic and specialized

GENERICDetect whether <concept> is present in <anything> the most generic form — you fill in everything
SPECIALIZEDDetect comorbidities mentioned in <anything> the concept is baked in — shorter to invoke, loaded with the domain's meaning. But notice the input blank stays wide open: a patient history, a discharge summary, a chart, a photo of a medication list, a recorded conversation

A specialized pattern is a generic one with a domain concept pre-installed — specialized in WHAT it looks for, still generic in WHAT IT APPLIES TO. Your library can — should — hold both: a few wide primitives, and the sharp domain forms you use daily. (For a whole catalog of specialized patterns in one field, see prompt patterns for software development — White et al., arXiv:2303.07839.)

The possibility test

The last lens, and the one that separates a good library from a cute one. For each pattern, ask three questions about the operation as it stood before LLMs:

The possibility test

1. Could a computer do this before — at all?

2. Could we have had humans do it for other humans
   COST-EFFECTIVELY, at scale?

3. Could humans have done it FAST enough — at the volume,
   and with the parallelism, the task actually needs?

The most interesting patterns are the ones where all three
answers are NO: operations that were not possible — for
machines OR for people — until now.

See if you can find a pattern or two where every answer is no.
You don't have to — but it's a fun challenge, and it's where
the genuinely new primitives live.

If the honest answer is "a spreadsheet macro could do this,"
you have automated the past, not found a new primitive.

Your turn

Now build your library. This is a group exercise — no playground needed: work in your groups with any LLM you like (ChatGPT, Claude, Gemini, …), or start on paper. Pick a domain somebody in the group knows deeply — a research field, a job you've held, a craft, an institution you know from the inside.

The exercise at a glance

  1. 1
    Pick a domain your group knows deeply.
  2. 2
    Find three patterns for that domain that can compose.
  3. 3
    Document each one: a name, its operation, three example prompts, the possibility test.
  4. 4
    Sketch one composition that chains two of them.
  5. 5
    Present your library to the room.

Step 1 · Find three patterns

Step 1 · What you'll do

  1. 1
    Hunt where your domain relies on scarce human judgment, applied one item at a time.
    That scarcity is usually where the best pattern hides.
  2. 2
    Find THREE patterns that fit together.
    Generic or specialized — but they must be able to COMPOSE.
  3. 3
    Keep yourselves honest with the test: could a spreadsheet, a regex, or a search box do this?
    If yes — dig deeper into what only understanding can do in your domain.

Step 2 · Document each pattern

Step 2 · Do this for EACH of the three

  1. 1
    NAME it.
    A name someone else could invoke — like "flipped interaction."
  2. 2
    State the OPERATION in one sentence.
    "This gives us the ability to ___."
  3. 3
    Write THREE example prompts that all fit the pattern.
    Three different fillings of the same shape — try them in your LLM as you go.
  4. 4
    Run the POSSIBILITY TEST on it.
    Could a computer do this before? Could humans do it at scale, fast enough? Why not?

Step 3 · Sketch one composition

Step 3 · What you'll do

  1. 1
    Chain TWO of your patterns into something bigger — like the inventory system.
  2. 2
    Write the sketch in two or three sentences.
    What flows out of the first pattern, into the second, and what the whole thing becomes.

Before we present

💾 Save this before you move on

Keep one document for your group. Copy each item into it and save — you will present from this document, and we build on these libraries later in the course.

Copy into your course document and save:

  1. 1Your three patterns: the name, the one-sentence operation, and the three example prompts for each.
  2. 2Each pattern's possibility-test verdict, in a line or two.
  3. 3Your composition sketch.

Be ready to discuss:

  • Which of your three operations was flatly impossible for computers before LLMs — and what exactly made it impossible?
  • As the other groups present, listen for recurring shapes across completely different domains: which operations keep reappearing?

Each group presents its patterns, then its composition — talk them through out loud, or put prompts, examples, or a demo on the projector; we'll help you get it up there.

5-minute break