§ 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 why checking and building belong in that same filesystem, not in a separate app.

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 a linter is for

Files you can check, not just edit.

Being a file unlocks more than an agent's attention. It unlocks every tool built to operate on files: a linter, a compiler, a CI runner, a diff viewer. A proposal locked in a database can only be checked by whatever bespoke validator a platform's engineers had time to build into their UI. A proposal stored as markdown can be checked by anything — the CLI on your laptop, an MCP server your agent calls mid-draft, a GitHub Action that runs on every commit. Same rule pack, same result, wherever the check happens.

So GrantKit ships the rules as data, not as logic buried in a web app. Each funder — NSF, Nuffield, PBIF — gets a versioned YAML rule pack: page and word limits, required sections, placeholder detection, budget bounds checked against BLS wage data and GSA per-diem tables. Every failure names the rule that caught it. When a funder changes a threshold, the fix is a pull request to a YAML file, not a deploy.

That is the linter half of the thesis. The other half is the compiler: once a draft passes, something still has to become the review page a colleague reads, the copy-paste blocks a portal wants, and the PDF a program officer opens. grantkit build does that from the same files grantkit check just cleared. Two commands, one source of truth, no separate export step to keep in sync by hand.

IV.The writing loop

Edit. Check. Build.

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, run grantkit check, fix what it flags. Each motion benefits from an agent that has the whole corpus at its disposal. Each motion wants a diff, not a Save button — and a check it can run before anyone else sees the draft.

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; grantkit build can compile a submission-ready draft the moment grantkit check goes clean, any night you want to see where you stand.

Ship the next grant the way you ship code.

View on GitHub → Read the docs

pip install grantkit