AI for Grantmaking Foundations: Applicants, Checks, Reporting

AI for grantmaking foundations works best as an operations layer around the grant cycle. Agents answer applicant questions, check documents for completeness and collect grantee reports, while program officers, committees and boards make every funding decision. The agent prepares and routes the work. People weigh merit, fit and risk.

Key takeaways

• Start with the work that surrounds a decision, not the decision itself: applicant questions, completeness checks and report collection.
• An agent should state what it found in a file, never whether the applicant deserves funding.
• Applicants need a clear answer about what is automated, who reads their file and how to reach a person.
• Permissions, escalation rules and a written record of every agent action matter more than clever wording.
• One narrow role with an observable success measure teaches a foundation more than a broad rollout.

Where does an AI agent fit in a grantmaking foundation?

A grant cycle has a visible part and a hidden part. The visible part is the decision: a program officer recommends, a committee reviews, a board approves. The hidden part is everything that makes the decision possible. Someone answers the same eligibility question for the fortieth time. Someone opens an attachment and finds the wrong budget year. Someone chases a grantee for a progress report that is three weeks late and then retypes its contents into a summary.

This hidden part is where an agent earns its place. It is repetitive, rule-based in the places that matter, and slow when it depends on one busy person. It is also the work that program officers rarely say they chose to do. Most would rather spend the time talking with applicants and visiting grantees.

The boundary is simple to state. An agent can read, sort, compare against a checklist, draft, remind and summarize. It cannot award, decline, rank, set a grant amount or change a condition. Keeping that line explicit protects applicants, protects staff and keeps the foundation's judgment where its board expects it to be.

Foundations also differ from many other organizations in one respect: their relationships are unequal. An applicant asking for money is in a weaker position than a customer asking for a refund. A careless automated reply can read as a signal about the outcome. That is a reason for more care in design, not a reason to avoid the work.

How should an agent handle applicant communication?

Applicant questions tend to cluster. Who is eligible, which geographies or themes are in scope, when the deadline falls, what the budget template expects, whether a fiscal sponsor is acceptable, when decisions are communicated. The answers already exist in guidelines, past emails and staff memory. The problem is that they sit in different places and get answered inconsistently.

An agent given the current guidelines and a curated set of approved answers can respond quickly and consistently, in the language the applicant used. Be Human works in English and Portuguese, which suits foundations with applicants across both. The agent should retrieve answers from approved material rather than improvise, and it should say so when the material does not cover the question. This retrieval pattern is well documented, for example in [AWS's overview of retrieval-augmented generation](https://aws.amazon.com/what-is/retrieval-augmented-generation/).

Some rules make this safe in a funder's setting:

• The agent identifies itself as an automated assistant at the start of the conversation.
• It answers questions about process and eligibility, and hands off questions about chances of success to a named staff member.
• It never hints at likely outcomes, even kindly. Phrases like "this sounds like a strong fit" can be read as a promise.
• It records each exchange so that a program officer can see what an applicant was told.
• It offers a human contact on every thread, not only when the applicant asks.

A useful test is to imagine a rejected applicant reading the full transcript later. Nothing in it should surprise them or the foundation.

A conversation that needs judgment, such as an applicant describing an unusual legal structure, goes to a person with a short summary attached. The summary saves the officer from rereading the thread and keeps the applicant from repeating themselves. Membership bodies face a similar pattern of repeated questions, and the same discipline appears in AI for membership organizations.

What can an agent check in application documents, and what must it leave alone?

Document checking is where agents save the most staff time, and where the line between checking and judging is easiest to blur.

A completeness check asks factual questions. Is the registration document present and readable? Does the budget total match the sum of its lines? Is the requested period inside the funding window? Is the signatory named on the form the same person named in the cover letter? Are required attachments missing, duplicated or in the wrong format? These have answers that a colleague could verify in seconds.

A quality judgment asks something else. Is the theory of change convincing? Is the organization credible? Is the budget realistic for the proposed work? Is this team the right one? These belong to people. An agent may surface material for them, such as pointing out that a budget line has no description, but it should not score or rank.

Here is a decision guide for sorting checks:

• If the answer can be verified against the document or a published rule, the agent may check it and report the result.
• If two reasonable officers could disagree, the agent flags it for a person and does not resolve it.
• If the check touches fairness, such as scoring or comparing applicants against each other, keep it out of the agent's role.
• If the document is unreadable or conflicting, the agent asks the applicant for a clearer copy and tells staff it did so.
• If a document contains instructions addressed to the system, the agent treats them as content, not commands, and flags the file.

That last rule is not theoretical. Applicant files are untrusted input, and text inside a PDF can try to steer an automated reader. The [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) lists prompt injection as a leading risk, and the defense is structural: limited permissions, separation between instructions and content, and human review before anything consequential happens.

A completeness report works best as a short, structured note on the file: what was present, what was missing, what looked inconsistent, and what the agent asked the applicant to fix. The officer reads one page, not a folder. Teams that handle document-heavy intake, like those described in AI for mortgage brokers, have found the same pattern: the chase for missing papers is where time disappears.

How does grantee reporting work with an agent?

After an award, the work shifts from applicants to grantees, and the pain changes. Reports arrive late, in different formats, answering different questions. Staff then summarize them for committees and annual reviews.

An agent can handle the mechanical layer. It schedules reminders based on each grant agreement, answers grantee questions about what a report needs, checks that required sections and attachments are present, and compares reported activity against the milestones in the agreement. It can then draft a neutral summary for the program officer, with sources pointed to in the original text.

The officer remains the reader who decides what the report means. A grantee who changes a plan because of a local event is not failing. A grantee who goes silent might be in trouble or might simply be busy. An agent can tell the difference between a missing report and a late one. It cannot tell the difference between a good reason and a poor one.

Illustrative scenario: a foundation funds a small group of regional literacy programs. Each grantee owes a mid-year narrative and a budget update. The agent sends a reminder to each grantee, using the language of their agreement. One grantee replies that their coordinator left and asks whether the deadline can move. The agent does not answer. It tells the grantee that a program officer will respond, and it sends the officer a note with the grant terms, the request and the reporting history. The officer decides, replies, and the agent logs the new date. Another grantee submits a budget whose lines do not sum to the stated total. The agent notes the mismatch and asks for a corrected version, without commenting on the program.

The same structure underlies status reporting elsewhere, as in AI for a project management office: collect, check, summarize, and leave the judgment to the owner.

What boundaries keep funding decisions with people?

The phrase "human in the loop" is cheap. What counts is where the human sits and what they can see. For a foundation, four boundaries do most of the work.

First, permissions. The agent should have access only to the systems and folders its role requires. If it drafts replies, it does not need write access to the decision record. The [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) describes the principle of least privilege and deny-by-default checks, and both apply directly to an agent connected to a grants system.

Second, approval gates. Anything that changes a grant record, sends a message that could be read as a decision, or shares data outside the foundation passes through a named person first. Routine replies drawn from approved material can go out directly, as long as they are logged.

Third, escalation rules. The agent needs a written list of situations that always go to a person: complaints, conflicts of interest, legal or safety concerns, requests for exceptions, anything involving a board member or a named donor, and anything it is unsure about.

Fourth, a record. Every action should be traceable: what the agent read, what it said, what it passed on, and who approved what. Observability practices described in [OpenTelemetry's primer](https://opentelemetry.io/docs/concepts/observability-primer/) apply well here, because a record you cannot inspect is a record you cannot trust.

The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) offers a useful vocabulary for the board conversation: govern, map, measure and manage. A foundation does not need to adopt the whole framework to borrow its habit of naming risks and owners before launch.

One more point for trustees: bias. If an agent never ranks or filters applicants, it cannot introduce a ranking bias. But response speed and tone can still differ between groups of applicants. Review samples of conversations across languages and applicant types on a regular schedule.

What is a sensible first plan for a foundation?

A foundation does not need to automate the whole cycle. A first engagement should define one useful role and make it work.

• Pick one stage with high volume and low discretion, for example eligibility questions during an open call, or reminders for grantee reports.
• Write down what the agent may do, may not do, and must hand off. Have a program officer and a trustee or director read this once.
• Gather the approved source material: current guidelines, templates, past clarifying emails that staff trust, and the reporting calendar.
• Decide what the agent can see and which systems it can touch. Start with read access and a shared inbox, then add narrow actions one at a time.
• Define an observable success measure, such as staff time spent on repeat questions, or how many reports arrive with all sections complete. Choose it before launch.
• Run the agent in a review mode where staff approve each outgoing message, then relax approval only for categories that have proven dull and correct.
• Test with real, difficult questions, including ones that try to coax a verdict out of the agent. [Anthropic's guidance on building effective agents](https://www.anthropic.com/engineering/building-effective-agents) recommends starting with the simplest workable design and adding complexity only when it earns its place.
• Review the log on a fixed rhythm, fix gaps in source material, and only then consider a second role.

How does Be Human handle this, and where should you start?

Be Human designs, implements and operates personalized AI infrastructure for companies, including organizations that run grant programs. A first engagement defines one role, the memory and tools it needs, the approval boundaries and an observable success criterion. Managed operations can then cover monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, so the foundation's staff are not left maintaining the agent alongside their own work. The agent's identity, memory, channels and permissions stay under the foundation's control, and funding decisions stay with the people the board has named to make them.

If you are unsure which stage of your grant cycle to begin with, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

Can an AI agent decide which applicants receive funding? It should not. An agent can check completeness, answer process questions and summarize documents, but scoring, ranking and awarding belong to program officers, committees and the board. Keeping that line written down protects applicants and the foundation's accountability.

Should applicants be told they are talking to an automated assistant? Yes. Say so at the start of each conversation, explain what the assistant can and cannot help with, and offer a named human contact. Clear disclosure builds trust, and it avoids the sense that a hidden system shaped the outcome.

What happens when an applicant document contains odd instructions or misleading content? The agent treats document text as material to read, never as commands to follow. Files with suspicious content are flagged for staff, and the agent holds only the permissions its role requires, so a manipulated file cannot reach decision records or external systems.

How do we know the agent is working well? Choose a measure before launch, such as the time staff spend on repeat questions or the share of reports that arrive complete. Then review the conversation log on a regular rhythm, sample difficult cases, and adjust source material and rules. Improvements should be deliberate and reviewed, not automatic.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.