DEV Community: Vasili

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

Vasili — Mon, 29 Jun 2026 09:08:57 +0000

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.

GitHub: vassiliylakhonin/grantflow

If this direction is interesting, I would appreciate your reactions, issue, critique, or architecture review.

Stop Asking AI for Answers. Start Asking If the Evidence Is Ready.

Vasili — Mon, 29 Jun 2026 09:02:02 +0000

Most AI agents are optimized to produce an answer.

But in serious workflows, the answer is not the hard part.

The hard part is knowing whether that answer is supported well enough for a human to trust it, act on it, or escalate it.

That is the problem I am working on with Agenda Intelligence MD:

An evidence-readiness and trust-routing runtime for high-stakes AI-assisted decisions.

GitHub: vassiliylakhonin/agenda-intelligence-md

The problem: AI can summarize before it can be trusted

Summarization is useful.

But many real-world decisions are not blocked by the lack of a summary. They are blocked by uncertainty:

Which claims are actually supported?
Which claims are weak?
Which source categories are missing?
Who needs to act next?
Is this file ready for review?
Should this be escalated before a decision is made?

This matters in workflows like:

vendor evidence review;
RFP and procurement analysis;
AI vendor due diligence;
strategic infrastructure project rooms;
market-entry readiness;
sanctions-adjacent exposure triage;
corridor, maritime, and counterparty risk files.

In those settings, a polished AI-generated memo can be dangerous if it hides evidence gaps.

Agenda Intelligence MD is built around a different idea:

The next layer of agent infrastructure is not better summarization. It is knowing when an AI-generated brief is not ready to be trusted.

What Agenda Intelligence MD does

Agenda Intelligence MD turns messy input packs into structured human-review packets.

The inputs can be things like:

RFP responses;
vendor claims;
source packs;
risk files;
model cards;
project notes;
weekly status updates;
public documentation;
analyst-style briefs.

The output is not just a summary.

It is a structured review layer that surfaces:

supported claims;
weak or under-sourced claims;
missing evidence categories;
source coverage diagnostics;
owner actions;
decision-readiness routing;
escalation signals;
heuristic scoring.

The goal is not to replace human judgment.

The goal is to make the review surface clearer before a human makes a decision.

What makes it different from a normal AI summarizer?

A normal summarizer asks:

“What does this document say?”

Agenda Intelligence MD asks:

“Is this document ready to support a decision?”

That distinction changes the architecture.

Instead of treating the AI output as the final deliverable, the project treats it as something that must pass through a readiness layer.

For example, a vendor might claim that their AI product is safe for regulated enterprise use.

A summarizer can compress that claim into a nice paragraph.

Agenda Intelligence MD is designed to ask a more useful set of questions:

Is the claim linked to evidence?
Is the evidence first-party, third-party, stale, missing, or incomplete?
Are there standards, audit artifacts, security documents, or governance materials missing?
Does this need a procurement owner, legal reviewer, technical reviewer, or compliance escalation?
Is the brief ready for a decision, or only ready for more questions?

That is the difference between generating text and routing trust.

Architecture

The project is implemented as a Python package with multiple delivery surfaces around one core service layer.

It includes:

a CLI;
an MCP stdio server;
an HTTP API shell;
an A2A adapter;
JSON schemas;
validators;
evidence audit;
source coverage diagnostics;
heuristic scoring;
vertical worker profiles.

This makes it usable in several different modes.

You can inspect it locally through the CLI.

You can integrate it into an agent workflow through MCP.

You can expose structured behavior over HTTP.

You can experiment with A2A-style agent routing.

The interesting part is not just that these interfaces exist. It is that they point toward the same product idea: evidence-readiness should be a reusable layer, not a one-off prompt.

Quick start

After installing the package, the basic local flow looks like this:

pip install agenda-intelligence-md

agenda-intelligence doctor
agenda-intelligence validate-brief examples/agenda-brief.json
agenda-intelligence score examples/agenda-brief.json --evidence examples/source/evidence-pack.json
agenda-intelligence weekly-delta examples/strategic-infrastructure-bankability/status.synthetic.md

The commands are designed to answer practical questions:

Is the package installed correctly?
Does this brief match the schema?
How strong is the structure / evidence / decision-readiness?
What changed in a weekly status update?
Which claims are unsafe to repeat?
What evidence is still missing?

That last question is the most important one.

Because in real decision workflows, “what is missing?” is often more valuable than “what is the answer?”

Example: AI vendor evidence-readiness

One of the current discovery wedges for the project is AI vendor evidence-readiness for regulated procurement.

Imagine a buyer reviewing an AI vendor for an enterprise or regulated environment.

The buyer has:

an RFP;
vendor claims;
public documentation;
security pages;
model cards;
standards references;
maybe some missing or vague materials.

A normal AI assistant can summarize the vendor.

But a buyer does not only need a summary.

They need a review packet:

What claims are supported?
Which claims are marketing language?
Which security or governance documents are missing?
Which buyer questions remain unanswered?
What should be escalated before approval?
What can be reviewed now, and what cannot?

That is the kind of workflow Agenda Intelligence MD is designed to support.

It is not trying to be the decision-maker.

It is trying to prepare the decision surface.

Vertical profiles

The repository also includes vertical profiles and demo surfaces for several high-stakes workflows, including:

Middle Corridor Deal Risk Gate;
CIS Secondary-Sanctions Exposure;
Agentic Interaction Trust Gate;
Gulf Maritime Exposure Gate;
Kazakhstan Market-Entry Readiness Gate.

These are not generic chatbot personalities.

They are structured reasoning surfaces for evidence-heavy review workflows.

The pattern is:

input pack -> structured review packet -> evidence gaps -> owner actions -> decision-readiness route

That pattern is useful because many high-stakes workflows fail in the handoff between AI output and human responsibility.

Agenda Intelligence MD focuses on that handoff.

What this is not

This project is intentionally bounded.

It is not:

a factuality verifier;
a legal advisor;
a compliance approval engine;
a sanctions determination tool;
a financial or investment advisor;
an autonomous decision-maker;
a replacement for analyst review.

The scoring is heuristic.

It evaluates structure, source coverage, evidence labeling, and decision-readiness signals.

It does not prove that a claim is true.

That boundary matters.

The point is not to say:

“The AI is right.”

The point is to say:

“Here is what the AI-assisted packet can support, here is what it cannot support, and here is where a human needs to review.”

Why MCP and A2A matter here

MCP and A2A are interesting because they push agent systems toward composable infrastructure.

But composability also increases risk.

If agents can call tools, route tasks, and generate structured outputs, then they also need a way to communicate uncertainty, missing evidence, and escalation requirements.

Otherwise, agent systems become very good at moving unsupported claims through a workflow faster.

Agenda Intelligence MD is an experiment in making the trust layer explicit.

Not hidden in a prompt.

Not buried in a paragraph.

Not left to the final reviewer to reconstruct manually.

Instead, the runtime exposes readiness, gaps, and routing as structured outputs.

Why I built it

I started from a simple observation:

A lot of AI work focuses on making outputs more fluent.

But in serious workflows, fluency is not the bottleneck.

The bottleneck is whether the output is usable for a decision.

A beautiful memo with missing evidence is still a weak memo.

A confident recommendation with unclear source coverage is still risky.

A summary that does not show what it cannot support is not enough.

I wanted a system that treats evidence gaps as first-class objects.

Who should look at this?

You may find the project interesting if you are working on:

AI agents;
MCP servers;
A2A experiments;
procurement technology;
AI governance;
risk intelligence;
analyst workflows;
structured evaluation;
human-in-the-loop review;
decision-support systems.

The repo is especially relevant if you are asking:

How do we make AI-assisted workflows more reviewable before they become more autonomous?

What to inspect first

If you open the repository, I would suggest looking at four areas:

The CLI flow
Start with the examples and validation commands.
The schemas
The schemas show what the project treats as structured review output.
The MCP integration
This is useful if you are thinking about agent-tool interoperability.
The vertical profiles
These show how the same evidence-readiness pattern can be adapted to different domains.

The bigger idea

I do not think every AI agent needs to make more decisions.

I think many AI agents need to become better at saying:

this is supported;
this is weak;
this is missing;
this needs review;
this is not ready yet.

That is less flashy than autonomous decision-making.

But it is much closer to what many real organizations need.

The future of AI infrastructure will not only be about agents that can act.

It will also be about systems that know when not to act yet.

That is the layer Agenda Intelligence MD is exploring.

GitHub: vassiliylakhonin/agenda-intelligence-md

If this direction is interesting to you, I would appreciate your reactions, issues, critiques, or architecture reviews.