Vasili

Posted on Jun 29

Grant Writing Does Not Need Another Chatbot. It Needs Infrastructure.

#ai #python #opensource #mcp

Most AI tools for grants start with the same assumption:

The hard part is writing the proposal.

I think that is only partly true.

For serious NGO, donor, and implementer workflows, the harder problem is not producing text. It is controlling the proposal workflow around that text:

Is the proposal aligned with donor requirements?
Are required sections missing?
Did a human review the risky parts?
Are citations and grounding signals traceable?
Can an agent safely start, pause, resume, and export work?
Can the system explain why a proposal is ready — or not ready — for submission?

That is why I built GrantFlow.

GrantFlow is an agent-native API for governed grant-proposal workflows.

It is not a grant-writing chatbot.

It is infrastructure for AI agents and workflow systems that need donor-aware drafting, preflight checks, human-in-the-loop review, grounding checks, audit trails, and export-ready evidence packs.

GitHub: vassiliylakhonin/grantflow

The problem: grant workflows are not just writing workflows

A grant proposal is not a blog post.

It has structure, funder logic, compliance expectations, review loops, evidence requirements, attachments, approvals, and formatting constraints.

For recurring donor cycles, teams often need to manage:

EU logframes;
USAID-style results frameworks;
FCDO logframes;
World Bank / IFC results chains;
MEL plans;
indicators;
budgets;
risk sections;
safeguarding language;
citation and evidence packs;
internal review comments;
final DOCX / XLSX export requirements.

A chatbot can help generate text.

But grant operations need something more controlled:

A governed workflow layer that agents can call safely.

That is the idea behind GrantFlow.

What GrantFlow does

GrantFlow gives AI agents and workflow systems an API layer for proposal operations.

It supports the core lifecycle:

Discover agent capabilities and tools.
Register or onboard an agent identity.
Run donor/readiness preflight checks.
Start generation with an idempotency key.
Pause for human review where needed.
Inspect status, quality, citations, grounding, and lifecycle events.
Export reviewable deliverables and evidence packs.

The point is not to let an AI agent blindly submit grant proposals.

The point is to keep agent-driven proposal work inside reviewable, auditable boundaries.

Why “agent-native” matters

A lot of software assumes a human is clicking through a dashboard.

GrantFlow assumes that the next proposal operator may be an AI agent.

That agent still needs operational controls:

discovery;
typed contracts;
authentication;
scopes;
idempotency;
preflight gates;
human-in-the-loop checkpoints;
structured errors;
audit events;
deterministic smoke tests;
export contracts.

GrantFlow exposes those controls as API surfaces rather than hiding them inside a chat UI.

That is the difference between a chatbot and infrastructure.

Not a chatbot. Infrastructure.

A chatbot asks:

“What proposal should I write?”

GrantFlow asks:

“Can this proposal workflow be safely started, reviewed, grounded, exported, and audited?”

That difference changes the product shape.

GrantFlow includes:

HTTP API surfaces;
MCP-style stdio tool server;
agent discovery endpoints;
sandbox agent registration;
self-serve onboarding;
OAuth client-credentials flow;
credential introspection;
credential rotation and revocation;
human-in-the-loop approval checkpoints;
quality and trust surfaces;
export payloads;
donor-aware requirements;
DOCX / XLSX / ZIP evidence-pack export paths.

This is designed for agent systems, not for one-off prompt sessions.

Example: a proposal agent should not just write

Imagine an NGO team is preparing a recurring USAID, EU, or FCDO proposal.

A naive agent workflow might look like this:

User uploads notes -> AI writes proposal -> team edits manually

That can save time, but it does not solve the operational problem.

A governed workflow should look more like this:

Discover donor requirements
-> run bid/no-bid or readiness preflight
-> ingest source material
-> generate controlled proposal sections
-> pause for human review
-> inspect grounding and quality signals
-> resolve high-severity findings
-> export DOCX/XLSX/evidence pack

GrantFlow is built around that second pattern.

Donor-aware proposal operations

GrantFlow supports donor-aware structures for major grant and development-finance workflows.

Examples include:

USAID;
EU / INTPA;
World Bank / IFC;
GIZ;
U.S. State Department;
FCDO;
AFD;
JICA;
ADB;
and a broader 40+ donor catalog through a generic donor strategy.

Each donor path can define its own structure, such as:

table of contents schema;
MEL schema;
role-specific prompts;
RAG namespace;
submission requirements;
required DOCX sections;
required XLSX sheets.

This matters because donor workflows are not interchangeable.

A generic proposal draft is often not enough. The output has to match the funder’s expected structure.

Human-in-the-loop by design

GrantFlow keeps human review in the workflow instead of treating it as an afterthought.

It includes HITL checkpoints for stages such as:

architect;
table of contents;
MEL;
logframe.

It also tracks:

critic findings;
review comments;
lifecycle status;
readiness warnings;
audit-friendly job events;
traceability endpoints.

This is important because “AI-assisted” should not mean “unreviewed.”

The goal is controlled acceleration, not uncontrolled automation.

Trust report before export

Before export, GrantFlow exposes a quality surface with a trust summary.

The trust summary can return verdicts such as:

pass;
conditional;
fail.

A conditional or failed verdict means at least one gate is not cleared.

This allows an agent or reviewer to know whether the workflow can proceed to export, or whether more review is needed.

That is a useful primitive for agent systems.

Agents should not only generate content.

They should know when not to proceed.

AI-use disclosure

Funders are increasingly paying attention to AI use in proposal workflows.

GrantFlow includes an AI-use disclosure endpoint that creates a machine-readable record from what the job already recorded, including:

generation mode;
models;
grounding mode;
trust signals;
human review state;
boundaries;
a human-readable paragraph.

This is not a compliance certification.

It is a transparency record.

That distinction matters.

Quick start

GrantFlow includes a hosted deterministic demo and a local development path.

Hosted demo:

curl https://vassilbek-grantflow.hf.space/demo/run | python3 -m json.tool
curl https://vassilbek-grantflow.hf.space/donors  | python3 -m json.tool

Run locally:

cp .env.example .env
make bootstrap-dev
source .venv/bin/activate
uvicorn grantflow.api.app:app --reload

curl http://127.0.0.1:8000/demo/run | python3 -m json.tool

For agent runtimes that prefer stdio tools, GrantFlow also exposes an MCP-style tool server.

MCP-style tool server

GrantFlow includes MCP-style tooling for runtimes that use tools/list and tools/call.

The tool surface includes operations for:

onboarding an agent;
creating a session;
introspecting credentials;
exchanging OAuth tokens;
rotating and revoking credentials;
registering a sandbox agent;
ingesting text;
running preflight;
starting generation;
checking status;
checking quality;
reading lifecycle events;
approving HITL checkpoints;
listing pending review items;
getting export payloads;
running a sandbox happy path.

This makes GrantFlow useful not only as a grant workflow backend, but also as an agent-integration experiment.

What this is not

GrantFlow is intentionally bounded.

It is not:

legal advice;
compliance advice;
financial advice;
grant-eligibility advice;
a factuality verifier;
a donor portal automation bot;
a replacement for human review;
a one-off chatbot UI for end users.

It enforces evidence structure and grounding signals.

It does not prove that every claim is true.

A human must review before submission.

That boundary is not a weakness. It is part of the design.

Governed proposal infrastructure should make its limits explicit.

Current maturity

GrantFlow is still early.

There are no customer pilots yet.

The benchmark numbers in the repository are illustrative demo baselines, not measured customer results.

The donor paths most built out today are:

EU;
FCDO;
USAID, depending on use case and operating constraints.

That is important to say clearly.

This is open-source infrastructure looking for real-world validation, not a finished enterprise product with proven ROI claims.

Who should look at this?

GrantFlow may be interesting if you are working on:

AI agents;
MCP servers;
nonprofit technology;
grant management;
proposal operations;
human-in-the-loop systems;
AI governance;
document generation;
donor compliance workflows;
workflow automation;
RAG-backed drafting;
auditable AI systems.

It is especially relevant if you are asking:

How do we let agents help with proposal work without removing governance, review, and traceability?

What to inspect first

If you open the repository, I suggest starting with:

The README
It explains the core workflow and boundaries.
The donor catalog
This shows how funder-specific requirements are represented.
The MCP server
This is useful if you are building agent runtimes or tool integrations.
The trust report surface
This shows how export-readiness is communicated.
The HITL flow
This is where the project becomes more than text generation.

The bigger idea

The future of AI in proposal workflows should not be:

“Let the model write everything.”

It should be:

“Let agents accelerate the workflow, while the system preserves structure, review, grounding, traceability, and export controls.”

That is the layer GrantFlow is exploring.

Grant writing does not need another chatbot.

It needs infrastructure that agents can call safely, operators can audit, and reviewers can trust.