AI & Tools · 11 min read
Why generic AI fails at grant writing — and what we learned building a specialized one.
A grant proposal isn't a document. It's a translation problem — converting the work an organization actually does into the language a specific funder uses to evaluate it.
Ask a general-purpose model to write a grant proposal and you get something that reads well and says nothing. The prose is competent. The structure is conventional. The transitions are smooth. And every specific claim in it is either generic enough to be worthless or specific enough to be invented.
We spent most of our first six months trying to fix that with better prompts. It does not work, and understanding why it does not work is the whole design problem.
A grant proposal is not a writing task. It is a translation task. It converts what an organization actually does — the caseload ratios, the retention numbers, the reason the program moved from two sites to four — into the evaluation language of one specific funder, who has their own priorities, their own vocabulary, and their own institutional history of what a good application looks like. Both halves of that translation are private information. The model has neither unless you hand it both, in a form it can cite.
So the work is not prompt engineering. It is building the retrieval layer underneath: the organization's evaluations, budgets, prior awards, program descriptions, board minutes, outcome data, and the last four applications it sent to this same funder. Then constraining generation to what that layer can actually support.
That constraint is where most of the engineering effort goes, and it is the opposite of the direction most AI writing tools push. A general model is rewarded for fluency. A grant model has to be rewarded for restraint.
Three rules came out of our early builds, and all three survived contact with real users.
First: every substantive claim must trace to a source document, and the interface must show the trace. Not a footnote the writer can ignore — a visible link that opens the page and highlights the sentence the claim came from. Writers do not trust drafts they cannot audit, and they are right not to. The citation is not a compliance feature; it is the thing that makes the draft usable at all.
Second: when the library lacks evidence for a section, the correct output is a flagged gap, not confident filler. This sounds obvious and is extremely difficult to implement, because the failure mode of a language model is precisely to produce plausible text in the absence of information. We had to build explicit coverage checks — does the library contain anything that answers this prompt? — and route the negative case to a different interface entirely: a short list of what is missing, and where it would normally live.
Third: some sections should never be auto-drafted at all.
The last one is the least intuitive and the most important. Community context, lived-experience narratives, and any paragraph that describes what a specific person said in a specific room — these are exactly where a fluent fabrication does the most reputational damage. Not to us. To the organization, in front of a funder relationship that may have taken a decade to build. A program officer who recognizes a mischaracterization of a community they fund does not conclude that the software was wrong. They conclude that the applicant was careless.
We hold the model back there on purpose and give the writer structure instead of sentences: what changed in the last twelve months, who told you, what did they say, what did you do about it. Four questions produce a better paragraph than four hundred generated words, and the paragraph is true.
There is a second-order failure worth naming, because it took us longer to see. Generic AI does not just write vague proposals — it writes proposals that all sound the same. Program officers read dozens of applications per cycle. The homogenization is visible from the outside, and by 2026 it is actively penalized. Several of the funders our design partners work with have added language about authenticity to their guidelines. A tool that makes your application indistinguishable from forty others is not saving you time; it is spending your credibility.
Specialization also changes what the model needs to know about the reader. A federal reviewer scoring against a published rubric is a different audience from a family foundation program officer with discretion and a personal relationship to the field. The same underlying facts should be assembled differently for each. That is not a tone setting. It is a different argument, ordered differently, with different evidence in the first paragraph.
None of this makes for an impressive demo. A general model produces a full draft in eleven seconds. Ours pauses, tells you that your most recent third-party evaluation is from 2023 and the funder asks for outcomes within twenty-four months, and refuses to write the impact section until you resolve it.
Users hate that for about a week. Then they stop rewriting drafts from scratch, and the objection disappears.
The result is a slower-feeling tool that produces usable output. Generic AI produces fast output that has to be rewritten from scratch, which is not a time saving — it is a time transfer, from the drafting stage to the editing stage, plus the cost of catching whatever was invented along the way. Only one of those actually gives anybody their week back.