Building AI Agents for Research Administration: A Budget Application Assistant
What if a principal investigator could get a realistic first-pass budget before anyone in research support had opened a spreadsheet? A look at what that agent would need to know, what it should never be trusted to decide alone, and why the gap it closes matters more than the intelligence behind it.
A PI has 12 million DKK over five years. How many PhDs and postdocs can they realistically afford?
It sounds like a simple question. In most institutions, it isn't a quick one. A PI emails on a Tuesday afternoon, three weeks before a deadline, asking something close to this, and answering it properly means someone in finance opening a costing template, checking current salary steps, working out pension and overhead, and running a few scenarios by hand. Days, not minutes, is the normal turnaround — not because the sums are difficult, but because the people who can do them accurately are already stretched across a dozen other proposals.
None of that delay is anyone's fault. It's just how the work is structured. But it does mean that researchers routinely start writing proposals without knowing whether the numbers in their head are anywhere close to real. This piece is about a narrower, more practical question: could an AI agent give a PI a decent first draft of that answer, in minutes, without pretending to replace the person who signs off on the budget?
A conversation, not a form
Picture a PI opening a chat window rather than an email to the project controller.
I have a total budget of 12 million DKK over five years. Approximately how many PhDs and postdocs could I include?
Before I estimate: which funding programme is this for? Which university's salary tables should I use? Should I assume standard institutional overhead? And are any major equipment purchases expected?
Horizon Europe, use the institution's published salary tables, standard overhead, no equipment for now.
Using current published salary tables and standard Horizon Europe overhead, a PhD costs roughly 550,000–600,000 DKK per year fully loaded (salary, pension, overhead), and a postdoc roughly 750,000–820,000. On 12 million over five years, that's about 2.4 million per year. A realistic mix might be two PhDs and one postdoc, which would use most of the annual budget with some room for consumables and travel. Would you like me to show a few alternative combinations, or account for other cost lines first?
This is what separates an agent from a calculator: it gathers the assumptions that actually affect the outcome before doing any arithmetic. Only once those are settled does it produce a number worth looking at.
That answer is still not a budget. It's a sketch — closer to what an experienced colleague might say off the top of their head over coffee, except available immediately, and open to being pulled apart and re-run as many times as the PI wants before anyone else gets involved.
The value is in what happens next, because the PI rarely stops at the first answer.
What if I replace one PhD with two research assistants?
What if the project runs four years instead of five?
Can I still afford equipment worth 2 million?
Each of these is a small recalculation. None of them is hard, individually, for someone who does this every day. But strung together, in the early stages of thinking through a proposal, they represent exactly the kind of back-and-forth that currently either doesn't happen at all — because nobody wants to bother finance with five "what if" questions before the idea is even solid — or happens slowly, over several email threads, while the PI's actual writing time ticks away.
The cost of not knowing early
Most of the friction in grant budgeting isn't complexity. It's timing. A researcher decides to apply for funding, has a rough sense of scale, and then has to wait — sometimes days — before getting any indication of whether their instinct about staffing is realistic. In that gap, one of two things tends to happen: the proposal gets written around an assumption that later turns out to be wrong, requiring a rewrite of the work plan; or the researcher simply doesn't ask, and submits something under-resourced or over-ambitious because checking felt like too much friction for a "quick question."
Neither outcome is good, and neither is really about budgeting competence. It's about the early planning phase having no fast, low-stakes way to test an idea against reality. A PI doesn't need an institutionally approved figure at the sketching stage. They need something roughly right, quickly, so they can decide whether the idea is worth three weeks of writing.
An agent that can hold that early conversation doesn't remove the need for research support — it changes when research support gets involved. Instead of being the first checkpoint, the finance team becomes the validation step for something that already has shape. That's a better use of everyone's time, including the PI's.
The agent estimates. It does not approve. Final budgets still go through institutional review, because salary agreements, overhead models, pension schemes, and funder-specific eligibility rules vary — often in ways an AI system won't have current or complete visibility into, and in ways that carry real financial and compliance consequences if got wrong. Project economists and research support staff remain the people responsible for the number that actually gets submitted.
What the agent would need to reason well
None of this requires anything exotic. The interesting part isn't the AI model — it's the plumbing around it, and being honest about what each piece can and can't be trusted to do.
The budget assistant is only one example. The more interesting idea is that the same architecture could support many different AI agents across research administration. Natural language understanding, trusted institutional data, deterministic calculations, and human validation form a reusable design pattern — not a one-off built for budgeting.
Understanding the question
The PI's question arrives as ordinary language, not a form. "Roughly how many PhDs and postdocs" has to be parsed into something calculable: a total budget, a duration, and a staffing category. This is the part large language models are genuinely good at — turning loose phrasing into a structured request — provided the request is then handed off to something that can actually calculate, rather than left to the model to estimate from memory.
Grounding the numbers
Salary estimates should come from actual published salary tables and current collective agreements, not from whatever the underlying model happened to have seen during training. Employment cost data — pension contributions, employer costs, standard overhead percentages — needs to sit in a structured, regularly updated source the agent queries, not in the model's general knowledge. This is the difference between an agent that's occasionally right by coincidence and one that's consistently right because it's reading the same tables a human would.
Doing the arithmetic properly
Budget calculation is not a task to hand to a language model directly. Multiplying salary by duration, adding pension and overhead, comparing scenarios — this belongs in a dedicated calculation engine that the agent calls, the same way a human would open a spreadsheet rather than do it in their head. The model's job is to work out what to calculate and how to explain it; the engine's job is to get the sums right, every time, the same way.
Knowing the rules that apply
Overhead models differ by funder. Some funding programmes cap certain cost categories or exclude specific staff types. Institutional costing rules may apply differently depending on project type. This is where historical templates and funding programme rules earn their place in the architecture — not as background colour, but as constraints the calculation engine has to respect before it offers a scenario as plausible.
Keeping a human in the loop
However good the estimate, it should arrive labelled clearly as a draft, with its assumptions stated in plain language — which salary table, which overhead rate, which year's figures — so that when a research administrator does review it, they're checking stated assumptions rather than reverse-engineering a black box.
None of these pieces is individually novel. What makes the agent useful is that they're wired together so the PI experiences one conversation, rather than needing to know which system holds which piece of the puzzle.
Where this gets harder in practice
It's worth resisting the temptation to describe this as solved. A few things make it genuinely difficult:
- Salary data goes stale. Pay scales change annually, sometimes mid-year through collective agreements. Whatever feeds the agent needs an owner and a maintenance rhythm, or it will quietly drift out of date.
- Overhead isn't one number. Institutions often apply different rates depending on funding source, cost type, or even department, and those rules change with policy updates. Encoding this accurately is more work than it looks, and getting it slightly wrong is worse than admitting uncertainty.
- Funder rules are inconsistent by design. Two funders can define "personnel costs" differently. An agent that generalises across funders risks giving a confidently wrong answer for the one that doesn't fit the pattern.
- Confidence is a design problem, not just a technical one. A tool like this is only safe if it's visibly a draft. If it starts to look authoritative — a clean number in a clean interface — people will treat it as final, and that's precisely the failure mode to design against.
None of this argues against building it. It argues for building it modestly, with the estimate clearly framed as a starting point and the underlying data treated as something that needs ongoing care, not a one-off import.
One example of a broader pattern
The budget assistant is a useful case precisely because it's small and concrete. But the same shape — natural language in, structured rules and reliable calculation underneath, human sign-off before anything becomes real — applies to a fair amount of the repetitive reasoning that currently sits with research administrators and PIs alike:
- Recruitment planning, working out realistic timelines and cost implications of hiring decisions
- Equipment planning, checking depreciation rules and procurement thresholds against a proposed purchase
- Project amendments, drafting the reasoning for a budget reallocation before it goes to formal review
- Reporting deadlines, tracking what's due when across a portfolio of grant agreements
- Cost reallocations, checking eligibility before a transfer between budget lines is proposed
- Grant agreement interpretation, surfacing the relevant clause instead of someone re-reading a fifty-page agreement from scratch
- Internal approval workflows, routing a request to the right person with the right context already attached
None of these agents will be individually remarkable. Their value is cumulative — a few hours a week returned to the people who actually have to think, not just process.
That's probably the most honest way to describe where AI agents fit in research administration right now. Not as a transformation of the work, but as a way of narrowing the gap between "someone asked a reasonable question" and "someone competent had time to answer it properly." Most administrative AI in universities won't be revolutionary on its own. It will just quietly remove enough repetitive groundwork that researchers and administrators get more of their week back for the parts of the job that actually need a person — judgement, negotiation, and the research itself.
The useful thing about an agent like this was never that it knows the answer. It's that it knows where to look, how to calculate reliably once it's looked, and when to stop and hand the work to someone who can actually sign it off.