Skip to content

The assistant

The floating orb at the bottom right of every staff page.

A chat that understands plain language and runs real commands: look things up, count things, and perform actions, without hunting through menus.

  1. Click the orb. The panel opens with example prompts.
  2. Type a question or command, or click a suggestion. Matching examples autocomplete as you type.
  3. Results come back as text, and often as a clickable table. Click a row to jump to that loan, device, person or submission.
  4. Follow-up chips suggest sensible next steps.
  5. Expand for a larger centred view, or close when done.

It remembers who you are talking about within a conversation, so “issue them a loan” works after looking somebody up.

Questions and commands across loans, repairs, devices, people, stock and costs:

  • How many laptops are on loan?
  • Currently assigned loans
  • Who has loan #1?
  • Available iPads
  • Overdue repairs
  • Open repairs for Riley Brooks
  • Unassigned submissions
  • How much did we spend this year?
  • Purchases this week
  • Issue a loan to Riley Brooks
  • Create a damaged display repair for Riley Brooks with a loan

Exact wording is not required. “Who’s got laptop loans out right now” works as well as the canonical phrasing.

It can do things, not just report them. Before anything that changes data it shows a confirmation prompt, so you stay in control.

Actions respect your permissions. It can only do what your role allows, and every action is audited like any other. There is no path through the assistant to something your role forbids.

How it works, and why it costs nothing to run

Section titled “How it works, and why it costs nothing to run”

A built-in command engine handles the recognised commands. It is fast, offline, and needs no external service. This always works.

A local model, optionally. With an Ollama connector configured, the assistant uses it to map unusual phrasings onto the same commands, which makes it noticeably more flexible.

The model runs on a machine you control. Nothing is sent to OpenAI, Anthropic, Google or anyone else.

That is the reason the AI connector is Ollama rather than a hosted API. An assistant with access to student names, device serials and repair notes is not something most schools can send to a third party on the ICT team’s own authority.

It will not exceed your permissions. The model chooses among commands; the permission checks run regardless.

It will not act without confirming. Anything that writes shows a prompt.

It will not answer general questions. It is a service desk interface, not a chatbot. Asking it about the weather gets you nothing useful.

It will not send your data anywhere. With no model configured it is entirely offline. With one configured, it goes to your model on your hardware.

For a question somebody just asked. “How many iPads are out?” is faster typed than navigated.

For a chain of actions on one person. Look them up, see their repairs, issue a loan, all in one thread.

For counts and totals that would otherwise mean opening a report.

Use the screens for sustained work. The assistant is for the interruption.

The catalogue behind the assistant is the same one exposed to AI clients over the MCP server, with identical permission checks. There is no second implementation to drift out of step.

The privacy difference is worth being precise about: the assistant runs against a model you host. An MCP client you connect hands results to whatever model that client uses. See the MCP server.