What it does
Open the Planner assistant next to any period and describe the outcome: move the Tuesday labs to the morning, take these placements off one teacher and spread them across the team, explain why last night's solve failed. The assistant answers questions, edits the plan and the timetable, runs generation, and reads the same analysis the panels show.
What makes this safe is the architecture underneath. Smootables has one command layer, about 200 planner commands, that powers interface buttons and AI alike, with about 170 of them exposed to the assistant as tools. There is no separate AI write path: every request passes the same input validation, the same permission checks, and the same school-scoped data boundary as a click. Intent routing decides which tools the assistant sees for each request, and a vague request drops it back to read-only tools.
How it works in Smootables
- Your school switches it on. The assistant is disabled by default for every school and stays hidden until enabled, so nobody meets an AI they did not ask for.
- Open Planner assistant from the header while viewing a plan or timetable. It is scoped to the period on screen; the empty state says "Ask about this period."
- Ask in your own words: reassign teachers across placements, move or swap lessons, split one in half, adjust schedule preferences, or run generation. The assistant can also drive the import pipeline, from parsing an .xlsx or CSV workbook to running the import.
- Watch each action land as a labeled tool call with running, completed, or failed status, and expand any of them for the specifics.
- Check the trail afterwards. AI-originated changes are logged with per-turn usage records, rate limits apply per planner, and timetable edits appear in the same edit log and versions as manual ones.
Key capabilities
One command layer
About 200 planner commands power buttons and AI alike, and about 170 are exposed as assistant tools. The assistant has no private write path into your data.
Names never reach the model
Teachers, students, and groups cross to the language model as codes such as T104. Real names are filled back in on your screen only, so the model works without them.
Analysis on demand
Ask why a timetable is infeasible, where teacher workload concentrates, or what drifted since the last generation, and get the same reports the analysis panels show.
Generation included
The assistant can run the solver, and the solve itself is unchanged: the same hard constraints, the same validation, and a saved version like any other run.
Scoped by intent
Routing picks the relevant tools for each request, and low-confidence requests fall back to read-only tools before anything can change.
Off until you say so
Disabled by default per school and fail-closed: if the enablement check cannot be read, the assistant stays off. Planners see it only after their school turns it on.
Planner in control, structurally
We keep the assistant on a leash made of architecture, not promises. It executes through the same commands, permission checks, and school data boundary as your own clicks, bulk changes have size caps, every mutation is logged, and timetable versions mean any result can be restored. It never bypasses the solver: a generation request runs the same hard constraints as pressing the button. A richer in-app review surface for AI actions is part of the Smootables vision.
Where it fits
The assistant is a faster hand on the same controls. It reaches its limits exactly where the product does, which is why the timetable generation page explains what the solver enforces, and individual learning paths explains what the planning model can carry. For the wider story of AI in school scheduling, read AI-powered school timetabling, and for the planning craft the assistant cannot replace, start with the timetabling guides.