Details

• Learning objective: Apply the value × feasibility use-case matrix to a realistic candidate list, sequence into build waves, name blockers on deferred items, and defend your sequencing against pushback that favors "coolest" or "biggest number" over evidence.
• Setup / materials: The candidate list below, the scoring template, your LLM playground.

Context

FitPath's leadership has ten agent ideas on a whiteboard and a budget for two. You're in the room. Score these eight candidates and tell them what to build first — and what to say no to.

The candidates

1. Support Ticket Triage & Draft Assistant — classifies inbound support tickets (billing, technical, cancellation, safety) and drafts a reply for a human agent to review before sending.
2. Adaptive Workout Plan Adjuster — automatically modifies a member's workout plan when the member logs pain, missed sessions, or a doctor's note, without a coach reviewing every change first.
3. Churn Prediction & Win-Back Agent — flags members likely to cancel and drafts a personalized win-back offer, pulling signals from usage logs, billing history, and support tickets stored across three separate systems.
4. Weekly Stats Report Formatter — takes a member's raw workout log data and reformats it into the standard weekly summary email, following the same template every time.
5. Motivational Caption Generator — writes a short, fun caption to go with a member's shared workout milestone photo on the community feed.
6. Corporate Wellness Partnership Negotiator — drafts and adjusts contract terms for gym-partnership deals with corporate wellness accounts, a handful of which close per quarter.
7. New Member Onboarding Q&A — answers new members' questions about the app (features, billing, cancellation policy) grounded in the current help-center articles.
8. Community Post Moderation Flagger — flags posts in the community forum that may violate content guidelines (harassment, unsafe medical claims, spam) for a moderator to review before removal.

Step 1 (10 min) — Score individually

For each candidate, score Value 1–5 and Feasibility 1–5 — this is the minimum of data readiness, risk manageability, and measurability, not the average. The weakest factor is binding. Write one line naming what's setting the feasibility floor (or ceiling) for each.

Step 2 (5 min) — Sequence

Sort into Wave 1 (build first), Wave 2 (deferred — name the specific blocker), or Declined (not viable — record why).

Step 3 (5 min) — Stress-test

Paste your scoring and sequencing into your LLM playground with the starter prompt below. Let it push back. Decide, in writing, where you're holding your ground and where it changed your mind — and why.

Where you're holding firm, where it changed your mind, and why

Success criteria

• All 8 candidates scored on both axes with a one-line justification for the feasibility floor.
• At least #2, #4, #5, and #6 correctly kept out of Wave 1 — each for a different underlying reason.
• #1 and/or #7 in Wave 1, or a clear written reason if not.
• #3 recognized as high-value-but-blocked → Wave 2, with the blocker named explicitly (data fragmentation).
• A written response to the LLM's pushback that holds a position on at least one contested item, with an actual argument — not just "the rubric said so."

Extension

For #3, write the one-paragraph brief you'd actually hand the data team: what's fragmented, across which systems, and what it would take to fix.

Details

• Learning objective: Build a full 8-category TCO and a defensible value case (baseline → proposed capability → cost/value ledger with haircut) for the agentic workout-plan generator you built on Day 4 — without letting "AI cost" collapse into "model cost."
• Setup / materials: Your own Day 4 artifacts (tool list, HITL approval design), the templates below, your LLM playground.

Context

Your Day 4 agent works. Now you have to defend taking it to production in front of people who control budget. Recall your build: the workout-plan generator, its read/write tools, LangSmith Fleet, per-tool human-in-the-loop approval.

Step 1 — TCO (15 min)

Fill in one line per category. Assume production scale: ~500 FitPath members using it weekly. No category may be left blank — if you think it's near-zero, say why in the line.

Step 2 — Value case

Business problem & target users

Current baseline & proposed capability — state the capability in maturity-ladder terms (e.g. "M2 tool-using agent in approval mode")

Risk & ownership

Success metric, with a baseline number

How to calculate the value (time-saved mechanism)

For example: 6 min saved per check-in × 500 members × 50 weeks/year × €0.50/min ≈ €75,000/year.

Every input here should be a real or clearly-labeled-as-assumed number — the baseline and target minutes, the €/minute cost, the frequency. If you can't defend one of them, say so explicitly rather than letting it hide inside the total. Then name the conversion route for that saved time (headcount avoidance / capacity redeployed to something else / throughput increase) — a value figure with no route named is the "10,000 hours saved" trap the material warns about.

Your calculation — each input, and whether it's real or assumed

Conversion route for the saved time (headcount avoidance / capacity redeployed / throughput increase)

The ledger

One-line honest verdict — breakeven, needs a cheaper build, clears comfortably, etc. Not "5x ROI."

Step 3 (8 min) — Stress-test

Take your draft to your LLM playground with the prompt below.

What you revised after the stress-test, and what you'd missed

Success criteria

• All 8 TCO categories populated with a real estimate or an explicit, justified near-zero.
• Model usage is not the largest line item unless you've stated a specific reason it should be.
• Value case names a concrete conversion route for any time-saved claim.
• Ledger shows both the 100% and 50%-haircut figures, with an honest verdict.
• At least one category revised after the LLM stress-test, and you can say what you'd missed.

Extension

Rerun the ledger at 5,000 members instead of 500. What changes non-linearly? (Hint: not just the value side.)

Details

• Learning objective: Run the four-question discovery funnel against a stakeholder who deflects on specifics, and land on a defensible readiness verdict — without getting talked into scoping a pilot that isn't ready.
• Setup / materials: Your LLM playground, the starter prompt below, the discovery brief template.

Context

You're in discovery with Priya Shah, VP of Growth at FitPath. She wants a churn-prediction and win-back agent built fast. Your job: run the four discovery question pairs and land on a verdict — pilot-ready, or name the specific readiness workstream that has to happen first.

You will not get a clean, well-instrumented answer. That's the point.

Step 1

Paste the starter prompt below into your LLM playground exactly as written. Don't show it your template or coach it.

Step 2 (15 min)

Run the conversation. Ask your four question pairs:

• What business outcome matters, and what workflow is painful today?
• What is the current baseline — what data and actions are needed?
• What risk must be controlled — who owns the outcome?
• How will success be measured — what metric proves the value?

Push for specifics at least twice when you get a vague answer. Don't accept the first deflection.

Step 3 — Discovery brief

Fill in your discovery brief with what she actually said — including the vague parts; the vagueness is itself a finding. Write your verdict: pilot-ready or not, and if not, name the specific readiness workstream and why, in one paragraph.

Business outcome & painful workflow — what she actually said

Current baseline — data and actions needed — what she actually said

Risk & ownership — what she actually said

Success metric — what she actually said

Verdict — pilot-ready or not, and if not, the specific readiness workstream and why

Success criteria

• Discovery brief has content in all four blocks, with vague/deflected answers captured as they were actually given — not smoothed into something more concrete than what was said.
• You pushed for specifics at least twice rather than accepting the first vague answer.
• Verdict is explicit — not "maybe" or "it depends" — and names a specific workstream if not pilot-ready (e.g. "baseline instrumentation on churn rate and its drivers," not just "needs more data").
• The verdict paragraph references something the stakeholder actually said.

Extension

Rewrite your "not ready yet" response as the exact sentence you'd say out loud to Priya — one that sounds like progress, not a block.