You use these tools every day, so the six-part anatomy is not news. This is the
layer under it: the structural model the labs actually build from, which runs
augmented LLM → orchestration → evals. We take the loop apart until you can see where
the money goes, decide single-agent versus multi-agent on task shape instead of vibes, read
what MCP standardizes at the wire, and measure whether a change made the agent better or just
different. Sourced end to end from Anthropic, OpenAI, Google, and the MCP spec.
Updated August 1, 2026Refreshed monthlySources: Anthropic · OpenAI · Google · MCP
Layer 01 · The block
Everything composes up from the augmented LLM.
Anthropic's whole framework starts from one primitive it calls the augmented LLM: a
model wired to three capabilities, retrieval, tools, and memory. That is the base block. Every
pattern above it, prompt chains, routing, parallelization, orchestrator-workers, and the full
autonomous agent, is composition on top of the same block. Nothing in this lesson is a new kind
of thing. It is that one block, arranged.
Reading the stack this way changes how you debug, because it tells you the layers are
separable. The model reasons. Retrieval decides what enters the context. Tools decide what the
model can touch. Memory decides what survives across turns. When an agent underperforms, you are
almost never looking at "the AI is bad." You are looking at one of those four attachments feeding
it the wrong thing, and each one is a different fix at a different layer.
Hold the three-layer model for the rest of this lesson. The block is the augmented LLM.
Orchestration is how you compose blocks into a loop, or into several loops. Evals
are how you know the composition is getting better instead of drifting. Build up, measure back
down.
The augmented LLM · the primitive everything else is built out ofLayer 02 · Orchestration
The loop is control flow, and every turn re-reads the desk.
Orchestration is the part that turns a static block into an agent: plan, act, observe, decide,
and loop until a stop condition. You know the shape. The part worth internalizing is the cost
model, because it is the single thing that most changes how you design a run. The loop is not
stateless. On every pass, the model re-reads the accumulated context: your instructions, the
running transcript, and the output of every prior tool call. Turn twelve carries turns one
through eleven.
That makes billed input tokens grow with the square of the turn count, not linearly. Ten turns
that each add 2,000 tokens is not 20,000 tokens of input. It is the running sum, 2,000 re-read
once, then twice, then ten times, which lands near 110,000. The compute compounds the same way,
which is why a wandering agent feels slow and expensive at the same time. Latency and cost are
the same curve. Scope the goal so the loop has a checkable finish line, and you are not being
tidy, you are cutting the quadratic short.
Go deeper: prompt caching bends the curve, it does not remove it
Providers let you cache a stable prefix, your long system prompt and pinned files, so the
model does not re-pay full price to re-read the unchanging part on every turn. Cached reads
bill at a fraction of fresh input. This flattens the flat part of the context, the standing
instructions, but the growing part, the transcript and fresh tool results, is new on every
turn and cannot be cached ahead of time. Caching turns the steep quadratic into a gentler
one. It does not make a fifty-turn ramble cheap.
The operator read: put everything stable up top so it caches, keep the moving part small,
and still end the loop early. Caching rewards the same discipline scoping does.
The re-read tax · each turn pays for every turn before it
The number you leave with
The token budget of one agent run
Fill these for a real loop you run. Every figure is yours to swap, the price line especially,
pull your provider's current per-million rate. The point is to feel the quadratic before it
shows up on an invoice.
01Tokens added per turnfresh transcript + tool output each pass, e.g. 2,000
02Turns to finish the jobhow many loop passes before the stop condition, e.g. 10
03Re-read multiplierturns × (turns + 1) ÷ 2, the triangular number, e.g. 10 × 11 ÷ 2 = 55
04Total input tokens billedline 01 × line 03, e.g. 2,000 × 55 = 110,000, versus the 20,000 a linear guess predicts
05Input price per 1M tokensyour model's current rate, e.g. $3 per 1M, cached prefix bills far less
06Cost per run = line 04 ÷ 1,000,000 × line 05e.g. 110,000 ÷ 1M × $3 = $0.33, about 5.5× the naive estimate, and it climbs fast as turns rise
Layer 02 · Orchestration
One agent, or many, is a coordination trade, not a power move.
Once one loop works, the tempting next step is more loops: an orchestrator that spawns
subagents, each with its own context window and its own tools, working in parallel. It is
a real pattern, and Anthropic's orchestrator-workers design is exactly this. It buys you two
things. First, parallelism, three subagents researching three sources at once finish in one wall
clock pass instead of three. Second, clean context, each subagent gets a fresh window scoped to
its slice, so none of them drowns in the others' tool output.
What it costs is coordination. The orchestrator has to decompose the job, hand each subagent a
brief, and then merge what comes back, and that merge is where multi-agent runs go wrong: three
confident partial answers that contradict each other, and now something has to arbitrate. You
also multiply the token bill, because every subagent runs its own loop with its own re-read tax,
and the orchestrator re-reads all their summaries on top. Multi-agent pays off when the slices
are genuinely independent and the work is big enough that parallel speed beats the merge cost.
When the steps depend on each other in sequence, one capable agent beats three cheap ones every
time, because you skip the coordination entirely.
Go deeper: keep subagent returns tight, or the orchestrator drowns
The orchestrator's context is the most expensive surface in a multi-agent run, because
everything funnels back into it. The design rule that keeps the pattern affordable: each
subagent returns a structured summary, the answer and the evidence, not the full transcript
of everything it read to get there. A researcher subagent should hand back three findings
and their sources, not the forty pages it skimmed. Pass briefs in lean, get summaries back
lean, and the orchestrator stays inside a sane window even with six workers under it.
This is the same re-read tax from the last section, one level up. At the orchestrator, the
thing being re-read on every turn is your subagents' output, so its size is now a design
knob you control.
Two topologies · single for dependent steps, many for independent slices you can mergeLayer 02 · Orchestration
MCP standardizes the connector, not the model.
The reason the "connect your apps" list keeps growing without a new model shipping is a
protocol, not a product. The Model Context Protocol defines a client-server contract
between a model and an outside tool. The tool runs as an MCP server that exposes three
things over a standard interface: the tools it offers, each with a name, a description, and a
typed input schema; resources it can read; and prompts it can supply. The model's host
app is an MCP client. On connect, the client asks the server "what have you got," the
server answers with that machine-readable list, and the model can now call any of it.
What that buys is an M-plus-N world instead of an M-times-N one. Before, connecting M models to
N tools meant a bespoke integration per pair. With MCP, each tool implements the server once and
every MCP-speaking model can use it, and each model implements the client once and reaches every
server. The tool description and the input schema are the load-bearing part: they are how the
model knows a tool exists and what shape of call it accepts, without anyone hardcoding it. Tool
reach and model capability now improve on separate clocks, which is the whole point.
Go deeper: why the tool schema is where reliability lives
The model chooses tools by reading their descriptions and fills arguments by matching your
request to the input schema. That makes the schema the contract, and a vague one produces a
flaky agent. A tool named send with no description and a loose schema gets
called at the wrong times with malformed arguments. A tool named send_invoice_email
with a precise description and a strict schema, required recipient, amount as an integer of
cents, gets called when it should and fails loudly when it should not.
The other half is idempotency: design a tool so that calling it twice with the same
arguments does no extra damage, because a loop that retries on a timeout will sometimes call
twice. A charge endpoint that double-bills on retry is a bug the model will eventually find
for you. This is ordinary API design, and it is exactly where agent reliability is won or
lost.
Evals are how you know it is actually getting better.
Every layer so far can be built by feel. This one cannot, and it is the layer that separates a
demo from something you trust in production. An eval is a repeatable test of whether the
agent did the job, run against a fixed set of cases so the score means the same thing today as
it did last week. Without one, "I tweaked the prompt and it feels better" is the only feedback
you have, and that feeling is how agents quietly regress: you fix the case in front of you and
break two you are not looking at.
The practical build is three pieces. First, an offline eval set: twenty to fifty real
tasks with a known good outcome, frozen, that you run on every change. Second, a
success metric you can actually score, task success rate is the honest one, the fraction
of cases where the finished artifact met the bar, checked by an exact rule where you can write
one and by a careful human or a model grader where you cannot. Third, a regression gate:
before any prompt or tool change ships, it has to hold or raise the score on the frozen set, not
just win the one case that annoyed you this morning. OpenAI's guide frames the same loop as
building the smallest thing, measuring it, and only then adding capability. The eval set is what
makes "measure" mean something.
Go deeper: what to log so a failure is debuggable a week later
A task success rate tells you the score dropped. It does not tell you why. To answer that,
log the run as a trace: the goal, every tool call with its exact arguments and the
result that came back, and the final output. When a case regresses, you replay the trace and
watch where the loop diverged, usually a tool that returned something unexpected, or context
that got summarized away at turn nine. Tracing is the difference between "it got worse" and
"the search tool started returning empty on quoted queries at turn six."
Tie this back to layer one: the trace shows you which of the four attachments, retrieval,
tools, memory, or the model itself, produced the bad turn. The eval catches the regression,
the trace localizes it to a layer, and the layer tells you the fix.
The most expensive mistakes here are not bugs. They are building an autonomous multi-agent
system for a job that wanted a five-line workflow, or hand-driving a chat window through work an
agent should own. Choose the architecture from the shape of the task, read across four
dimensions: how predictable the steps are, whether the slices are parallel, how much cost you can
tolerate, and whether the job needs to self-correct. Match the row, then build the simplest thing
in it that works.
The architecture decision grid · task shape picks the build
Build
Pick it when the task shape is
The tell you chose wrong
Chat
Steps unknown · not parallelExploratory, one-off, you are still figuring out what you want.
You run the same conversation a third time this week. That is a workflow now.
Workflow
Steps fixed · low cost toleranceSame inputs, same steps, every time, and no self-correction needed.
You keep adding "if this then that" branches. The branching is outgrowing a fixed pipeline.
Single agent
Steps vary · sequential · self-correction neededThe path depends on what each step returns, and steps depend on each other.
Independent chunks are waiting in line for no reason. You are paying latency parallelism would erase.
Multi-agent
Slices independent · parallel · cost toleratedBig job, genuinely separable sub-jobs, and speed is worth the merge.
The subagents keep contradicting each other and you are refereeing. The work was sequential all along.
Read the grid top to bottom and it is Anthropic's own advice in table
form: start at the simplest row that fits and move down only when the task shape forces it. Every
step down adds capability and cost at the same time. The engineering skill is spending that
budget exactly where the task shape earns it, which is the same instinct that runs a business
well. The next lesson, Talk to AI like an engineer,
is how you write the brief that any of these four run on.
Fresh from the lab
What changed this month
OpenAI shipped multi-agent orchestration as a first-class inference mode, not a wrapper you
build yourself. GPT-5.6 Sol reached general availability July 9, and its Ultra mode
decomposes a task and spawns parallel subagent processes inside a single model call, each
working a slice concurrently before a synthesis pass merges the results. It is the
orchestrator-workers pattern from Layer 02, built into the API instead of assembled by you. On
Terminal-Bench 2.1, an 89-task real-terminal benchmark, standard Sol scores 88.8% and Sol Ultra
scores 91.9%. Ultra carries no separate per-token price, but every subagent generates its own
tokens independently, so cost scales with fan-out width exactly the way the re-read tax
predicts, just distributed across parallel loops instead of one sequential one.
MCP moved off a stateful transport, which changes how you would deploy a server. The
2026-07-28 spec, shipped July 28, moves MCP's core from a bidirectional, connection-held-open
model to plain request and response. Practical result: MCP servers, the tool side of the
client-server contract this lesson covered, can now run on serverless and edge infrastructure
instead of a process that has to stay resident. The spec also formalizes Apps and Tasks as
versioned extensions rather than core protocol, and hardens the auth story with OAuth and OIDC.
Adoption backs up the timing: Anthropic reports MCP now clears 400 million monthly SDK
downloads, 4x its pace at the start of the year, with Claude's connector directory alone past
950 servers.
Open weights just posted competitive numbers on the agentic side of the benchmark suite, not
only static QA. Moonshot AI's Kimi K3, a 2.8 trillion parameter mixture-of-experts model
(104 billion active per token, 1,048,576 token context), released July 16 with open weights
following July 26. On real-world task automation benchmarks, the ones that score whether a model
completes a job through tool calls rather than describes one, K3 took first place in four of
eight categories, including AutomationBench and BrowseComp, and posted 88.3% on Terminal-Bench
2.1 against Sol's 88.8%. For anyone weighing build-versus-buy on the model layer, the closed-open
gap on tool use specifically, the mechanism this lesson is built around, is now closer than the
gap on general reasoning benchmarks.
These map to the three-layer model, not
the six parts. Learn them and you can read an architecture doc, a pricing page, and a postmortem
at the same altitude the people who build these systems do. There is no quiz.
Augmented LLM
The block. A model wired to retrieval, tools, and memory. Anthropic's base primitive:
every agent pattern is composition on top of this one thing.
Orchestration
Layer two. The control flow that runs the loop, plan, act, observe, decide, and
decides when to stop, fan out, or hand off. What turns a static block into an agent.
Subagent
Orchestration. A worker agent with its own context window and tools, spawned by an
orchestrator to run a slice in parallel and return a summary, not its whole transcript.
Token budget
The block. The context window is a fixed pool, and the loop re-reads it every turn, so
billed input grows with the square of the turn count. The reason scoping is an economic act.
Prompt caching
The block. Billing a stable prompt prefix at a fraction of fresh input on repeat reads.
Flattens the standing part of context; the growing transcript is still full price.
MCP
Orchestration. Model Context Protocol. A client-server contract that lets one tool
server reach every MCP model. Turns an M×N integration problem into M+N.
Tool schema
Orchestration. A tool's name, description, and typed input shape. How the model knows
a tool exists and what a valid call looks like. Vague schema, flaky agent.
Idempotency
Orchestration. A tool designed so calling it twice with the same arguments does no
extra damage. Required, because a loop that retries on timeout will sometimes call twice.
Eval
Layer three. A repeatable test of whether the agent did the job, run on a frozen set
of real cases so the score is comparable across changes. The cure for "it feels better."
Task success rate
Layer three. The fraction of eval cases where the finished artifact met the bar. The
honest headline metric, and the number a regression gate defends before anything ships.
Not a chatbot you remember to open. A
bounded loop with tool reach, a checkpoint before anything irreversible, and one number that
tells you it is working. Budget a focused afternoon. Each build below picks a real architecture
from the grid on purpose and says which one.
The pattern under all sixteen is the same three layers.
Scoping the loop and connecting only the tools it needs is the block. Wiring the trigger,
the checkpoint, and any handoff is orchestration. The number you track weekly is your
eval, a task success rate you defend before you widen the job.
For female founders
I'm the CEO, the marketer, the bookkeeper, and the intern, and the
building only happens after 9pm.
The chief-of-staff agent that runs on a trigger
Architecture: single agent · Claude Projects + MCP (Gmail, Calendar, Drive) or a custom GPT with Actions, fired by Make/Zapier
Scope one bounded loop, not "help with my business." New inquiry lands, agent
reads it, checks the calendar, drafts a qualified reply, logs it. A loop with a checkable
finish is the only kind you can automate and measure.
Write the standing spec: role, hard refusal rules, the exact finished artifact
("a 120-word reply, one calendar link, drafted not sent"), and a checkpoint before send.
Connect least privilege: read inbox, read calendar, read the proposals folder.
Nothing that sends or spends until you have watched it run for a week.
Wire the trigger: a Make scenario fires the agent on each new inquiry and leaves
the reply as a Gmail draft. You approve every send. That gate is part 06, on purpose.
Track one number: share of drafts you send unedited. Cross ~70% and widen the
job; dip below and tighten the spec before you add anything.
The payoff: a measured draft-first pipeline, with a success rate you can
point at, instead of a tool you forget to open.
For artists
I make the work. Then the statements, applications, and pitches eat the
studio time the work needed.
The applications agent with a deadline radar
Architecture: workflow → single agent · Claude Project + a saved opportunity feed, weekly scheduled run
Build the knowledge base once: statement, CV, honest notes on the practice, and
your own-words descriptions of key pieces. This is retrieval, the block's first layer.
Spec the voice as constraints: "plain and specific, never 'explore' or 'juxtapose'
unless I do." Constraints are how you get a checkable artifact instead of art-speak.
Point it at a real open call: paste the guidelines, and have it draft every answer
from your base, flagging any claim it could not source to your materials.
Checkpoint each submission: you read, correct once in plain words, and only then
submit. Its corrections and the final version go back into the base.
Measure fit, not volume: log submitted versus shortlisted. When one call type
keeps landing, have the agent prioritize that shape next cycle.
The payoff: applications become an edit session with a memory that gets
sharper every deadline, not a lost studio day.
For actors
Between survival jobs, self-tapes, and submissions, the admin of the
career crowds out the acting.
The submissions agent with a scene-work mode
Architecture: single agent · Claude Project or custom GPT, two scoped jobs in one spec
Load the kit as retrieval: resume, three bio lengths, rep info, and the types you
are actually right for in blunt words. The blunter, the better the matches.
Spec two jobs, one gate: submission drafting and sides prep, with a rule that it
never invents credits and always shows which real ones it chose to lead with.
Per breakdown, run the loop: paste it, get a tailored cover note plus the credits
to feature, edit, send. The choice of credits is the checkpoint you keep.
Switch to prep mode: paste sides, get given circumstances, a beat breakdown, and
three playable choices. A scene partner that starts you past the blank page.
Log the loop: what you submitted for, what you booked. When a pattern shows,
the agent leads with the credits that actually convert for your type.
The payoff: submissions in minutes with a booking pattern attached, and
prep that opens at choice three.
For musicians
I'm a musician, and somehow most of my week is a promo job I never
applied for.
The release agent that fans out the kit
Architecture: orchestrator + parallel drafts · Claude Project, one release brief in, a full kit out
Load the story once: bio, past press, how the record was made, the five details
fans always ask. One source, many outputs, that is the parallelization pattern.
Spec the voice from stage: how you actually talk, plus a banlist ("never 'sonic
journey'"). The banlist is a cheap eval, you can grep a draft for it.
One brief, the whole kit: playlist pitch, three venue emails, a week of captions,
a newsletter, all drafted from the same story in one pass.
Checkpoint before anything ships: you read for voice, correct out loud, and the
corrections stay in the room for next release.
Track reuse quality: which pieces you sent unedited. That share climbing release
over release is the agent learning your voice.
The payoff: release-week promo drops to an afternoon with a rising hit
rate, and the writing time goes back to songs.
For fitness pros
I'm booked teaching all day, so programming, check-ins, and content
happen in the cracks that used to be my rest.
The programming agent with a movement guardrail
Architecture: single agent · Claude Project + a client-notes sheet, Sunday scheduled run
Encode your method as rules: how you program, movement standards, sample weeks per
client type, and a hard constraint, never prescribe an exercise you do not coach.
Give it read access to the week's notes ("knee cranky, travel Thursday") and spec
the artifact: a drafted adjustment per client, for your review.
Run the Sunday loop: it drafts every client's week, you approve or fix. The
movement guardrail is the checkpoint that keeps it safe to trust.
Draft check-ins from your bullets: warmth stays yours, typing does not. Every
reply is a draft until you send it.
Measure your Sunday: minutes to clear the queue, and the share of drafts you send
clean. When both improve, batch the content the same way.
The payoff: Sunday admin becomes one hour with a guardrail, and clients
still get your coaching, not a template.
For coaches
I sell transformation, but my calendar is full of the sessions, so the
marketing that fills next month never happens.
The content agent with a privacy hard rule
Architecture: workflow → single agent · Claude Project, weekly themes in, a content week out
Load frameworks and winners: niche, method, the questions you hear weekly, two
pieces that performed. A hard rule at the top: no client details, ever, anonymized or not.
Spec the artifact: five posts and two emails per theme, in your voice, each one
scannable in under fifteen seconds. Concrete artifacts are what an eval can score.
Capture themes on a trigger: one line after each session ("everyone's negotiating
in August") drops in a note the Friday run reads.
Friday loop: it drafts the week; you approve. The privacy rule is the checkpoint,
and you verify it held before anything is scheduled.
Track what lands: log the winners back in. Rising engagement on agent-drafted
posts is your success metric, and it steers the next batch.
The payoff: marketing ships every week with a feedback loop, instead of
never, in the someday.
For therapists
Between sessions I'm doing intake calls, insurance letters, and website
updates, and none of it is why I trained.
The practice-admin agent (with a bright red line)
Architecture: single agent, tightly scoped · Claude Project for the public practice only, never clinical data
Draw the line as the first instruction: no client information enters a general AI
tool, period. Clinical notes need a HIPAA-compliant tool with a signed BAA, a different
aisle. This agent handles the practice, never the people.
Load the public practice: modalities, who you serve, fees, policies, your
warm-but-clear tone. Retrieval scoped to what is already public.
Spec the repeatables: intake FAQ replies, waitlist emails, superbill explainers,
out-of-network scripts, each as a reviewable draft.
Run the loop, keep the gate: it drafts, you edit until it sounds like your office
feels, then it sends nothing on its own. The red line is the checkpoint.
Measure the reclaim: admin minutes recovered per week. When the number holds,
add the referral one-pager and the directory rewrite to its scope.
The payoff: the between-clients hour goes back to notes or lunch, and
the red line keeps it ethical.
For authors
I want to be writing the next book, and instead I'm writing about the
last one, forever.
The platform agent for everything but the book
Architecture: orchestrator + parallel outputs · Claude Project, one book brief in, the eternal kit out
Draw the boundary: the book is you and off-limits to the agent. Synopsis variants,
newsletter, and event copy are its department. Scope is the first design act.
Load the base: synopsis, a sample chapter, reviews, bio, and how you talk to
readers. One retrieval set feeds every downstream output.
Fan out the kit: synopsis in three lengths, five podcast angles, event copy, a
reader-magnet description, all from the same base in one pass.
Batch the newsletter with a gate: your month's notes in, a draft out, your edit
keeps the voice. Nothing publishes without your pass.
Track the outreach loop: tailored pitches drafted in ten minutes each, logged
against replies. The reply rate tells you which angle is working.
The payoff: platform upkeep holds at an hour a week with a metric, and
the next book gets the mornings.
For chefs
I'm cooking or shopping all day. Menus, costing, and captions happen
after midnight if they happen at all.
The back-of-house agent that costs and writes
Architecture: single agent · Claude Project + a costs sheet it can read, one dish in, the kit out
Load the kitchen: signature dishes, sourcing philosophy, price points, and a voice
rule, "no adjectives I wouldn't say across the pass." Retrieval plus a banlist.
Give it your numbers: per-head costs and target margins, so quotes come out
arithmetic-correct, not vibes. This is tool reach into your real data.
One dish, the whole kit: paste a new dish, get the menu line, the caption, and the
newsletter blurb in one loop.
Checkpoint the quote: it drafts the catering email from your margins; you confirm
the math and the price before it goes. Money always gets a gate.
Keep a specials bank: every write-up goes back in, and you track how many you ship
unedited. January writes faster than July did.
The payoff: the after-midnight shift leaves the schedule, and the quotes
come out priced right.
For consultants
I'm delivering client work all day, so my own pipeline goes cold every
time I'm busy, which is exactly when it shouldn't.
The pipeline agent that runs after every call
Architecture: single agent · Claude Project + Gmail via MCP, a Friday scheduled pipeline pass
Load positioning: who you serve, the three problems you solve, a winning proposal,
two case studies. The base every draft reasons from.
Spec two loops: a post-call recap-and-next-step, and a Friday nudge pass over open
threads. Each ends in a draft, never an auto-send.
Post-call loop: paste your notes, get the recap email and next-step draft before
the coffee is cold. You approve, it logs the thread state.
Friday pipeline pass: it reads your open threads and drafts a nudge per lead, each
referencing the real last conversation. You send the ones that fit.
Measure warmth: track reply rate on agent-drafted nudges. A rising number means the
pipeline stays warm while you bill, which is the whole trick.
The payoff: a pipeline that runs on a schedule, with a reply rate you
watch, not a database that goes cold when you get busy.
For health advocates
Every client is a crisis, and the paperwork is endless. I'm doing intake,
appeals, and case summaries at 11pm.
The paperwork agent on a template library (privacy first)
Architecture: workflow → single agent · Claude Project, de-identified templates only
Privacy is instruction one: no client health information in a general AI tool. The
agent works in templates and [BRACKETS]; you fill the person in later, in your own
documents. That rule is the whole guardrail.
Load de-identified skeletons: your best appeal structures, records-request letters,
provider outreach, onboarding, each stripped to its bones. Retrieval, safely scoped.
Build the library as a loop: each case type becomes a reusable template with the
variable fields marked. The library compounds run over run.
Draft public work for real: website copy, workshop outlines, family explainers in
plain warm language, each a draft you approve.
Measure the fill-in time: the 11pm letter should drop to a 15-minute fill-in. Track
that number, and add a template every time a new case type appears.
The payoff: the paperwork mountain becomes a compounding template
library, and client hours go to clients.
For makers
I make the thing. Then I photograph the thing, list the thing, ship the
thing, and market the thing, and suddenly I never make the thing.
The shop agent that batches listings
Architecture: single agent · Claude Project, two-sentence input per piece, a full listing out
Load the shop: materials, process, price ranges, three best listings, and who
actually buys. Your top listings are the voice sample the agent matches.
Spec the artifact: title, description, materials, care, and story, in your voice,
from two plain sentences of input. A tight schema means consistent output.
Batch the loop: describe each new piece briefly, get the full listing back, review,
publish. The review is your checkpoint before anything goes live.
Draft the wholesale kit once: line-sheet copy and a pitch email tailored per shop
for the five you want to be in.
Track listing speed: minutes per listing and the share you post unedited. When both
hold, spin up seasonal-collection copy the same way.
The payoff: listing night becomes listing hour with a metric, and the
studio gets its maker back.
For nonprofit leaders
I'm chasing grants, thanking donors, and writing the newsletter, and the
mission work is what's left over.
The development agent, an office of one
Architecture: single agent · Claude Project + a donor sheet it can read, gift data drives the draft
Load the mission once: mission and vision, programs, impact numbers, two funded
proposals, your best appeal. The base every grant and letter draws from.
Spec the voice: concrete and warm, never grandiose, with a rule to only claim
impact numbers that appear in your data. That rule is your hallucination guard.
Grant loop: paste a funder's guidelines, get need statement, program description,
and org history in their language, flagged where a number needs your confirmation.
Donor gratitude that scales: it drafts thank-yous personalized from gift size and
history; you sign each one. The signature is the checkpoint.
Measure development hours: time reclaimed per week, and grant win rate over time.
Rising numbers mean the mission gets its hours back.
The payoff: development runs on a repeatable loop with a win rate, and
funders still hear a human.
For photographers
I'm booked shooting on weekends and editing all week, so inquiries wait
and the blog died in 2023.
The front-desk agent that replies same-day
Architecture: single agent · Claude Project + Gmail via MCP, drafts on each new inquiry
Load the studio: packages, pricing, turnaround, FAQs, booking process, and three
inquiry replies that felt right. Your real availability rules go in as constraints.
Spec the reply: warm, in your voice, with the correct next step and never a price
you did not list. A tight artifact is what makes same-day safe.
Trigger on inquiry: each one gets a same-day draft in your inbox. You edit and
send. Speed books shoots, and you just bought speed with a gate on it.
Automate the journey copy: booking confirmations, prep guides, gallery-delivery
emails, drafted once and reused, each approved the first time.
Revive the blog on a loop: three sentences per delivered shoot become an SEO post
it drafts. Track posts shipped per month as your success metric.
The payoff: inquiry response goes same-day with a draft-first gate, and
editing week stays for editing.
For realtors
My database is a graveyard. Everyone I've ever sold to is in there, and
none of them have heard from me since closing.
The follow-up agent that segments and drafts
Architecture: workflow → single agent · Claude Project + a contacts export, monthly scheduled pass
Load the market: farm area, niche, recent sales, and how you actually talk to
clients, texts included. The texting voice is what keeps it from smelling like a campaign.
Spec the segments: past clients into three groups, each with a different
re-connection angle, and a rule to reference a real detail, never a mail-merge blank.
Resurrect on a loop: it drafts a per-group note that reads like a neighbor; you
approve and send in batches. The approval is your checkpoint.
Monthly value email on rails: feed three local data points, get the update people
actually open, drafted for your quick edit.
New listing, full kit: one paste of details yields MLS copy, captions, and
open-house follow-ups. Track reply rate on nurture sends as your metric.
The payoff: the graveyard becomes a referral engine with a reply rate,
on one planning hour a month.
For stylists
I'm behind the chair all day. Rebooking texts, socials, and retail
recommendations all happen on my one day off.
The chair agent that runs rebooking and content
Architecture: single agent · Claude Project or custom GPT, a weekly due-list in, nudge texts out
Load the chair: services and prices, rebooking windows by service, the products you
actually believe in, and your texting voice. The window rules drive who is due.
Spec three jobs, one gate: rebooking nudges, promo messages, and captions, all in
your between-appointments voice, every message a draft you fire off.
Weekly rebooking loop: list who is due ("Maya, balayage, 8 weeks"), get friendly,
specific nudge texts to send between clients. You send, so the gate is you.
Content from the chair: two sentences about today's transformation become a caption
bank entry. Batch a month in one sitting.
Track rebooking rate: share of nudged clients who rebook. That number rising is the
agent earning its keep, and it steers the retail aftercare notes next.
The payoff: the day off goes back to being a day off, with a rebooking
rate you can watch climb.
The house rule
Lauren's line, and the standard at this party: what belongs to you and keeps your humanity,
you keep. What frees you to be more human away from your laptop, you hand off. Taking the agent
apart does not change that rule, it just tells you exactly where to put the checkpoint. You stay
the one who decides what is worth doing.