Two pieces of a working agent are on your desk. Part 1 left you with a system instruction. Part 3 left you with a context file. The third — nobody tells you how to build it because you don't write it. You iterate to it.
Part 4 of a five-part series. Part 1 covered what an agent is, Part 2 where to place your first, Part 3 built the client context file. This piece assembles all three.
Three components
A working agent is three things. The instruction tells it what to do — Part 1's five components. The context tells it what to know — Part 3's ten fields. The example shows it what good looks like.
The first two you bring. The third is where most practitioners stall — every guide says they need one, most don't have one, and a bad example is worse than no example at all.
Why examples are tricky
Examples do real work — they anchor format, tone, and judgment in ways rules can't. They also handcuff: a mediocre example pulls every output toward that mediocrity, and the wrong choice gets reproduced with confidence. The question isn't whether to use one — it's where a good one comes from.
Some examples you inherit. Most you build.
Some examples you inherit. Engagement letters carry limitation-of-liability clauses your insurer demands. Tax representation letters have regulator-prescribed wording. Compilation and review reports have language that isn't optional. The example acts as a constraint — feed in the template, preserve required language verbatim, iterate around it.
Most agent work in a CAS practice isn't template-bound. A client email lives or dies on tone. A monthly summary, tax notice response, or year-end planning brief is judged on what it surfaces and what it skips — judgment no rule fully describes. Iteration earns its keep here.
Walking it through — the document chase
The mechanic is short. Assemble the instruction and the context, skip the example, run.
The first output will be 70 to 80 percent right — don't fix the output. Fix the instruction or the context, then run again. Two or three rounds is usually enough, and the output that's finally what you'd send is your example.
Take last week's exercise client. Mine is Glendale Brewing — Mike Jensen, owner, prefers email, signs off short, hates the word "kindly." The doc-chase email is the first item off my Z1 list. Here's the instruction, built around Part 1's five components:
Identity: You are a senior bookkeeper at our practice. Your job: draft the month-end document-chase email to Mike Jensen at Glendale Brewing.
Context: The attached client context file. The list of outstanding items will be pasted in when this runs.
Rules: Warm and brief tone. Reference any items outstanding from the prior month. Sign off as Peter.
Output: A complete email asking Mike for the outstanding items, ready to send.
Contingency: Ask before drafting if no outstanding list is given.
No example attached. I paste in this month's outstanding list and run it.
Run one. A polite, generic email asking Mike for "documents required for the monthly close." Structurally fine but doesn't sound like me. Doesn't reference last month's outstanding items. Uses "kindly."
I edit the instruction, not the email. New rules: reference last month's outstanding items by name; never use "kindly." New contingency: flag if last month's chase was ignored.
Run two. Mike's name is there, prior-month items listed, tone is closer. The close is still corporate — "Please don't hesitate to reach out."
I update the context file: "Mike signs off short, doesn't do warm closes."
Run three. The output is the email I would have written. Six minutes total.
Recompile and save
Three rounds in, the instruction has rules added inline, a context edit, and an output worth keeping. I ask the LLM to consolidate:
"Rewrite this as one clean reusable instruction. Organize the rules and contingencies, include the run-three output as the example, drop our iteration history."
I check the rewrite, name it Glendale Brewing — Doc Chase, and save it wherever my tool keeps projects, custom GPTs, or saved prompts. Next month, the agent starts from that standard, not zero.
Note the pattern: two of three rounds were tone fixes — no "kindly," no warm closes. A firm-wide tone-of-voice profile catches those upstream, once, instead of three times per client. The companion piece walks the build.
Try this now — 30 minutes, one Z1 item
Pick one Z1 item from your Part 2 backlog. Build the instruction (Part 1's five components) with an explicit task. Attach the context file. Run without an example, and fix the instruction or the context — not the output — until the output is what you'd send. Recompile, name it, save it.
One agent. Three pieces. The next step is what makes it matter.
You have a working agent. One piece brought, one built last week, one iterated into existence today.
Three things change once an agent exists. It persists across time — saved, named, opened next month. It persists across clients — swap the context file, same instruction, next name on your book. It persists across workflows — chain with others and what you can deliver shifts. Part 5 walks through all three.