Agentic Patterns & Prompt Architecture

How to design the prompts that use your tools reliably

Day 1 · Session 6 — the bridge from Lab 2 to Lab 3

Where You Are Right Now

In Lab 2, you watched a model call your own code.

But you let the model decide how to chain the calls.

Lab 3 takes back that control.
Today you learn to tell the model exactly which loop to run —
and how to stop it from going wrong.

The Core Idea

A prompt without a pattern is a wish.
A prompt with a pattern is a design.

You're not asking the model to figure out how to work.
You're telling it which problem-solving loop to use.

Part 1 — The Core Agentic Patterns

Four ways to structure an agent's work

The Four Patterns at a Glance

Pattern Core idea Best when…
ReAct Reason → Act → Observe → repeat next step depends on the last result
Plan-and-Execute Plan fully upfront, then execute steps are predictable & independent
Reflection Do it, then critique & revise output quality matters and is checkable
Reflection + Re-planning Reflect mid-task, rewrite the plan early steps change what later steps should be

Pick the pattern that matches the shape of the task.

Pattern 1 — ReAct (the default)

Reason + Act, interleaved.

WHY — when you can't know the next step until you see the current result, planning upfront is impossible.

WHAT — a loop: Reason → Act (tool call) → Observe → Reason → Act → … → Done.

HOW — the model thinks, calls one tool, reads the result, then thinks again.

WHEN — research, debugging, open-ended gathering — anything exploratory.

This is what you already used in Labs 1 & 2. It's the default for a reason.

ReAct, In a Real Trace

What actually happened in Lab 2's end-to-end test:

[Thought]      I need to search the web first.
[Action]       search(query="TypeScript backend benefits")
[Observation]  3 articles. Key: type safety, refactoring, IDE support.
[Thought]      Enough info. Now create the entry.
[Action]       create_entry(title="TypeScript Benefits", ...)
[Observation]  Entry created. ID: abc-123.
[Thought]      Verify it saved.
[Action]       search_entries(query="typescript")
[Observation]  1 result found. Task complete.

Thoughts = Reasoning. Actions = Action. Observations = Perception.
That's the Session-2 agent loop, running in your editor.

Pattern 2 — Plan-and-Execute

WHY — for predictable tasks, committing to a strategy upfront avoids wasted, meandering tool calls.

WHAT — generate the full plan as text first, then execute each step; re-plan only if a step fails.

HOW — "Plan: 1) search entries 2) group by tag 3) write summary 4) save." Then run the plan.

WHEN — weekly summaries, batch processing, report generation — clear structure, independent steps.

ReAct figures it out as it goes. Plan-and-Execute decides first, then acts.

Pattern 3 — Reflection

WHY — a first draft is often not good enough; checking it against a rubric raises quality.

WHAT — after completing the task, the model critiques its own output and revises if it falls short.

HOW — "Does the entry have a title under 80 chars? Tags lowercase? Markdown content?" If not → revise.

WHEN — output quality matters, is verifiable, and an extra loop is worth the cost.

Reflection is a second-pass loop on top of the execution loop. The model grades its own work.

Pattern 4 — Reflection + Re-planning

WHY — in long tasks, what you learn early can change what you should do later.

WHAT — reflect mid-task and rewrite the remaining plan based on what's been discovered.

HOW — "Most entries are tagged mcp → replan: make an MCP-specific digest, not a general summary."

WHEN — long-horizon tasks where early results reshape the goal.

The most adaptive pattern — and the most expensive. Use it when the task genuinely shifts under you.

Choosing: ReAct vs. Plan-and-Execute

The most common practical decision:

Choose ReAct when

  • each step's output changes the next step
  • you can't predict the full tool sequence
  • the task is exploratory

Choose Plan-and-Execute when

  • steps are predictable and independent
  • you want to commit to a strategy before spending calls
  • the task has a clear, specifiable structure

Lab 3 question: search → synthesise → create → verify → report. Which pattern?
ReAct — the entry's content depends on what the search returns.

Part 2 — System Prompt Architecture

The agent's constitution

The Four Sections (in this order)

The system prompt defines what the agent is, what it can do,
what it must not do, and how it should respond.

  1. ROLE — who the agent is and its purpose. One sentence. The identity anchor.
  2. TOOLS — what it can use and when (purpose, not the schema).
  3. CONSTRAINTS — what it must not do: scope, max steps, guards, format rules.
  4. OUTPUT FORMAT — how to structure the final message back to the user.

Onboarding a colleague: "You are X. You have Y. You must not do Z. Deliver as W."

Why the Order Matters

  • Role first — it frames everything after it. "Research assistant" colours how every later line is read.
  • Constraints before output format — the model reads top-to-bottom; a constraint seen after the format may arrive too late to change a decision already forming.

The order isn't cosmetic. It's how the model's interpretation is built up, line by line.

A Complete System Prompt (the Lab 3 template)

[ROLE]
You are a StackLog research assistant. Research a topic, save a journal
entry, verify it, and write a report. Work autonomously.

[TOOLS]
- search:        find current info. Call at most twice.
- create_entry:  save findings. Call once, after researching.
- search_entries: verify the entry saved. Call once after create_entry.
- write_file:    save the markdown report. Call last.

[CONSTRAINTS]
- At most 6 tool calls total.
- Do not infer results from training data — call the tool.
- Summarise each tool result in one sentence; drop the raw data.
- Do not expand scope beyond the topic.
- Complete only when an entry ID is returned AND the report is saved.

[OUTPUT FORMAT]
"Task complete. Entry ID: [id]. Report: [path]. Key finding: [one sentence]."

The system prompt is not a suggestion. It's an engineering constraint.

Same Model, Different Results

The live demo: run the Lab 3 task without, then with, the system prompt.

Without — may or may not call tools · no consistent format · stops early or loops · inconsistent titles/tags · no clear "done."

With — exactly the planned calls · clean "Task complete." · lowercase tags, title under 80 · stops within the step budget · ID and path reported.

The difference between a demo that works once and a system you can rely on is the system prompt.

Part 3 — Context Window Management

The agent's memory is finite

The Finite-Window Problem

A large context window sounds endless — until it isn't.

Five searches × ~3,000-word results = ~15,000 tokens in tool output alone.
Add the system prompt, history, and reasoning, and a long run can hit the wall.

You need a strategy for what to keep, summarise, and drop.

What to Keep, Summarise, Drop

Content Decision Why
System prompt Always keep (uncompressed) lose it → the agent forgets who it is
User's original goal Always keep lose it → the agent drifts
Last 1–2 tool results Keep the inputs to the next reasoning step
Older tool results Summarise, drop raw keep the one-line signal, drop the JSON
Old reasoning / scratchpad Summarise, drop keep the decision, drop the deliberation
Final outputs (IDs, files) Keep as compact list so the agent doesn't repeat work

The Compression Rule

One sentence you can apply to any tool result:

"After each tool call: extract the 1–3 key facts you need next,
state them in one sentence, then treat the raw result as dropped."

  • Back to Lab 2: search_entries' 200-char preview is this rule in code — the server pre-compresses before data enters context.
  • Forward to Lab 3: add to the prompt — "Summarise each tool result to one sentence before proceeding." It cuts hallucination and drift.

(Aside: if context truly fills, the oldest content is silently truncated — which can drop a system prompt placed only at the start. Short prompts avoid this in the labs; production frameworks manage it.)

From Managing the Window → Engineering the Context

Managing the window is defensive. The offensive skill is context engineering — deciding what to put in front of the model in the first place. Six kinds of context:

  • Instructions — role, goals, hard limits (your system prompt)
  • Knowledge — docs, schemas, the data it reasons over
  • Memory — session state + persistent project facts
  • Examples — reference patterns, few-shot
  • Tools — the MCP tools, and when to call each
  • Guardrails — constraints, output format, safety

The question stops being "how do I prompt this?" and becomes
"what would a new teammate need to know — and how do I encode it?"

Static vs Dynamic Context

Where context lives is a real design decision:

Static — always loaded Dynamic — loaded on demand
What rule files, persona, global memory Skills, tool results, fetched docs
Cost every token, every turn you pay only when needed
Risk too much → diluted signal too little → the agent forgets
  • Rule files are the static spine: CLAUDE.md · project-context.md · AGENTS.md — the emerging cross-tool name for the same idea (your BMAD constitution, tomorrow).
  • Skills are dynamic context — procedural knowledge pulled in only when the task triggers it.

Most "the agent is dumb" moments are really context failures, not model failures.

Part 4 — The Five Failure Modes

Not bugs — design gaps

Every failure mode is predictable. Your job, before writing a single tool call,
is to decide which ones your system could hit — and add a guard for each.

The Five Modes & Their Guards

Failure mode What it looks like Guard
Tool hallucination claims a tool result it actually invented "Call the tool for live data. Do not infer or guess the result."
Infinite loop calls the same tool over and over, never finishing "At most N tool calls. If not done by N, summarise and stop."
Context blowout fills the window with raw outputs, no room to reason "Summarise results as you go. Don't retain raw data."
Off-task drift starts right, then wanders to a related task "Your task is exactly [X]. Do not expand scope."
Premature stopping stops after one call, reports partial as done "Complete only when [explicit criteria]. Don't stop before."

Anchor each to something you already saw in Lab 1 or 2 — you've met most of these.

The Universal Guard Block

Five lines to add to the [CONSTRAINTS] of any agent prompt:

# Guards
- Do not infer tool results from training data — call the tool.   (hallucination)
- Complete in at most [N] tool calls, else summarise and stop.    (infinite loop)
- Summarise each tool result in one sentence; drop raw data.      (context blowout)
- Task is exactly [one sentence]; do not expand scope.            (off-task drift)
- Complete only when [explicit criteria] are met.                 (premature stop)

These five are your safety net. Lab 3 makes you write all five — then break the pipeline to see what each one prevents.

Part 5 — Your Pattern Reference Card

Three decisions before Lab 3

Take 90 seconds. Write down:

  1. Which pattern will you use in Lab 3? (ReAct, Plan-and-Execute, Reflection)
  2. What is your max_steps limit?
  3. What is your explicit completion criterion — the exact condition for "done"?

These three answers are the core of your Lab 3 system prompt.
If you can't answer all three, get help before Lab 3 starts.

Anchor This

A pattern tells the model which loop to run.
The four-section prompt is its constitution.
Context management keeps its memory usable.
The five guards stop the predictable failures.

Lab 3 isn't a new challenge — it's everything from today, assembled into one prompt.

References

  • The New SDLC With Vibe Coding — Osmani, Saboo, Kartakis (Google, 2026) · context engineering, static vs dynamic context
  • ReAct — Yao et al. 2022 · arxiv.org/abs/2210.03629
  • Reflexion — Shinn et al. 2023 · arxiv.org/abs/2303.11366
  • Plan-and-Solve — Wang et al. 2023 · arxiv.org/abs/2305.04091
  • Anthropic — "Building effective agents" · anthropic.com/research/building-effective-agents