Where AI agents can genuinely help program teams

There is a version of this article that promises AI will run your program. This is not that article. Program work is mostly judgement applied to incomplete information about people, and that is the part least suited to handing over.

What AI is genuinely good at is the layer underneath: reading a lot of text quickly, restating it consistently, and noticing when something is missing. That turns out to cover a meaningful share of what program teams spend their week on.

The test worth applying

Before using an agent for a task, ask three questions:

• Is the output checkable? Can a human verify it in seconds against the source, or would checking cost as much as doing it?
• Is being wrong cheap? A mis-summarised application that a reviewer reads alongside the original is cheap. An automated rejection is not.
• Does it need context the model does not have? Anything that depends on a promise made in a call, or on knowing this applicant is a returning one, will go confidently wrong.

Tasks that pass all three are worth automating now. The rest are worth revisiting later.

Triaging inbound questions

During an open round, the same twenty questions arrive hundreds of times. An agent with access to your program's own documentation can answer the repeat questions immediately and route the genuinely novel ones to a person.

Two design choices decide whether this helps or embarrasses you. First, ground it strictly in your own published material and have it say "I don't know, here's who to ask" rather than improvise — a plausible wrong answer about eligibility is worse than no answer. Second, make the handoff to a human obvious and one click away. People tolerate a bot that knows its limits; they resent one that traps them.

Summarising applications for reviewers

This is the clearest win on the list. A consistent one-paragraph summary against the same structure — what they do, what they are asking for, what stage they are at — lets a reviewer triage fifty applications in the time it used to take to read twelve.

Keep the original one click away and make clear the summary is a summary. The failure mode is reviewers deciding from the summary alone, which quietly outsources your selection criteria to a language model. Summaries are for ordering the queue, not for deciding what is in it.

Checking completeness

A boring, high-value use: read each submission and report what is missing or internally inconsistent — a budget that does not add up, a referee with no contact details, a required section left as a placeholder. This is checkable, cheap to get wrong, and removes a whole category of back-and-forth before review starts.

It also benefits applicants directly if you run it at submission time and let them fix things while the round is open.

Surfacing risk in a cohort

Mid-programme, the useful question is "who is quietly falling behind?" The signals are usually already there — missed submissions, declining session attendance, a check-in form that stopped being filled in — just spread across records nobody reads together.

An agent that assembles that into a short weekly list for the program manager is a genuine help. What it must not do is act on it. The output is "these six people are worth a conversation", not an automated email to those six.

Drafting the things you write every week

Session recaps, cohort updates, funder reports, reminder copy. The content exists in records; the work is phrasing it. Drafting is low-risk because a human reads it before it goes out, and the time saved is real.

Where this goes wrong is voice. Programs that let AI write participant-facing copy unedited end up sounding like every other program, which costs more than the hour it saved.

What to keep human

• Selection decisions. Beyond the reputational risk, scoring on model output bakes in whatever the model finds fluent — which correlates with confident, practised writing rather than with merit.
• Anything delivered without review. Especially rejections and anything touching money or eligibility.
• Pastoral conversations. The participant who is struggling needs a person, and will remember which they got.

Three practical cautions

Tell people. If an agent answers support questions or summarises applications, say so. Discovering it later reads as deception even when nothing was hidden.

Mind what you send. Applications contain personal data that applicants gave you for one purpose. Check what your tooling retains and whether it trains on your inputs before pasting a cohort into it.

Keep the manual path alive. If the agent is the only way to get an answer, an outage becomes a program incident. It should always be the fast path, never the only one.

A sensible starting point

Completeness checking at submission, and consistent summaries for reviewers. Both are checkable, both fail cheaply, both save hours in exactly the week you have none, and neither touches a decision. Once those are routine, add question triage — grounded in your own documentation, with a visible way to reach a person.

← All articles