§ Volume I · Thesis
Grants as files,
read by agents.
an essay · 2026
I.Where grants live today
Trapped in web forms that AI cannot reach.
A typical grant platform is a web application. The proposal lives in
a database row; the sections render as textareas; the history is
whatever the platform chose to record. The user's tools — their
editor, their agent, their version control — watch from outside the
glass.
That was fine when the main thing you did with a draft was edit it
yourself. It is no longer fine. The best drafting partners in the
world now live one cd away, and they
do their best work on a directory of files, not a 6,000-token
prompt.
2023 was the year of the chatbot. 2024, RAG and finetuning. 2025,
MCP and tool use. 2026 will be the year
of the computer environment and filesystem.
— Alex Albert, Anthropic
The rest of this essay is the reasoning behind GrantKit: what
changes if a proposal is a set of files; why the filesystem is a
better substrate than a web UI for this kind of writing; and what
the cloud is still good for when files win.
II.Three reasons
Why files beat a web form.
i. Context
The agent reads everything, not a snippet.
A web form hands the model the single section you are editing. A
filesystem hands it the budget, last year's proposal, the
solicitation PDF, the reviewer's letter, and every response you
have drafted — and lets the model decide what to pull in. That
difference is the difference between a copyeditor who skimmed
the abstract and one who read the whole file.
ii. Provenance
Every edit is a reviewable diff.
Git is a log. A web "undo" is a guess. When your broader impacts
section drifts across three weeks of revisions, you want to see
the line where the outreach plan moved from "publications" to
"six summer REU slots," who made the change, and when. That is
what git log gives you. That is
not what a revision history sidebar gives you.
iii. Portability
The model is yours to choose.
Today, Claude. Tomorrow, a local model running on your laptop.
Next quarter, a model that does not exist yet. A grant stored as
plain markdown is not an AI lock-in bet. It is writing, held in
the same medium as writing has been held for forty years, and
it will outlive every AI vendor in the category.
III.What the cloud is for
Files for writing, cloud for sharing.
"Everything in files" sounds austere. It is not. A grant in flight
is rarely a solo document. Advisors read drafts, collaborators write
sections, program officers want a shareable link. None of this is
served well by passing a zipfile over email.
So GrantKit treats the cloud the way you treat GitHub: the files
are the source of truth on your machine; the cloud is the canonical
place where teammates see them, where a program officer clicks a
link, where permissions live. A push reconciles. A pull reconciles
back. The same mental model you already have for code.
The risk with any such system is silent data loss: you push a stale
version and overwrite a teammate's work without knowing. We built
conflict detection into the sync from day one. Every push checks
whether the cloud has moved since you last pulled; if it has, the
push stops and prints a plan. You choose what to do. Nothing is
overwritten without your say-so.
IV.The writing loop
Pull. Edit with your agent. Push.
The loop is the point. A grant is a long document written in small
motions: tighten the abstract by forty words, add a concrete metric
to broader impacts, reconcile the budget with the narrative, check
the citations. Each motion benefits from an agent that has the
whole corpus at its disposal. Each motion wants a diff, not a Save
button.
When the loop is fast, a proposal stops being a dread-object you
open twice a week and becomes something you edit the way you edit
code — incrementally, with confidence, with history. Deadlines
become less frightening because the last seventy-two hours are no
longer where the work compresses.
Write the next grant the
way you write code.
pip install grantkit