Where we are in the arc
Sessions 1-5 taught you to write one excellent call: clear, structured, grounded, cache-shaped. Session 6 is the phase change. First we stop pretending one call should do everything and learn to chain. Then we let the model act - call tools, observe results, decide what to do next - and learn what that does to your prompts. TriageBot gets hands today.
Chaining: many small prompts beat one giant one 5 min live
Prompt chaining is the simplest idea in this session: the output of one call becomes the input of the next. Anthropic's docs push it for accuracy on multi-step work, and Gemini's docs teach the same move as decompose-and-aggregate: break the task down, run the pieces, merge the results. Each link does one job, so each link can be tested, cached, and fixed on its own.
LiveThe self-correction pattern3 min▶
The highest-value chain is only two links longer than what you already have. Anthropic's docs describe it plainly:
- Draft: the call you have today produces its answer.
- Review with a rubric: a second call gets the draft plus explicit criteria ("check the quote is verbatim, the category is one of the allowed five, the JSON validates") and returns a pass/fail per criterion.
- Refine: a third call gets the draft plus the review notes and fixes only what failed.
Why not just tell the first call "double-check your work"? Because a fresh call has no attachment to the draft. Reviewing your own answer in the same context is like grading your own exam with the answers already written in your handwriting.
LiveWhen to chain, when one call is fine2 min▶
| Stay with one call | Chain it |
|---|---|
| One task, one output shape | Distinct sub-tasks with different skills (extract, then judge, then write) |
| Accuracy already meets the bar | Errors compound mid-task and you cannot see where |
| Latency or cost budget is tight | You need to test, cache, or fix one step without touching the rest |
| The model handles it reliably in evals | Different steps want different context, models, or effort levels |
Chaining costs latency and money - every link is a round trip. The discipline: chain when a step is measurably failing, not because diagrams look impressive. Modern models handle much more in one call than 2023 folklore suggests.
Meridian's data team split TriageBot's "summarize the week's tickets" report into decompose-and-aggregate: one call per store's tickets, then one call to merge the 80 mini-summaries. Accuracy jumped and the merge call became the only prompt they ever needed to tune.
Prompting agents: what changes when the model can act 8 min live
A chain is choreography you wrote. An agent chooses its own next step: it gets a goal and tools, then loops - plan, call a tool, observe the result, reflect, repeat. Your prompt stops being a request and becomes a policy: how hard to persist, when to use tools, when to stop.
LiveThe three reminders that fix most flaky agents (GPT-4.1 guide)3 min▶
OpenAI's GPT-4.1 prompting guide found that three system-prompt reminders transform agent reliability. In spirit:
- Persistence: "You are an agent - keep going until the user's request is completely resolved before ending your turn. Do not stop at the first uncertainty."
- Tool-calling: "If you are not sure about facts you can look up, use your tools. Do not guess or make up an answer."
- Planning: "Plan before each tool call and reflect on the result of the previous one - do not chain silent tool calls with no thinking in between."
They read like management advice because they are: finish the job, check instead of guessing, think between actions. Models tuned for agentic work default toward chat-style politeness (stop early, hand back to the user); these reminders flip the default.
LiveEagerness: a dial you turn in both directions (GPT-5 era)3 min▶
Newer agentic models made the opposite failure common: too much persistence. The GPT-5 guidance calls the dial agentic eagerness, and you calibrate it both ways in the prompt:
| Agent gives up too early | Agent rummages forever |
|---|---|
| Add persistence clauses: do not hand back on uncertainty, make the most reasonable assumption and note it | Add early-stop criteria: "as soon as you can name the order status, stop looking things up" |
| Tell it not to ask permission for steps inside its mandate | Set tool budgets: "at most 2 lookups per ticket, then route to a human" |
Same era, second habit: tool preambles. Ask the model to restate its plan before the first tool call and narrate progress between calls. Costs a few tokens, buys you debuggable transcripts and fewer silent wrong turns.
LiveAnthropic's agentic playbook: state, action defaults, honesty tags3 min▶
Anthropic's best-practices docs have a whole agentic section. The pieces you will reuse constantly:
- Long-horizon state: for work that outlives one context window, tell the agent to keep progress notes in a file it updates as it goes, and to use git commits as durable checkpoints - the context window is working memory, not storage.
- Action defaults: named snippets set the posture.
<default_to_action>for agents that should just do the thing;<do_not_act_before_instructions>for agents that must wait for explicit direction. Pick one deliberately. - Parallel tool calls:
<use_parallel_tool_calls>- when reads are independent, fire them together instead of one by one. - Anti-hallucination:
<investigate_before_answering>- never claim a file, record, or fact exists without having looked at it in this session. - De-escalate the shouting: older prompts full of CRITICAL and MUST in all caps make modern Claude models overtrigger on those rules at the expense of everything else. State rules once, calmly, and reserve strong language for the one rule that genuinely is critical.
Self-studyGemini's 9-point agentic system-instruction framework2 min read▶
Google's Gemini agentic guidance arrives as a framework: nine sections a serious agent system instruction should cover. Paraphrasing the categories:
- 1 Role - who the agent is and what it owns. 2 Objective - what done looks like. 3 Instructions - the behavioural rules. 4 Workflow - the planned sequence of steps. 5 Tool guidance - which tool for what, and what not to touch. 6 Context - the environment and data it operates in. 7 Constraints and escalation - hard limits, and when to hand to a human. 8 Output format - the shape of the final answer. 9 Examples and reminders - a worked case plus the rules worth restating at the end.
Notice how much this overlaps the GPT-4.1 template from Session 2 and Anthropic's agentic sections above. Three vendors, one converged shape: role, rules, tools, limits, format. That convergence is next session's whole subject.
Tool descriptions ARE prompts 4 min live
Here is the most under-engineered prompting surface in production systems: the tool spec. Teams agonize over the system prompt, then describe their most important tool as "looks up orders". The model chooses tools by reading those descriptions - they are prompts, and they deserve the same craft.
LiveWhat a well-engineered tool spec contains2 min▶
- Name: a verb phrase the model can reason about -
lookup_order, notsvc_call_3. - Description: what it does, what it returns, and its limits, written for a reader with zero backend knowledge.
- When to use it: the trigger conditions, concretely ("the ticket mentions an order and status affects routing").
- When NOT to use it: the anti-triggers - the missing half in most specs, and the main cause of both tool spam and tool neglect.
One more GPT-4.1 finding with teeth: pass tools through the API's tools field, not by pasting descriptions into the prompt text. Models are trained on the structured format; in OpenAI's testing, using the tools field improved performance and hand-injected descriptions underperformed. Same message from every vendor: let the API carry the spec.
Self-studyReAct in one honest paragraph1 min read▶
ReAct (Yao et al., 2022) taught models to interleave Thought / Action / Observation as literal text you parsed with regex, and for a year every agent tutorial made you hand-roll that loop. As a prompt technique it is dead: native tool calling won, the models are trained for it, and nobody should be parsing "Action:" lines in 2026. As an architecture it is immortal - plan, act, observe, reflect is exactly the loop running inside Claude Code, Gemini's agent stack, and every harness you will ever use. Honor it as lineage; do not hand-roll it.
TriageBot v4: it gets hands ★ 22 min · build it with me
TriageBot v3 (Session 5) classifies tickets into schema JSON, grounded in the policy manual with quote extraction, cache-shaped. Its blind spot: refund routing depends on order status, which it can only guess at. v4 gets one tool - lookup_order - and the agentic rules to use it well.
Write the tool description first. Name, description, when to use, when NOT to use. Draft it before touching the system prompt - if the spec cannot explain the tool to a colleague, the model has no chance.
Add the three agentic reminders to the system prompt: persistence (finish the triage), tool-calling (do not guess order status - look it up), planning (reflect after each result).
Add the early-stop rule. Max 2 lookups per ticket; if status is still unclear, route to a human with needs_human: true. Eagerness calibrated in both directions: it must look, and it must stop.
Dry-run a refund ticket on paper. "Order MR-88231 never arrived, refund me." Walk the loop: what does it look up? Suppose the tool returns status: delivered, signed_by: neighbor - how does the final JSON change? (Category shifts from refund to delivery-dispute, and the evidence field cites the tool result.)
Add the preamble rule. One line of plan before any tool call. Now your logs read "Checking order status because the customer claims non-delivery" instead of a bare function call - future-you debugging at 5pm will be grateful.
tools parameter as structured JSON. It is shown here so you can see the whole prompting surface in one place - system prompt and tool spec are one design, split across two fields.
Three things before Session 7 ◐ 30 min total
- Chain something you own. Take one prompt that does two jobs at once and split it: draft call, review-with-rubric call, refine call. Compare against the single-call version on 5 real inputs.
- Audit one tool spec in any agent you use or build. Does it say when NOT to use the tool? Rewrite it with all four ingredients and note what the agent does differently.
- Dry-run TriageBot v4 on two more tickets: one where the lookup changes the routing, one where the early-stop rule should fire (order number malformed, both lookups fail). Write down the expected JSON for each - these become eval cases in Session 8.
What this session covers
Builder-level coverage of the sources below. Official docs and guides stay with the vendors; links live in the course map.
Three questions before you go 🎯 ◐ 90 seconds
1 · The GPT-4.1 guide's three agentic system-prompt reminders are...
Finish the job, check instead of guessing, think between actions. Three sentences in the system prompt that flip a chat-tuned model into a reliable agent.
2 · Your agent keeps looking things up long after it has the answer. The eagerness fix is...
Eagerness is a two-direction dial. Under-eager agents need persistence clauses; over-eager agents need explicit stop criteria and budgets. This one is over-eager.
3 · The most under-engineered prompt surface in most tool-using systems is...
The model chooses tools by reading their descriptions, so they are prompts. Pass them through the API's tools field - and never hand-roll ReAct text loops in 2026.