The AI didn't write a generic thank-you letter because it's bad at writing. It wrote a generic thank-you letter because you gave it nothing to be specific about.
Every development professional has now had the same experience. You open an AI tool, type "write a thank-you letter to a donor who gave $5,000 to our scholarship fund," and get back something that is grammatically flawless, emotionally weightless, and completely interchangeable with what any other nonprofit in the country would send.
The usual diagnosis is that AI can't do warmth. That's the wrong diagnosis. The model produced an average letter because you handed it an average request. It had no idea who your donor is, how your organization talks, what your scholarship fund actually does, or what you would never say out loud. So it filled the gaps with the statistical middle of every nonprofit letter ever written.
The fix is context engineering, and it is the single highest-leverage skill in AI-era stewardship.
Context engineering vs. prompt engineering
Prompt engineering is about phrasing: how you word the request, what role you assign, whether you ask for steps. It helped a lot in 2023. It matters much less now, because the models got better at understanding intent.
Context engineering is about supply: what information the model has available when it answers. Not how you ask, but what it knows.
This distinction matters for stewardship because the quality of a donor communication is almost entirely a function of specific knowledge. A great thank-you letter is great because it names the thing the gift paid for, in the voice the organization actually uses, referencing a relationship the writer actually remembers. None of that is a phrasing problem. All of it is a context problem.
Better prompt, same context: marginal improvement. Same prompt, better context: a different letter entirely.
The stewardship context pack
Build this once, keep it in a single document, and paste the relevant sections into any AI tool before you ask for anything. Five layers, in order of how much they change the output.
1. Voice, shown not described
Do not write "our tone is warm, professional, and mission-driven." Every organization writes that, and it tells the model nothing, because every organization believes it. Instead, paste in three to five paragraphs of real writing you were proud of: the best line from last year's annual appeal, a stewardship email a donor replied to, a paragraph from your executive director that sounded like a person.
Then add the negative space, which is usually more useful. List the words and constructions your organization does not use. "We never say 'the less fortunate.' We never open with 'On behalf of.' We don't use 'impact' as a verb. We don't use exclamation points in donor mail." Constraints do more work than adjectives.
2. Facts with numbers attached
The model cannot invent your programs, and when it tries, it hallucinates. Give it the real specifics: what each fund does, what a dollar amount actually buys, how many people you served last year, what a program cycle looks like, the name of the thing your donors care about most.
Write these as flat statements the model can pull from. "$5,000 funds one semester of tuition and books for one Presidential Scholar. Our 2025-26 cohort has 14 scholars. Median family income of a scholar's household is $38,000." Three sentences like that will improve an AI draft more than an hour of prompt tinkering.
3. Constraints and guardrails
Tell the model what it is not allowed to do. This is where most stewardship drafts go wrong, because the model's default instinct is to be effusive and to ask for money.
- Never include an ask in a stewardship touchpoint.
- Never promise an outcome the organization cannot guarantee.
- Never claim a percentage of a gift goes to programs unless the number is in the facts section.
- Maximum 180 words. Signature is always the ED's first name.
- No em-dashes.
Length limits in particular are worth being aggressive about. Left unconstrained, AI writes long, and long is the enemy of a stewardship note that gets read.
4. Gold-standard examples
Two or three complete examples of the exact output type you want will outperform any amount of instruction. If you want a good thank-you email, paste in two thank-you emails you actually sent and were happy with. The model reverse-engineers the pattern: structure, length, where the specific detail lands, how the close works.
If you have an example of a bad one, include it and label it as such. "Here is a draft we rejected, and here is why" teaches the boundary faster than a rule does.
5. The situation
Only now do you describe the moment you are writing for. Not "a donor gave $5,000," but the actual circumstances: a lapsed donor who gave for eight years and then stopped after a leadership change, now giving again after a personal conversation. A first-time donor who found you through a colleague. A board member who quietly covered a budget shortfall and asked not to be recognized.
You can do all of this without exposing a single donor record. Describe the situation, not the person. No name, no address, no giving history export, no CRM screenshot. The model does not need to know who they are to know what the moment requires. If your organization has a data policy, and it should, keep donor PII on your side of the line. Our AI stewardship guide goes deeper on privacy-safe workflows.
What this looks like in practice
The workflow is boring, which is why it works.
- Spend two hours building the pack. Most of it is copying and pasting writing you already have.
- Keep it in one document with clear section headers.
- At the start of any AI session, paste in sections 1 through 4. That is your standing context.
- Add section 5, the situation, and make your request.
- When a draft comes back wrong, do not rewrite the prompt. Ask what the model didn't know, and add that to the pack.
That last step is the whole discipline. Every bad output is a missing-context bug report. Fix the pack, not the prompt, and the fix applies to every future draft instead of just this one.
The compounding part
A prompt is disposable. A context pack is an asset. Six months in, a new development associate can produce donor communications that sound like your organization on day one, because the institutional voice is written down instead of living in the head of whoever has been there longest.
That is the quiet argument for doing this. Context engineering is not really about AI. It is about finally documenting the things your team knows but has never written down: how you talk, what you never say, what a gift actually buys. The AI just makes the cost of not having written it down suddenly visible.
Context makes execution better. It doesn't tell you what to execute. That's the other half of the problem, and it's the one Steward-Ship exists for: one reviewed, ready-to-run stewardship idea every morning, with the execution plan attached. Bring your context pack to it and you have both halves.
FAQs
What is context engineering?
Context engineering is the practice of assembling the right background information for an AI model before you ask it to do anything: voice samples, facts, constraints, and examples of good output. Prompt engineering is about wording the request well. Context engineering is about making sure the model has what it needs to answer the request correctly in the first place.
Why do AI-written donor letters sound generic?
Because the model is averaging across every nonprofit letter it has ever seen. Without your specific voice samples, program details, and constraints, the statistically safest output is the blandest one. The fix is not a better prompt or a better model. It is more and better context.
What should go in a stewardship context pack?
Five things: your voice profile with real samples, your organizational facts and program specifics, your hard constraints and forbidden phrases, two or three gold-standard examples of writing you were proud of, and the situational details of the specific donor moment you are writing for.
Is it safe to put donor information into an AI tool?
Treat donor records as confidential by default. Context engineering does not require donor PII. You can describe the situation in abstract terms, such as a five-year monthly donor at a mid-level giving tier whose gift lapsed after a payment failure, and get the same quality of draft without exposing names, addresses, or giving records. Check your organization's data policy and your vendor's terms before any donor data goes anywhere near a model.
How long does it take to build a context pack?
About two hours for the first version, mostly spent gathering writing samples you already have. After that it is a living document you update a few times a year as programs, numbers, and voice evolve.
Does this work with any AI tool?
Yes. Context engineering is tool-agnostic. The same pack works in a general-purpose chat assistant, in a CRM's built-in AI features, or in a custom instructions field. Tools with a persistent instructions or project setting are more convenient, because you paste the standing context once instead of every session.
How is this different from a brand style guide?
A style guide is written for humans and assumes shared judgment. A context pack is written for a model that has none, so it is more literal, more example-heavy, and more explicit about prohibitions. If you have a style guide, it is a good starting input, but it usually needs to be rewritten as concrete samples and hard rules before a model can use it well.