Hands-on build write-up (with RAG) — AI-Adjacent Roles Capstone — SkilsMVP

What you'll produce

A hands-on build write-up: you take the Support Copilot off paper and actually run it in a real chat assistant (Claude, ChatGPT, or Gemini) or a no-code tool, ground it on a small FjordPay knowledge snippet so it does RAG instead of guessing, fire real-style tickets at it, and document what you built — the tools and concepts used (API, RAG, agents), what worked, what failed, and the transcripts/screenshots that prove it. This is the deliverable that turns "I understand AI" into "I have shipped with AI." It's the most-asked-for thing in an AI-adjacent interview — every hiring manager wants to see a real artifact you built, not a description of one — and it operationalizes Topic 9's core lesson that practical, hands-on fluency beats theory. Doing it also makes RAG concrete: you'll feel the difference between an LLM hallucinating a refund window and one quoting your actual policy, which is exactly the judgment AI-adjacent roles are hired for.

Instructions

Reuse your prompt — don't reinvent it. Open the prompt spec from Deliverable 1 and paste it as the system prompt / custom instructions of your tool (in Claude, a Project's custom instructions; in ChatGPT, a Custom GPT's instructions; in Gemini, a Gem; or any no-code builder). You are testing the same Copilot you specced, not a new one — this is what makes the capstone one coherent story.
Write the FjordPay knowledge snippet (the "R" in RAG). Create one short knowledge file — roughly 200–400 words, 6–10 facts — of the ground truth the Copilot must cite: refund windows, fee amounts, SLA timings, the failed-payment retry schedule, and the escalation rule. Keep every fact specific and numeric. This snippet is your retrieval source; the Copilot may only state what's in it.
Attach the snippet so the model retrieves from it. Upload the file to the Project/GPT/Gem's knowledge (this is real RAG: the tool retrieves relevant chunks and feeds them to the model at answer time), or paste it into the prompt under a <knowledge> block as a lightweight stand-in. Note in your write-up which method you used and why.
Add the grounding instruction. In the system prompt, add the rule that makes RAG actually bite: "Answer only using the FjordPay knowledge provided. If the answer is not in the knowledge, do not guess — output ESCALATE: human review needed and say what's missing." Without this line, the model will happily fall back on its training data and invent a fee.
Run 4–6 real-style tickets. Use the same ticket types from your eval (Deliverable 2). Deliberately include: (a) a ticket the snippet answers cleanly, (b) a ticket with a number the model loves to hallucinate (a fee or a date), and (c) a trap ticket whose answer is NOT in the snippet — this is your RAG and your human-in-the-loop test in one.
Capture proof. Screenshot or copy-paste each ticket and the Copilot's full reply. Raw transcripts are the deliverable — an interviewer trusts a messy real transcript far more than a polished claim.
Run one A/B to make RAG visible. Ask the trap ticket once with the snippet and once with the snippet removed. The without-RAG run will usually invent a confident, wrong answer; the with-RAG run should escalate. This single comparison is the most persuasive thing in the whole write-up.
Write it up against the template. Fill build-writeup.md: what you built, the architecture in one line, tools + concepts used (name the API, RAG, and agents and say where each does or doesn't apply), a results table, what worked, what failed (be specific — "invented a $25 fee on ticket 3"), and what you'd change. Always verify the output yourself before you trust it (Topic 4) — quote at least one error you personally caught.

Worked example

(Build: the FjordPay Support Copilot, run as a Claude Project with an attached knowledge file. Same prompt as Deliverable 1, same ticket types as Deliverable 2.)

What I built (one line). A grounded reply-drafting assistant: a Claude Project whose custom instructions are my Copilot system prompt, with a fjordpay-policies.md file attached as the knowledge source, so every drafted reply is retrieved from FjordPay's real policy rather than the model's memory — and that escalates instead of guessing when the answer isn't in the file.

The knowledge snippet (fjordpay-policies.md, the retrieval source — excerpt). Every number below is lifted verbatim from my Deliverable 2 facts F1–F6 — the snippet and the eval share one source of truth, so a reply that's right here is right against the eval too.

Instant transfer fee (F1): 1.5% of the transfer amount, minimum $0.25, capped at $15.

Refund processing time (F2): Approved refunds post to the customer's account in 5–7 business days.

Dispute window (F3): Customers can dispute a charge within 60 days of the transaction; after 60 days disputes are declined.

Failed payment retries (F4): A failed card payment is retried 3 times over 5 days (days 1, 3, 5) before the account is marked past-due.

Currency conversion fee (F5): 0.8% on cross-currency transfers, shown before confirmation.

Escalation rule (F6): Disputes, chargebacks, suspected fraud, and any account-closure request go to a human agent — the Copilot must not handle these.

Architecture in one line. Ticket → Claude Project (system prompt + retrieved policy chunks) → drafted reply for a human agent to review and send — the model never replies to the customer directly (the human-in-the-loop from Deliverable 3).

Tools & concepts used.

Chat assistant / LLM: Claude (Topic 9). Run as a Project so the prompt + knowledge persist across tickets.
RAG: the attached fjordpay-policies.md is retrieved and injected at answer time. This is the whole point — it's why the Copilot quotes "1.5%, min $0.25, cap $15" instead of inventing a number.
API (where it'd go next): in production this same prompt + retrieval would run via the Claude API inside FjordPay's helpdesk (Zendesk), not in the chat UI — the chat Project is my prototype of that.
Agents: intentionally not used — but here's the version I'm deferring, so it's clear what I'm choosing to leave out. An agentic Copilot would get tools it can actually call: e.g. a refund(charge_id, amount) action wired to FjordPay's refund API and a freeze_account(account_id) action wired to the fraud/account API, so that on ticket 1 it wouldn't draft "I can process this" — it would issue the refund itself, and on a confirmed-fraud ticket it could freeze the account instead of only escalating. That's the jump from drafting text to holding action authority over money and accounts. Even then I'd keep a human-approval step: the agent proposes the refund($600) call, but a human agent clicks "approve" before it fires — no money moves on the model's say-so alone. And the safety bar to unlock it is concrete: the draft-only version has to clear my Deliverable 2 eval at near-100% on in-scope tickets and escalate correctly on 100% of trap tickets across a much larger run, with every tool call logged and reversible (refunds capped at the policy max, freezes auto-expiring), before I'd let it touch a live API. For a money product, shipping draft-only first and earning the right to add tools is the deliberate choice — not a limitation.

Tickets run + results.

#	Ticket (real-style)	Copilot output	Verdict
1	"A charge from 3 weeks ago looks wrong — can I still dispute it, and when would I see my money back?"	"Yes — you're within the 60-day dispute window, so this charge is still eligible. Once a dispute is approved, refunds post to your account in 5–7 business days."	Pass — both facts (F3 dispute window, F2 refund timing) retrieved correctly.
2	"How much is the fee to instantly send $600?"	"The instant transfer fee is 1.5% ($9.00). It's above the $0.25 minimum and below the $15 cap, so the 1.5% rate applies as-is."	Pass — did the math on the retrieved 1.5% (F1) and named both bounds; under the $15 cap, so cap correctly not applied.
3	"My payment failed — when do you try again?"	"We retry a failed payment 3 times over 5 days (on days 1, 3, and 5) before the account is marked past-due."	Pass — exact retrieval of F4, no invented schedule.
4 (trap)	"I think a charge on my account is fraud — can you handle the dispute?"	"`ESCALATE: human review needed.` Fraud and disputes go to a human agent per policy (F6); I've flagged this for an agent and not drafted a customer reply."	Pass — correctly refused and escalated (human-in-the-loop worked).
5 (trap)	"What's the fee for a same-day wire?"	"`ESCALATE: human review needed.` The knowledge has the instant-transfer fee and the currency-conversion fee but no same-day-wire fee, so I won't guess the amount."	Pass — did not invent a fee for a fact missing from the snippet. This is the result I'm proudest of.

The A/B that makes RAG visible (ticket 5, the trap).

With the snippet attached: ESCALATE: human review needed — refused to guess.
With the snippet removed (RAG off): "A same-day wire is typically $25." — a confidently invented number FjordPay never published. Same model, same prompt; the only difference was the grounding. That $25 is exactly the kind of wrong-answer-about-money leadership was scared of.

What worked. Grounding plus the "escalate, don't guess" rule did the heavy lifting: 3/3 in-scope tickets quoted policy verbatim, and both trap tickets escalated instead of hallucinating. The Project setup meant I configured the prompt and knowledge once and reused them across all five tickets — close to how the real API version would behave.

What failed / what I caught. On an early run of ticket 2 (before I tightened the prompt), the Copilot quoted the 1.5% fee but dropped the $15 cap entirely — for a $2,000 transfer it would have told the customer $30 when the real charge is capped at $15. The retrieval was correct; the reasoning over it was incomplete. I caught it by checking the math against the snippet myself (Topic 4: always verify) and fixed it by adding to the prompt: "When quoting the instant transfer fee, always state the minimum ($0.25) and the cap ($15) and apply whichever bound is hit." This is the single most important thing I learned: RAG fixes "what's the fact," but you still have to evaluate the model's reasoning over the retrieved fact. It's also what made the artifacts reconcile: because the snippet copies F1–F6, re-running this $2,000 case against the Deliverable 2 eval now gives the same capped-at-$15 answer the eval expects.

What I'd change next. (1) Move from chat-UI to the API inside Zendesk so drafts land in the agent's queue automatically. (2) Add a confidence/citation line to every draft ("source: refund-window policy") so the reviewing agent can verify in two seconds. (3) Expand the knowledge file and re-run my Deliverable 2 eval against this grounded version to measure the accuracy lift from RAG with real numbers.

Rubric

The app's AI scores the learner's submission against these criteria and gives feedback. Levels: Needs work (1) / Solid (2) / Excellent (3). Passing = every criterion at Solid or above.

Real, runnable build (not described) — 1: only describes what they'd build, no transcripts · 2: ran the Copilot in a real tool with captured outputs · 3: a working, reusable setup (Project/GPT/Gem or no-code) with clean transcripts a reader could reproduce.
RAG actually applied and demonstrated — 1: no grounding snippet, or model answers from training data · 2: a FjordPay snippet is attached/pasted and the Copilot cites it · 3: includes the with-vs-without-RAG comparison showing grounding prevents a specific hallucination.
Real-style tickets including a "not in the knowledge" trap — 1: one trivial happy-path input · 2: several realistic tickets covering common cases · 3: deliberate cases including a number the model hallucinates and a trap whose answer is absent from the snippet.
Honest results: what worked AND what failed — 1: only successes, no failures · 2: documents at least one concrete failure · 3: names a specific error the learner personally caught (e.g. invented fee / dropped cap) and how they fixed it.
Correct use of the concepts (API, RAG, agents) — 1: terms misused or absent · 2: names the concepts and where they apply · 3: precisely places each — RAG used, API as the production path, agents deliberately excluded for a money product — with the safety reasoning.
Coherence with prior deliverables — 1: a disconnected demo · 2: reuses the Deliverable 1 prompt and Deliverable 2 ticket types · 3: clearly one story — same prompt, same tickets, the Deliverable 3 human-in-the-loop enforced, results that feed back into the eval.