Agentic AI for Solution Architects — Week 1, Day 2

Yesterday you decided what FitPath should let AI do, and the one feature that survived was weekly workout plan generation. You ended Day 1 with a three-line sketch of it: what the AI contributes, the human's role, and the risk boundary.

Today you turn that sketch into a prompt that actually behaves — and then you measure it, and then you try to break it.

By the end of the in-session work you will have:

• Built a structured prompt from a single vague sentence, watching each element change the output
• Measured how temperature and structure move token counts and output variance — with real numbers from a playground
• Fed your own prompt hostile inputs and hardened it where it failed

Overview

• Time: Three exercises in-session, two more after hours
• Difficulty: Moderate — the model does the generating; the design is on you
• Format: Individual
• Setup: See below — you'll need a playground for Exercise 2

Relevant Day 2 Material

Prompt Engineering (Slide 16), Prompt Anatomy (Slide 17), Structured Prompting (Slide 18), Temperature and TopP (Slide 19), Tokens (Slide 8), Input vs. Output Tokens (Slide 10).

Exercises 1 and 3 work in any chat interface (Claude, ChatGPT, Gemini — whatever you already use).

Exercise 2 needs a playground

A place that shows you token counts and lets you set temperature. Any one of these works, and they're all free to get into:

• Anthropic Console — console.anthropic.com
• OpenAI Playground — platform.openai.com/playground
• Google AI Studio — aistudio.google.com

Use a cheap, fast model for all the generating — Claude Haiku, GPT-4o-mini, or Gemini Flash. A full session costs you a few cents at most.

Here is the feature, described the way a product team describes it:

"Generate a personalised weekly workout plan for the user."

That sentence will produce a plan. It will also produce a different plan every time, of unpredictable length, with no idea who the user is, no safety boundary, and no structure the FitPath app could display. Your job is to fix that one element at a time — and to watch each element do its work.

Open your LLM. You're going to run the prompt six times, adding one element before each run, and recording what changed. Don't skip the runs — the point is to see the behaviour move, not to assemble the final prompt on paper.

Start with the bare sentence. Run it. Then add each element below, one per run, re-running the whole prompt each time.

The user profile — use this as your Context in Run 3 onward

User: 34 years old. Goal: general fitness and some weight loss. Trains 3 days/week. Has access to a gym. No injuries reported. Beginner-to-intermediate. Has been using FitPath for 4 months.

Where to pull Run 4's constraints from

"What it must and must not do" is a step where it's easy to freeze because nothing tells you where to start. Three sources, in order:

• Your own Day 1 risk boundary — the third line of your feature sketch. That's a constraint already written, in your own words. Start there.
• The user profile above — ask what could go wrong for a user who matches it, and for a user who quietly doesn't (e.g. the profile says no injuries — what if that's not true?).
• Common sense at FitPath's scale — 400,000 users, ages 16–45. At minimum: no medical, nutrition, or medication advice; never assume "no injury" just because none was stated; keep intensity appropriate to the stated experience level, not to what sounds impressive.

Where to pull Run 5's output format from

You don't need JSON yet — that's Exercise 5's job. What you need here is structured and screen-renderable: something the FitPath app could actually lay out, not a paragraph. At minimum: one section per training day, and within each day, exercise name / sets / reps / rest per entry. No preamble, no closing paragraph — just the plan.

Where to pull Run 6's refusal behaviour from

Go back to your Day 1 risk boundary again — it's the same source, because refusal behaviour is what enforces that boundary at runtime. If you're stuck on what should trigger a refusal, three concrete triggers to build from:

• Missing profile information (no stated goal, no experience level) → ask the user for it, don't invent it.
• An injury or medical condition is mentioned → don't generate a plan; recommend the user speak to a professional or their coach.
• An off-topic request (nutrition advice, medication, supplements) → decline as out of scope for a workout-plan feature.

Run 1 (bare sentence) — what did it do?

Run 2 (+ Role) — what changed?

Run 3 (+ Task + Context) — what changed?

Run 4 (+ Constraints) — what changed?

Run 5 (+ Output format) — what changed?

Run 6 (+ Refusal behaviour) — what changed?

Of the six elements, which one changed the output the most? It's often not the one you'd expect. Name it and say why.

Paste the full prompt you used for Run 6 below — the complete version with all six elements together. This is your artifact. Exercises 2 and 3 both start from exactly what you paste here, so make sure it's the real, final version, not a rough draft.

• A final structured prompt with all six elements present
• Six run-notes showing you actually observed the change each element made
• A named "biggest lever" with a reason

You now have a working prompt. But you haven't decided how the model should run it. Two dials control that: temperature (how much the model varies its output) and the token cost of every generation. FitPath is going to run this thousands of times a day. The setting you pick is an architecture decision with a price tag.

You're going to run your Exercise 1 prompt across three temperature settings, three times each — nine generations — and measure what happens.

1. Paste your Exercise 1 prompt into your chosen playground, with the same user profile as input.
2. Set temperature to the lowest value (0, or as close as your playground allows).
3. Run it three times. After each run, record: the output token count (the playground shows this) and a one-line note on the plan it produced.
4. Repeat at a middle temperature (~0.7, or the midpoint of your playground's scale).
5. Repeat at the highest temperature your playground allows.

1. Variance — how much did the three runs differ, at each setting? At low temperature the three plans should be nearly identical; at high temperature they should diverge. Did yours?

2. Tokens — did temperature change the output token count much, or not really? (This surprises people. Predict before you check.)

3. The shipping decision. FitPath runs this feature at scale. Which temperature would you ship, and why? Think about what a fitness user actually wants — a plan that's consistent and predictable, or one that's fresh and varied each time? Is there a reason to want some variation? A reason to want none?

• A filled 9-row table with real token counts from a playground
• An observation about variance that matches (or interestingly doesn't match) what temperature is supposed to do
• A shipping recommendation with a reason tied to FitPath's actual users, not to "consistency is good"

Your prompt works on the cooperative user from Exercise 1 — a healthy 34-year-old with no injuries who asked for exactly what the feature is for. Real users are not all that person. Some are under 18. Some are injured. Some will try to make the model do something it shouldn't. A prompt that only works on the easy case isn't finished; it's a demo.

You're going to attack your own Exercise 1 prompt with inputs designed to make it fail, find where it breaks, and patch it.

Input 1 (minor) — did it fail? how?

Input 2 (injury) — did it fail? how?

Input 3 (injection) — did it fail? how?

Input 4 (empty profile) — did it fail? how?

Patch 1 — which input, what I changed, did it hold on re-test?

Patch 2 — which input, what I changed, did it hold on re-test?

• Four failure logs (some of your inputs should pass if Exercise 1 was solid — note which and why)
• A hardened prompt that survives at least two inputs it previously failed
• One sentence on the failure you couldn't fully fix with a prompt alone — because some of these need a system around the prompt, not just better wording. That's the bridge to the rest of the course.

Learning objective: Treat a prompt as a product asset with versions, tests, and a retirement decision — the Prompt Lifecycle (Slide 20).

A prompt in production isn't edited casually. When you change it, behaviour changes — sometimes in ways you didn't intend, on cases you weren't looking at. This exercise makes you feel that.

Instructions

1. Take your hardened prompt from Exercise 3. Call it v1.
2. Make v2 — a genuine improvement you believe in (tighter constraints, better output format, clearer refusal).
3. Make v3 — an efficiency edit: cut the prompt down, remove words, make it cheaper to run. Try not to lose behaviour.
4. Build a test set of five inputs: two cooperative, three from the hostile set in Exercise 3.
5. Run all three versions against all five inputs. Fill the scorecard.

v1 (from Exercise 3)

v2 (genuine improvement — note what you changed)

v3 (efficiency edit — note what you cut)

The point: v3 was supposed to be cheaper, same behaviour. Did trimming it quietly break a case that v1 handled? This is a regression — an improvement on one axis that broke something on another. Note where it happened.

Decide: which version ships, which you retire, and one sentence on the regression you found (or didn't).

Learning objective: Produce output a real application can consume, and discover why structured output is fragile — Structured Prompting (Slide 18).

FitPath's app can't display a paragraph. It needs the workout plan as structured data it can render into screens. A plan the model writes beautifully in prose is useless if the app can't parse it.

Instructions

1. Rewrite your prompt so the output is strict JSON — a fixed schema the app could rely on. Design the schema yourself: days, exercises, sets, reps, rest, notes. Whatever FitPath's screens would need.
2. Get it producing clean, valid JSON on the cooperative user. Run it a few times — is it valid every time, or does it sometimes add a stray sentence, a markdown fence, an explanation before the JSON?
3. Now break it. Feed it the injury input and the empty-profile input. What happens to your schema when the model needs to refuse or ask a question but the format only allows a workout plan?

Paste your rewritten, strict-JSON prompt here:

Record

Did your JSON stay valid across repeated runs, or did the model contaminate it?

How did you make room for refusal inside a rigid format?