Running a School's Workflows on Your Own Model
The pitch lands in my inbox about once a week now: artificial intelligence will run your school. Draft every parent message, answer every query, build the timetable, chase the unpaid fees. Point an API at the problem and watch the admin work melt away.
I build the software that actually does some of this, and I want to talk about a smaller, more boring question hiding underneath the hype — not whether to use a language model in school operations, but whose model, running where. Because for the schools I work with, the honest answer is increasingly: a modest open-source model, running on hardware we control, rather than a frontier model behind someone else's API. That's not ideology. It's what survives contact with a Nigerian school's budget, a parent's data, and a connection that drops at the worst possible moment.
What's actually worth automating
Start by being unromantic about the task. A language model is not going to run a school. But it is genuinely good at a handful of narrow, repetitive language jobs that eat an administrator's day:
- Drafting. Turning a one-line instruction — "tell JSS2 parents pickup is 1 p.m. on Friday" — into a clear, correctly toned message.
- Rewriting for tone. Softening a fee reminder so it carries respect, not threat. The most delicate message a school sends.
- Triage. Sorting a flood of inbound parent questions into "needs a human today," "answerable from the handbook," and "already covered in last week's notice."
- Translation. Carrying a notice between English and the language a family actually reads at home, without losing the meaning.
Notice what these have in common. They're bounded. They produce a draft a person checks, not a decision a machine commits. And crucially — none of them need a frontier model. A 7-to-30-billion-parameter open model is more than capable of rewriting a reminder politely or classifying a complaint. You are not curing cancer; you are saving a deputy head an hour of typing.
The three reasons "your own model" wins here
Once the task is that narrow, the case for self-hosting an open model — a Hermes fine-tune, a Qwen, a DeepSeek, a Llama derivative — stops being a hobbyist's preference and starts being plain engineering.
Cost that scales the wrong way. Per-token API pricing looks trivial until you multiply it by every parent, every message, every term. A school messaging thousands of families is exactly the high-volume, low-margin shape that punishes metered billing. A model you host has a fixed cost: the box it runs on. Past a surprisingly low volume, owning beats renting — and a school's volume is never going down.
Data that shouldn't leave the building. The text you feed these tasks is student names, parent phone numbers, who owes fees, who was absent, who was disciplined. Shipping that to a third-party API in another jurisdiction is a data-protection decision most schools have never consciously made. Running the model locally means the sensitive part of the workflow never crosses the boundary of the institution. Under Nigeria's Data Protection Act — and any serious duty of care to children — that is not a small thing.
The weakest connection in the building. I've written before about designing for the last bar of signal. An automation that depends on a reliable round-trip to a foreign API inherits the reliability of your worst internet moment. A small model running on a machine in the office keeps working when the line drops. For school operations, an always-there tool that's merely good beats a sometimes-there tool that's brilliant.
The discipline that makes it safe
None of this works without one rule, and it's the same rule that governs every other system I build: the model drafts; a human approves. Automate the typing, never the decision. The model proposes the parent message, the fee reminder, the translated notice — and a person who knows the families presses send. Take the human out of that loop to save thirty seconds and you trade it for the one wrong message that costs the school its trust, which is the only asset it can't rebuild quickly.
So the architecture is almost dull: a small open model, doing bounded language tasks, on hardware the school controls, with a person in the seat. No part of that sentence demos well. All of it holds up on a Tuesday in October when the network is flaky, the budget is fixed, and a parent is waiting to hear whether school closes early.
The interesting frontier of education technology, for me, was never the biggest model. It's the smallest one that's good enough, run in the place where it's cheapest, most private, and most reliable — and pointed at the unglamorous work that actually makes a school day run.