An AI study companion, costed per student before any build
A private university wanted an AI study companion inside its online entry course. We designed the integration route, the guardrails and a capped cost model. Nothing was built; a separate course tracker of ours is in use.
Context
A private university runs a self-paced online entry course for incoming undergraduates, hosted in its learning-management system (LMS) with automatically graded activities and progression gates. It exists because many first-year students struggle with academic reading, written instructions and their first examinations, and some leave early.
The academic team asked for a companion that answers questions about navigating the course and generates extra practice on demand. A later working session widened the brief to written production, academic reading and the critical use of AI, and the team was interested in a comparison group so that a pilot could yield research evidence.
This is design work done ahead of any contract; we hold no record that the companion was commissioned or built. One separate piece of work was delivered and is in use: a course-administration tracker built for our own teaching, described below.
The challenge
Building a chatbot over course material is the easy part; the harder questions were institutional. Any integration with the official LMS meant a slow IT and security review, and the academic team asked us to avoid student-progress data in a first version. The assistant also had to help students learn without doing graded work for them.
Then there was money. A conversational assistant has a variable cost, and on a course that could reach a few thousand students nobody should face an open-ended bill.
Our approach
We treated the integration decision, not the agent, as the centre of the design, and costed operations as seriously as tokens.
- 1Frame the product and its limitsA framing document set out users, use cases, scope, guardrails and open decisions before any architecture was chosen.
- 2Research the LMS ecosystemWe compared seven integration routes, from a standalone external app to a platform of our own, and drafted 30+ questions for the university's IT team.
- 3Export the real courseWith course-level access, not administrator rights, we exported the live course offline as source material for a future knowledge base. No participant or grade data was taken.
- 4Model cost in three layersMemos for model API, cloud hosting and operations, a fourth on total real cost, then a short executive summary.
What was designed
In the design, the LMS stays the academic system of record. The companion would be a separate web application reached from inside the course, with no plugin in the LMS core. We set the options out as a ladder: an external app; a link from the course; a launch through LTI, the open standard that passes identity and course context to an outside tool; web-service access to progress data; and, last, a plugin.
- Retrieval over the real course. Answers would draw only on relevant fragments of the exported course material.
- Pedagogical guardrails. The assistant is specified never to solve graded activities, invent course rules, diagnose a student or take an academic decision. Anything beyond its scope goes to a teacher.
- Usage and budget limits. Turn limits per student and per session, response-length limits by intent, alerts at 50%, 80% and 100% of the consumption budget, and a hard cap per cohort.
- Three commercial lines. An implementation fee, a monthly operations retainer, and variable consumption passed through under an agreed cap.
The cost model counts what a chat really sends: system prompt, course context, retrieved fragments and the conversation history, resent on every turn. Usage was spread across four assumed student profiles, from one short session to ten long ones. Its main finding: the cost risk lies less in student numbers than in a prompt that sends too much context on every request.
The piece that exists: a course tracker
Separately, we built and use an agent-operated tracker for a small postgraduate course that one of our team teaches: a local application with its own database and 15+ agent skills, from read-only inspection of the course site to draft alerts, weekly audits and an approval queue. It was delivered as an own-use tool; it is not part of the university proposal and not a client deployment.
Results
There are no outcome results to report. The output is a set of design documents: the framing document, the research report, the offline course export, four cost memos with a summary, and a 40+ chapter technical reference on connecting an external AI agent to an LMS through LTI.
Course text only, exported with course-level access rather than administrator rights. No participant, grade or student data was extracted.
Projection, not a bill: assumes about 15 chat turns per student on average and provisional unit prices. The design adds a reserve and a US$500 hard cap.
Same model and assumptions. At the US$500 hard cap, the ceiling for a cohort of ~3,000 is under 20 US cents per student.
Order-of-magnitude estimate from the research report. Depends on the university's IT team enabling LTI.
Every cost figure is a projection. The model assumes an upper-bound cohort of about 3,000 students; a first cohort would more likely be a few hundred, so per-cohort totals are upper bounds while fixed hosting weighs more per student. Unit prices were working assumptions, to be confirmed against the chosen provider's price list. No usage has been observed.
The design also moved. The reference architecture assumes an LTI launch with pseudonymous identifiers; the follow-up we drafted afterwards proposed something simpler: a link from the course page, one controlled institutional access, no individual accounts. Our own report says plainly that a link looks integrated but technically is not. The draft also folded build and usage into one amount, which our cost memos advise against.
Governance and risk
The privacy position was minimal data by default: no grades, no progress records, short retention, a clear notice that students are talking to an AI, and no training of external models on student data without explicit authorisation. The security design, drawn against abuse, scraping, prompt injection and denial-of-wallet, keeps keys on the server, rate-limits requests, caps message and token sizes, and stops course documents overriding the assistant's policies. None of it has been tested in a running system.
The tracker applies the same discipline in a tool that runs. It separates facts observed in the course site from its own operational state, treats every page and file as untrusted input, and defaults to read-only and dry-run. Anything that would write waits for explicit approval naming the exact action; at the time of our records, no such action had been performed.
What we learned
- Decide how the agent relates to the system of record before designing the agent. A ladder of integration levels lets a pilot start without the deepest approval.
- Model cost per turn, including resent history, and set a hard cap. Then say plainly that the recurring cost is operations, not tokens.
- Keep agents that touch an institutional system read-only and dry-run by default, with explicit approval at the moment of any action that writes.
Client identity, locations and identifying details are withheld under confidentiality. Figures are rounded. Measured figures come from engagement records; client-reported figures are attributed, not audited; modelled figures are projections from the engagement's business case and are labelled as such.