The problem
Our enterprise clients applied for EU and national grants all the time. Each application meant days of work: reading the call, finding the right company data, and writing every section to fit the scheme's rules.
Most of that is structured work with a lot of reading. That made it a good fit for an LLM pipeline, as long as the output could be trusted.
How it works
The pipeline parses the grant call, splits it into its sections and drafts each section with its own prompt.
Every section gets context from two sides. One module injects the grant's guidelines and the EU or scheme rules. The other is RAG over the client's own documents: Salesforce and Bynder for one client, shared drives and APIs for others, plus partner sources when there were any.
We kept it model-agnostic. Each stage can use a different GPT variant, and clients with data-residency needs ran on Azure-hosted EU models.
The hard part: two good sources that disagree
Sometimes a company's own guidelines pulled against a grant requirement. The model never said so. It quietly picked a side and wrote a fluent section, so reviewers could not tell why a draft felt off.
We added an LLM judge after drafting. Its criteria come from both the grant rules and the company's internal metrics. It scores every section from 1 to 10, names the weak spots, and flags the sections where the two sides conflict. The flag goes to the expert, who decides: keep the draft or fix the source.
The criteria themselves come from a separate eval workflow, so they can change without touching the drafting prompts.
Where it ended up
Live with 4 enterprise clients. A first draft takes about two minutes instead of days, and an expert review is the only manual step.
Our rough estimate of the labour saved across clients is around €360k a year: teams that needed several grant writers now need one person working with the product.
The same pipeline was later reused for HR screening on a client's applicant tracking system.