Party School · Go deeper · Context engineering

Context engineering.

You already write clean prompts. The next skill is not a better sentence, it is deciding what the model gets to see at all. In September 2025 Anthropic named this context engineering: managing the full set of tokens in the window so the highest signal is present and the noise is gone. This lesson treats the window as a budget you allocate across five competing categories, works through retrieval versus long context versus memory, few-shot selection, context rot and eviction, and how to test a prompt the way you test code.

Updated August 1, 2026 Refreshed monthly Sources: Anthropic · OpenAI
Core concept 01

The context window is a budget, and every category competes for it.

Anthropic's framing is the one worth internalizing: the context window is a finite resource with diminishing returns, and the job is to find the smallest set of high-signal tokens that maximizes the odds of the outcome you want. That reframes prompting entirely. You are not writing an instruction, you are allocating a budget. On a 200,000-token window, every token you spend on one thing is a token unavailable to another, and past a point, more tokens make the answer worse, not better.

Five categories draw on the same budget at once: the system prompt and instructions, any retrieved knowledge you pull in, the few-shot examples you show, the conversation history so far, and the tool results that come back from searches, files, and function calls. Prompting basics decide the wording inside one category. Context engineering decides the split across all five: what to load, what to keep out, and what to drop once it stops earning its place.

Source: Anthropic, "Effective context engineering for AI agents"

Scroll the diagram sideways →

One window, one budget a 200k-token window, split across five competing categories + reserve WHAT YOU LOAD → retrieved knowledge examples history tool results reserve: room to reason + write the answer SYSTEM ~2k RETRIEVED ~18k FEW-SHOT ~6k HISTORY ~8k TOOL RESULTS ~46k Loaded: ~80k · Free headroom: ~120k more tokens ≠ better answer past this point Every token spent on one category is a token the others don't get. Allocation is the skill.
The context budget · five loaded categories plus reserve, on one fixed window
Core concept 02

Retrieval, long context, and memory solve three different problems.

When you need the model to know something it wasn't trained on, you have three moves, and they are not interchangeable. Retrieval (RAG) means you keep the knowledge outside the window in a searchable store and pull in only the few passages that match the current task. Long context means you load the whole corpus into the window and let the model read all of it. Memory means the system persists facts across sessions and re-injects the relevant ones when they matter, so nothing has to be re-pasted every time.

The trade is precision against completeness against continuity. Retrieval wins when the corpus is large and each task only needs a slice of it, because it keeps the window lean and the signal high. Long context wins when the task genuinely needs the model to reason across the entire document at once, a full contract, a whole transcript, where a retrieved fragment would miss the connective tissue. Memory wins when the same facts about you, your clients, your standards should survive from one conversation to the next without a paste. Most real setups use two of the three: a small standing memory, plus retrieval for the deep archive, and long context only for the one document today's task is actually about.

Go deeper: why "just paste everything" loses to retrieval at scale

Loading a 300-page archive into a long window costs on two axes. First, price and latency: you pay for every token on every turn, and the model reads all of them each time. Second, and worse, signal dilution. The one paragraph that answers the question is now competing with hundreds of pages of near-irrelevant text, and the model's attention is spread across all of it. Retrieval fixes both at once by putting only the matching passages in front of the model, so the answer is cheaper and sharper. The rule of thumb: long context for the one document this task is about, retrieval for the library it lives in.

Source: Anthropic, "Effective context engineering for AI agents"

Scroll the diagram sideways →

Retrieval vs long context vs memory How much of the knowledge does THIS task actually need? RETRIEVAL · RAG A slice of a big library. Corpus is large; each task needs only a few passages. Wins: precision, low cost. LONG CONTEXT The whole document. Task needs the model to reason across all of it. Wins: completeness. MEMORY Facts that persist. Same truths about you and your work, every session. Wins: continuity. Most real setups combine two: a small memory, retrieval for the archive, long context for today's one document.
Three ways to feed the model what it wasn't trained on · pick by what the task needs
Core concept 03

Few-shot examples are a selection problem, not a volume one.

Both labs agree examples are the highest-impact thing in a prompt: Anthropic's guidance is that examples show rather than tell, and clarify the subtle stuff that is hard to describe, like tone and structure. The mistake fluent users make is treating that as a volume dial, ten examples must beat three. They usually do not. Each example you add spends budget and pulls the model's pattern matching toward whatever that example happens to contain. Five examples that all resemble the current task teach a tighter pattern than twenty scattered ones, and they leave more window for the actual work.

So the discipline is selection, not accumulation. Choose examples that match the current task on the dimension that matters: the same format, the same edge case, the same tone register. Anthropic recommends making examples diverse enough to cover the cases you care about, while staying relevant, which is the balance to hold, cover the real variation, cut the decorative duplicates. In a saved template this means you do not keep one growing pile of samples. You keep a small, curated set and swap in the one or two that resemble today's job.

Sources: Anthropic, "Prompting best practices" · OpenAI, "Prompt engineering"

Core concept 04

Models lose the middle, so plan for eviction before it happens.

A long window is not uniformly readable. Attention is strongest at the start and end of the context and weakest in the middle, so a critical instruction buried halfway down a huge paste is the one most likely to get skipped. Anthropic describes the broader version of this as context rot: as the token count climbs, the model's ability to accurately recall and use any single piece of it degrades. The window fills, and older, mid-stack content gets summarized, compressed, or dropped to make room. Your carefully placed rule from message one is still technically present, but it is now diluted by everything since.

The operator response is to design eviction on purpose instead of letting it happen by accident. Put the load-bearing instructions where attention is strongest, at the very top of the system prompt and restated near the actual ask. Keep the standing brief short so it survives compaction. And treat conversation history as the first thing to cut: when a thread drifts, do not argue across ten more turns, start a fresh window and reload only the memory, the two real files, and the current task. A clean window with the right three attachments beats a forty-message thread almost every time, and now you know the mechanism why.

Source: Anthropic, "Effective context engineering for AI agents"

Core concept 05 · Judgment

For any task, decide what to load and what to evict, and why.

This is the whole skill in one table. Take one real recurring task and walk the five categories: what earns a place in the window, what gets left in the store or dropped, and the reason behind each call. The reasons are the point. Once you can name why a category is in or out, you can make the same decision on a task you have never seen before.

The context-budget allocation · a consultant drafting a proposal from a discovery call
CategoryLoad or evictWhy
System & instructions Load · keep short Role, voice rules, and the proposal structure. Short enough to survive compaction and sit where attention is strongest, the top.
Retrieved knowledge Load a slice The two case studies closest to this prospect's problem, pulled from the archive. Not all nine. Relevance, not the whole library.
Few-shot examples Load one, curated The single winning proposal that matches this format. A second only if the prospect is a different edge case. Selection over pile.
Conversation history Evict first The prior back-and-forth is scaffolding. It dilutes signal and is the cheapest thing to drop when the window tightens.
Tool results Load today's, drop stale This call's transcript is the whole point, load it in full. Last week's transcript and the raw CRM export stay out.

Notice what the judgment turns on: the task decides the split. A task that needs one document whole loads it in full; a task that needs a slice of a library retrieves. The categories are fixed. The allocation is yours to make, every time, on purpose.

Core concept 06

Test a prompt the way you'd test code.

The moment a prompt goes from a one-off message to a saved template running real work, vibing stops being enough. OpenAI's guidance is blunt about this: evaluate and iterate systematically, because a prompt that looks good on one input can quietly fail on the next. The engineering move is an eval set: five to ten real inputs you have seen, each paired with what a good output looks like. When you change the prompt, you run the whole set and check that the score went up and nothing that used to pass now fails. That last part is regression testing, and it is the difference between improving a prompt and just moving its failures around.

Scoring does not need a framework to start. For most solo work a rubric of three checks is plenty, did it hit the format, the voice, and the actual ask, scored pass or fail per input, so you are measuring instead of guessing. Anthropic's self-correction pattern lives inside this loop: have the model critique a draft against your rubric, then revise from the critique. The habit that separates a durable template from a lucky one is simple. Never change a prompt you rely on without running it back across the same set of inputs first.

Sources: OpenAI, "Prompt engineering" · Anthropic, "Prompting best practices"

The eval loop · measure, don't vibe 01 · WRITE The prompt or the revision you're testing. 02 · RUN On the set 5–10 real inputs you've seen before. 03 · SCORE Against a rubric format · voice · ask pass / fail each. 04 · READ The scores then revise from evidence. revise, then run the SAME set again REGRESSION CHECK score went up AND nothing that used to pass now fails
An eval loop · the same discipline you'd give code, on a prompt that does real work
The worksheet you leave with

Allocate a 200k window for your one real task

Pick the recurring task that eats the most of your week. Walk the five categories and assign each a token budget out of 200,000. The numbers below are a worked example for a proposal from a discovery call. Replace them with yours, add them up, and read what has to get cut.

  1. ≈2kSystem & instructionsrole, voice rules, output structure, kept short so it survives compaction and sits up top where attention is strongest
  2. ≈18kRetrieved knowledgethe 2 closest case studies + positioning, pulled from the archive, a slice, not all nine
  3. ≈6kFew-shot examplesone winning proposal that matches this format, curated in, a second only for a true edge case
  4. ≈8kConversation historycapped low and evicted first when the window tightens, scaffolding, not signal
  5. ≈46kTool resultstoday's full call transcript loaded whole; last week's transcript and the raw CRM export stay out
  6. ≈80kLoaded · ~120k headroom left to reason and answerwhat got CUT to keep it lean: the other 7 case studies, the full CRM export, every prior chat in this thread, evicted on purpose, not by accident
Fresh from the lab

What changed this month

Anthropic's own team just validated aggressive prompt deletion at production scale. On July 24, Anthropic published "The new rules of context engineering for Claude 5 generation models," detailing how the Claude Code team cut more than 80% of its system prompt migrating to Claude Opus 5 and Claude Fable 5, with no measurable regression on coding benchmarks. The framing: rules written to guardrail worse models against known failure modes had become conflicting instructions competing for token budget once the model got good enough to exercise judgment on its own. The post names six concrete shifts, rules become judgment, examples become interface design, upfront context becomes progressive disclosure through Skills, duplicated instructions get consolidated into tool definitions, manual memory becomes auto-memory, and flat markdown specs get replaced by richer references like tests and rubrics. Anthropic also shipped claude doctor, a command that audits your own system prompt, skills, and CLAUDE.md for exactly this kind of bloat.

OpenAI published a parallel argument for GPT-5.6, with the eval numbers to back it. The guidance, live July 9, formalizes "outcome-first prompting": define the goal, the constraints, and the stopping condition, then stop scaffolding the path. In OpenAI's internal coding-agent evals, switching from heavily prescriptive prompts to outcome-first prompts improved scores 10 to 15%, cut total tokens 41 to 66%, and cut cost 33 to 67%. Notably, "think step by step" no longer earns its keep on GPT-5.6 the way it did on earlier generations. The model already runs that reasoning internally, so the instruction just spends tokens for free.

Read together, both labs are converging on the same operating rule for context budgets: every token spent guardrailing a capability the model already has is a token not spent on the actual task, and it can measurably hurt the result, not just the bill.

Sources: Anthropic, "The new rules of context engineering for Claude 5 generation models", July 24, 2026 · TechTimes, "GPT-5.6 Prompting Guide: Lean System Prompts Now Outperform Elaborate Scaffolding", July 15, 2026

Vocabulary

Seven words that make context engineering precise

These are the terms the labs use in their engineering write-ups. Learn them and you can read any prompting or agent doc, from Anthropic to OpenAI, at the level it was written.

Context window

The fixed number of tokens a model can attend to at once, input and output together. On many current models that is around 200k. It is the budget everything competes inside.

Token budget

Treating the window as a resource you allocate. Anthropic frames it as finding the smallest high-signal set of tokens that maximizes your desired outcome, because returns diminish as it fills.

RAG / retrieval

Retrieval-augmented generation: keep knowledge in a searchable store outside the window and pull in only the passages that match the current task. Precision and low cost, at scale.

Few-shot

Showing the model a small set of example inputs and ideal outputs inside the prompt. A selection problem, not a volume one: relevance and coverage beat raw count.

System prompt

The standing instructions read before every message, the role and rules layer. In Claude Projects and custom GPTs this is the "instructions" box. Put load-bearing rules here, at the top.

Eval

A fixed set of real inputs paired with what a good output looks like, plus a rubric to score against. You run it every time you change a prompt, and check for regressions.

Context rot

Anthropic's term for the decay in a model's ability to accurately use any single token as the window fills. The mechanism behind lost-in-the-middle and the case for eviction.

Deeper definitions, straight from the builders: Anthropic, "Effective context engineering" · Anthropic prompt engineering docs · OpenAI prompt engineering guide

Make it yours

Engineer the context for your one task

Same five categories, your real work. Pick your lane and build one context-engineered template for your highest-value recurring task: the right files retrieved, the right one example selected, an eviction rule, and a small eval set to test it. Budget about an hour, once. A Claude Project or a Custom GPT is enough to hold it all.

For female founders

I'm the CEO, the marketer, the bookkeeper, and the intern, and I write every proposal, post, and follow-up from a blank page because I've never saved a version of my own voice.

The investor-update, engineered

Tool: Claude Project (or Custom GPT) · pinned files + a 5-input eval set
  1. Pick the one task, the recurring investor or customer update, and write a short system prompt: role, voice rules, the exact structure you send. Keep it under 200 words so it survives a long thread.
  2. Retrieve, don't dump. Load only this period's metrics and the last update as reference. The full data room and every prior email stay out of the window.
  3. Select one example, the update that got the best investor reply, labeled "match this structure and candor." Not five, the one that fits.
  4. Write the eviction rule: each month, start a fresh chat, reload the system prompt plus this month's numbers, drop last month's thread entirely.
  5. Build a 5-input eval set: five past months' raw numbers, and score each generated update on format, voice, and the one clear ask before you trust it.

The payoff: the update writes in one measured hour, and it passes the same bar every month because you can prove it does.

For artists

I make the work, then the statements and applications eat the studio time, and every single one starts from zero in my own voice.

The statement, context-engineered

Tool: Claude Project (or Custom GPT) · retrieved bio + a scored example set
  1. System prompt first: your voice rules in plain terms. Ban the words you never use ("explore," "juxtapose") right in the instructions, at the top where attention holds.
  2. Retrieve the right slice: load your bio, your two strongest past statements, and this show's brief. Leave the full archive of every statement you've written out.
  3. Select one example, the statement closest in length and register to what this application needs, marked "this directness, every time."
  4. Eviction rule: new deadline, new window. Reload the standing brief and the one matching example, never the last application's back-and-forth.
  5. Eval set of five: five past open calls you've answered, and check each draft holds your voice and the length before it goes out.

The payoff: applications become an edit pass you can trust, not a lost studio day and a coin flip.

For actors

Between survival jobs, self-tapes, and submissions, I retype the same cover note a dozen slightly worse ways because I never saved the one that actually booked something.

The submission, engineered per breakdown

Tool: Claude Project (or Custom GPT) · retrieved credits + a rubric
  1. System prompt: your voice, warm and never desperate, plus the rule "lead with the credit that fits the breakdown." That last rule does the real work.
  2. Retrieve, don't paste your whole résumé: load your credit list and this specific breakdown. The model selects the matching credit; you don't hand-pick every time.
  3. Select one example, the cover note that actually got a callback, marked "the standard." One, not your whole folder of past notes.
  4. Eviction rule: each breakdown is a fresh window with only the credits and today's role, so yesterday's submission never bleeds into this one.
  5. Eval set: five real past breakdowns, and score whether the note led with the right credit and sounded like you, not like a form.

The payoff: every submission is tailored and on-voice in minutes, and you can see it holds up across roles.

For musicians

I'm a musician, not a manager, but I'm the one writing gig pitches, deposit chasers, and midnight replies to "do you do weddings?" with no template in sight.

The booking pitch, engineered

Tool: Claude Project (or Custom GPT) · retrieved EPK facts + a scored set
  1. System prompt: talk like you talk from stage, three sentences, one ask, one link. Put the format rule up top so it holds through a long booking thread.
  2. Retrieve the facts: load your rates, availability rules, and one-line EPK. Keep the full press folder and every past email chain out of the window.
  3. Select one example, the pitch that actually booked a room, marked "this exact tone." Swap it only if a venue is a genuinely different room.
  4. Eviction rule: each inquiry starts fresh with the facts and the one example, so a wedding lead never inherits a dive-bar thread.
  5. Eval set: five real past inquiries, and check each reply keeps the ask clear and the voice yours before you lean on it.

The payoff: inquiries get same-day, on-brand replies you've actually tested, not midnight guesses.

For fitness pros

I'm teaching back to back all day, and by 9pm I'm still writing captions, DMs, and re-sign nudges from scratch every time.

The client check-in, engineered

Tool: Claude Project (or Custom GPT) · retrieved cues + a pass/fail rubric
  1. System prompt: warm, direct, three sentences, and a hard rule, never invent an exercise you don't coach. That guardrail belongs in the instructions, not your memory.
  2. Retrieve your real cues: load your coaching-cue list and this client's current program. The full client roster stays out of the window.
  3. Select one example, your best actual check-in reply, marked "match this warmth." One that fits this client's stage.
  4. Eviction rule: each client's check-in is its own fresh window, so nobody's note picks up another client's details.
  5. Eval set: five past check-ins, and score each on warmth, the three-sentence cap, and no invented exercises before Sunday batch.

The payoff: Sunday admin shrinks to one tested hour, and every note stays inside what you actually coach.

For coaches

I sell transformation, but I spend my week rewriting the same follow-up email and recap note because I never turned the good one into a template.

The session recap, engineered with a red line

Tool: Claude Project (or Custom GPT) · retrieved framework + a rubric
  1. System prompt with the guardrail baked in: encouraging, specific, no jargon, format of recap plus one action step plus one question, and a hard rule, no client names, ever.
  2. Retrieve your framework, not your clients: load your recap structure and coaching model. Real session details go in by hand, per recap, never stored.
  3. Select one example, a recap a client actually thanked you for, marked "this level of specific," identifying details stripped first.
  4. Eviction rule: each recap is a fresh window, so no client's theme ever carries into another's note.
  5. Eval set: five de-identified past recaps, and score structure, specificity, and the no-names rule before you rely on it.

The payoff: follow-up goes out same-day and provably safe, instead of the someday pile.

For therapists

Between sessions I'm drafting intake replies and insurance letters from a blank page, and none of it is why I trained.

The front-office reply, engineered behind a wall

Tool: Claude Project (or Custom GPT), admin only · retrieved policies + a rubric
  1. Draw the wall in the system prompt: no client information enters this tool, ever, and never reference a specific client. This is the load-bearing instruction, so it sits at the top.
  2. Retrieve the practice, not the people: load your policies, availability, and fee structure. Nothing clinical, nothing identifying, goes in the window.
  3. Select one example, your best past intake reply with every identifying detail removed first, marked "this warmth, this clarity."
  4. Eviction rule: each reply is a fresh window; this Project is reserved for front-office work and kept entirely separate from any clinical system.
  5. Eval set: five de-identified past inquiries, and score warmth, clarity, and the never-a-specific-client rule before you trust the template.

The payoff: the admin hour between clients comes back, with the privacy line built into the tool, not just your memory.

For authors

I want to be writing the next book, and instead I'm rewriting the same launch email and pitch note from scratch every single time.

The newsletter, context-engineered

Tool: Claude Project (or Custom GPT) · retrieved catalog + a scored set
  1. System prompt: your reader voice, the one from the book's acknowledgments, and the format, 300 words, one story, one link. Voice rules up top.
  2. Retrieve, don't load the shelf: pull your synopsis, bio, and this book's key facts. The full back catalog and every past issue stay out of the window.
  3. Select one example, the issue with the best reply rate, marked "this structure." Swap it only for a genuinely different kind of send.
  4. Eviction rule: each issue is a fresh window with the standing voice and the one example, so last month's thread never dilutes this one.
  5. Eval set: five past issues, and score voice, the 300-word shape, and the single link before it goes to the list.

The payoff: platform upkeep drops to a tested hour a week, and mornings go back to the book.

For chefs

I'm cooking or shopping all day, so every quote and menu description gets written cold, with no starting point to work from.

The menu description, engineered

Tool: Claude Project (or Custom GPT) · retrieved sourcing + a rubric
  1. System prompt: no adjectives you wouldn't say across the pass, format of dish name, three-word story, price. The voice rule sits at the top so it holds.
  2. Retrieve the facts: load your sourcing philosophy and current price points. Keep the full recipe archive and every past menu out of the window.
  3. Select one example, the menu line guests actually asked about, marked "this exact restraint." One that matches tonight's dish.
  4. Eviction rule: each menu run is a fresh window with sourcing and the one example, so last season's specials never creep in.
  5. Eval set: five past dishes, and score each description on restraint, the format, and an accurate price before it hits the board.

The payoff: the after-midnight admin shift gets cut, and the copy sounds like your kitchen, every time.

For consultants

I'm delivering client work all day, so my proposals and recap emails start from a blank page every time, right when I have the least time to write well.

The proposal, engineered from the call

Tool: Claude Project (or Custom GPT) · retrieved case studies + a 5-input eval
  1. System prompt: credible, unhurried, no jargon, format of problem, approach, three deliverables, price. Structure up top so it survives a long transcript.
  2. Retrieve the right slice: load the two case studies closest to this prospect's problem plus your positioning. Not all nine, and not the full CRM export.
  3. Select one example, the proposal that actually closed, marked "this structure, every time." A second only for a different kind of engagement.
  4. Eviction rule: load today's call transcript in full, then start fresh for the next proposal, dropping the transcript and the prior thread.
  5. Eval set: five past discovery calls, and score each proposal on structure, voice, and a right-sized price before you send.

The payoff: the pipeline stays warm while you're billing, on proposals you've measured, not vibed.

For health advocates

Every client is a crisis and the paperwork is endless, and I'm drafting intake notes and appeal letters from zero each time.

The appeal letter, engineered behind brackets

Tool: Claude Project (or Custom GPT), templates only · retrieved policy + a rubric
  1. System prompt with the privacy rule first: no client health information enters this tool, use [BRACKETS] for every detail, plain and firm, no legal jargon. That rule leads.
  2. Retrieve the policy, not the person: load the relevant appeal grounds and your letter structure. Case details never go in the window; you fill them after.
  3. Select one example, a de-identified appeal that actually won, marked "the standard." One that matches this denial type.
  4. Eviction rule: each letter is a fresh window with the policy and the one example, this Project holds templates only, never case files.
  5. Eval set: five de-identified past appeals, and score firmness, the bracket discipline, and structure before you trust the skeleton.

The payoff: the 11pm letter becomes a fifteen-minute fill-in-the-blanks job with the privacy line built in.

For makers

I make the thing, then I write the listing, the caption, and the wholesale pitch from scratch for every single piece.

The product listing, engineered

Tool: Claude Project (or Custom GPT) · retrieved materials + a rubric
  1. System prompt: specific and unfussy, no adjective that could describe any product, format of title, two-sentence story, materials, care. Format rule up top.
  2. Retrieve your facts: load your materials list, process notes, and price ranges. Keep every past listing out of the window; pull only what this piece needs.
  3. Select one example, your best-selling listing, marked "this exact structure." One that matches this piece's category.
  4. Eviction rule: each listing is a fresh window with materials and the one example, so the last piece's copy never bleeds into this one.
  5. Eval set: five past pieces, and score each listing on specificity, the format, and accurate materials before it goes live.

The payoff: listing night becomes listing hour, on copy you've tested to sound like your bench, not a template mill.

For nonprofit leaders

I'm chasing grants and thanking donors, and every letter starts from a blank page even though I say the same true things every time.

The grant section, engineered

Tool: Claude Project (or Custom GPT) · retrieved boilerplate + a scored set
  1. System prompt: concrete, warm, never grandiose, format of need statement, program description, one real number. The no-grandiosity rule belongs up top.
  2. Retrieve the slice: load your mission, this program's description, and your current impact numbers. Leave the full grant archive and every past letter out.
  3. Select one example, language from a proposal that actually got funded, marked "this concreteness." Matched to this funder's focus.
  4. Eviction rule: each funder is a fresh window with the boilerplate and the one example, so last month's ask never dilutes this one.
  5. Eval set: five past sections, and score concreteness, the real number, and no grandiosity before it goes to the funder.

The payoff: development stops eating the mission's hours, and every ask carries a number you can stand behind.

For photographers

I'm booked shooting on weekends and editing all week, so every inquiry reply and gallery email gets written cold, mid-scramble.

The inquiry reply, engineered

Tool: Claude Project (or Custom GPT) · retrieved packages + a rubric
  1. System prompt: warm, in your voice, real availability rules and next steps only, no invented dates. The availability rule sits at the top where it holds.
  2. Retrieve the facts: load your packages, pricing, and turnaround times. Keep every past client thread out of the window; pull only what this inquiry needs.
  3. Select one example, the inquiry reply that actually booked, marked "this exact warmth." One that matches this shoot type.
  4. Eviction rule: each inquiry is a fresh window with packages and the one example, so a wedding lead never inherits a headshot thread.
  5. Eval set: five real past inquiries, and score warmth, accurate availability, and a clear next step before you lean on it.

The payoff: inquiry response goes same-day and accurate, without a VA, and you've proven it holds.

For realtors

My database is a graveyard, and every listing description and nurture email starts from zero instead of from what already worked.

The listing description, engineered

Tool: Claude Project (or Custom GPT) · retrieved comps + a scored set
  1. System prompt: sound like a neighbor, not a brochure, format of 150 words, three features, one call to see it. The voice rule leads the instructions.
  2. Retrieve the slice: load this property's facts and your farm-area notes. Keep the full MLS export and every past listing out of the window.
  3. Select one example, the listing that sold fastest, marked "this exact tone." One that matches this property's type.
  4. Eviction rule: each listing is a fresh window with the facts and the one example, so last quarter's copy never creeps in.
  5. Eval set: five past listings, and score the neighbor voice, the three features, and the word count before it goes on the sheet.

The payoff: the graveyard becomes a referral engine, on one planning hour a month and copy you've tested.

For stylists

I'm behind the chair all day, so every rebooking text and caption gets typed out fresh, one client at a time, from nothing.

The rebooking text, engineered

Tool: Claude Project (or Custom GPT) · retrieved services + a rubric
  1. System prompt: warm and quick, sounds like a text, not an ad, format of one line, one specific detail, one link. The "sounds like a text" rule goes up top.
  2. Retrieve the facts: load your services, prices, and rebooking windows. Keep your full client list out of the window; the specific detail goes in by hand.
  3. Select one example, a rebooking text that actually worked, marked "this exact length." One that matches this service.
  4. Eviction rule: each text is a fresh window with services and the one example, so no client's message picks up another's detail.
  5. Eval set: five past rebooking texts, and score the one-line length, the specific detail, and the single link before you batch a day of them.

The payoff: the day off goes back to being a day off, on texts you've tested to sound like you, not a bot.

The house rule

Context engineering is not a heavier version of prompting. It is the calmer one. Once you treat the window as a budget you allocate on purpose, most of the work is subtraction: the right three files instead of the whole archive, the one example instead of the pile, the fresh window instead of the forty-message thread. What belongs to you and keeps your humanity, you keep. What is a template you would build the same way every time, you engineer once and test so it holds.

Next lesson: Pick your tools →